Про APIPA, Эффект гонки и как DORA связана с DHCP?

DHCP (Dynamic Host Configuration Protocol) - это сетевой протокол, который автоматически раздает устройствам IP-адреса и другие важные настройки (маску подсети, шлюз по умолчанию и адреса DNS-серверов). Без него каждый адрес в сети пришлось бы вбивать руками.

Процесс получения IP-адреса называется DORA (по первым буквам четырех этапов):

1. D - Discover (Поиск): Новое устройство кричит на всю сеть (широковещательный запрос): "Эй! Мне нужен IP-адрес. Тут есть DHCP-сервер?"
2. O - Offer (Предложение): Роутер (или выделенный сервер) слышит запрос, резервирует свободный адрес и отвечает: "Я тут. Возьми вот этот IP".
3. R - Request (Запрос): Устройство отвечает: "Отлично, беру! Оформи аренду".
4. A - Acknowledge (Подтверждение): Сервер фиксирует выдачу: "Договорились. Адрес твой на следующие 24 часа".

Динамические адреса - это удобно для смартфонов, но плохо для серверов. Например, если вы подняли сервер Minecraft или развернули виртуалку в Proxmox, смена IP после перезагрузки сломает все доступы. Для таких случаев в DHCP используют Static Lease (Резервирование) - жесткую привязку нужного IP-адреса к MAC-адресу сетевой карты устройства.

Пример: Клиентский ПК без интернета
Во время удаленной поддержки клиент жалуется, что сеть "отвалилась". Ты просишь его проверить IP-адрес в настройках Windows, и он диктует что-то вроде 169.254.x.x.
Это так называемый адрес APIPA (Automatic Private IP Addressing). Он означает, что процесс DORA сломался на первом же шаге: ПК прокричал "Discover", но DHCP-сервер ему не ответил (или до него не дошел запрос из-за проблем со свитчем). ОС поняла, что ответа не будет, и назначила себе этот резервный адрес.

Подробнее про APIPA (169.254.x.x)

APIPA (Automatic Private IP Addressing) - это встроенный в операционные системы (Windows, macOS, большинство дистрибутивов Linux) механизм "спасения утопающих".

Когда ПК отправляет широковещательный DHCP Discover, но в ответ тишина (таймаут), ОС понимает: "Сервера нет, но сеть как-то строить надо". Тогда она делает следующее:

1. Выбирает случайный адрес из зарезервированного диапазона 169.254.0.1 – 169.254.255.254 с маской подсети 255.255.0.0 (или /16).
2. Проверяет на конфликты: Перед тем как назначить этот адрес сетевому интерфейсу, ПК отправляет специальный запрос (Gratuitous ARP) в сеть: "Эй, у кого-нибудь уже есть этот 169.254.x.y?". Если ответа нет - забирает адрес себе. Если есть - генерирует новый и спрашивает снова.

APIPA не назначает основной шлюз (Default Gateway) и DNS.
Это значит, что интернета на этом ПК не будет. Однако, если в кабинете стоит свитч, к которому подключены пять компьютеров, и роутер внезапно "умер", все пять ПК получат адреса 169.254.x.x. Они смогут пинговать друг друга, и ты даже сможешь расшарить между ними папку по локалке. Это так называемая Link-Local сеть.

Два DHCP-сервера в одной сети: Эффект гонки (Race Condition)

Представь ситуацию: в офисе работает основной роутер (сеть 192.168.1.0/24), но кто-то из сотрудников принес из дома свой Wi-Fi роутер (сеть 10.0.0.0/24), воткнул его LAN-портом в офисную розетку и забыл выключить на нем DHCP. Это называется Rogue DHCP (ложный/паразитный DHCP-сервер).

Оба сервера находятся в одном широковещательном домене (L2-сегменте). Что произойдет, когда новый клиент включит ПК?

Сработает правило: Кто первый встал, того и тапки.

1. Клиент кричит на всю сеть DHCP Discover.
2. Этот крик слышат оба DHCP-сервера.
3. Оба сервера моментально формируют пакет DHCP Offer (один предлагает 192.168.1.50, другой - 10.0.0.20) и отправляют его клиенту.
4. Клиент получает оба предложения, но принимает то, которое пришло к нему первым. Второе он просто игнорирует.
5. Клиент отправляет DHCP Request на первый пришедший IP, официально забирая его. Проигравший сервер видит это и возвращает свой IP обратно в пул свободных.

От чего зависит скорость ответа?

• От загрузки процессора роутера/сервера.
• От топологии (какой сервер физически ближе по количеству свитчей к клиенту).
• От настроек (некоторые enterprise-серверы искусственно делают микро-задержку пинга перед выдачей IP, чтобы проверить, не занят ли он, а дешевый домашний роутер выпаливает адрес не глядя).

Последствия для сети:

Абсолютный хаос. Половина офиса (те, кто успел получить правильный IP от 192.168.1.x) будет работать нормально. Вторая половина получит IP 10.0.0.x, неправильный шлюз (домашний роутер сотрудника) и останется без интернета и доступа к корпоративным ресурсам. Причем после перезагрузки ПК ситуация может поменяться местами.

Для защиты от таких паразитных серверов на умных (управляемых) коммутаторах настраивают функцию DHCP Snooping. Она разрешает пакетам DHCP Offer проходить только через один конкретный (доверенный) порт, к которому подключен легальный сервер, а на всех остальных портах такие пакеты жестко блокируются.

Защита инфраструктуры: DHCP Snooping

DHCP Snooping - это как раз тот самый "фейсконтроль" на уровне управляемого коммутатора (свитча), который защищает сеть от хаоса с двумя серверами.

Чтобы понять, какой именно порт блокируется, нужно посмотреть на то, как коммутатор делит все свои порты после включения этой функции. Он разбивает их на два лагеря: Trusted (Доверенные) и Untrusted (Недоверенные).

Как это выглядит под капотом
По умолчанию, когда ты включаешь DHCP Snooping на свитче, абсолютно все порты становятся недоверенными (Untrusted). Доверенные порты сетевой администратор должен назначить руками.

1. Trusted (Доверенный) порт: Это порт, к которому физически подключен твой легальный DHCP-сервер (или аплинк-порт, который ведет к другому коммутатору, за которым стоит сервер).
   1. Что разрешено: Через этот порт коммутатор пропускает любые DHCP-пакеты. И запросы от клиентов (Discover, Request), и ответы от сервера (Offer, Acknowledge).
2. Untrusted (Недоверенный) порт:
   1. Это порты, куда подключаются обычные пользователи, рабочие станции, принтеры и, потенциально, тот самый принесенный из дома роутер сотрудника.
   2. Что разрешено: Коммутатор разрешает получать из этого порта только клиентские запросы (Discover, Request), потому что ПК должны иметь возможность попросить IP.
   3. Что БЛОКИРУЕТСЯ: Если из этого порта вдруг "вылетает" пакет от имени сервера (например, DHCP Offer с предложением IP-адреса), коммутатор понимает: "Ага, за этим портом сидит самозванец!". Он моментально отбрасывает (drop) этот пакет, а сам порт может перевести в состояние ошибки (err-disable), выключив на нем линк и отправив алерт админу.

Binding Database

DHCP Snooping Binding Database (База данных привязок) - это специальная таблица, которую коммутатор (свитч) автоматически создает и хранит в своей оперативной памяти, когда на нем активирована функция DHCP Snooping.

Позже эта таблица используется для защиты от подмены IP-адресов и мак-спуфинга (например, с помощью функции Dynamic ARP Inspection), чтобы никто не мог вручную прописать себе чужой IP и перехватывать трафик.

Как выглядит эта таблица

Если зайти в консоль управления коммутатором (например, Cisco) и ввести команду show ip dhcp snooping binding, вы увидите примерно такую картину:

Сама по себе Binding Database - это просто лог-файл. Но она является фундаментом для работы двух очень мощных технологий защиты от хакеров внутри локальной сети:

1. Dynamic ARP Inspection (DAI) - Защита от перехвата трафика
   1. Проблема: Хакер в локальной сети может отправить фальшивое сообщение (ARP-ответ) всем компьютерам: "Эй, теперь я ваш роутер (шлюз), отправляйте весь интернет-трафик через меня!". Это называется атакой Man-in-the-Middle (Человек посередине).
   2. Как помогает база: Если включить DAI, коммутатор перестает верить устройствам на слово. Когда порт хакера пытается заявить: "Мой IP - это IP роутера", свитч мгновенно сверяется с Binding Database. Он видит: "Так, на порту №8 у нас числится IP 192.168.1.51, а ты пытаешься выдать себя за шлюз 192.168.1.1. Блокирую!". Пакет уничтожается.
2. IP Source Guard (IPSG) - Защита от подмены IP-адреса
   1. Проблема: Пользователь может вручную зайти в настройки сетевого адаптера Windows и прописать себе чужой IP-адрес (например, адрес начальника или сервера), чтобы получить чужие права доступа или избежать ограничений по скорости.
   2. Как помогает база: Свитч проверяет каждый исходящий пакет данных от пользователя. Если в пакете указан IP-адрес отправителя 192.168.1.100, а в базе привязок за этим портом числится 192.168.1.50, коммутатор просто не выпустит этот трафик за пределы порта.