В любой современной корпоративной сети жизненный цикл IP-адреса начинается с DHCP-запроса. Принтеры, телефоны, терминалы, камеры, клиентские станции — всё, что появляется в сети, просыпается с нулевым знанием о своей сетевой принадлежности. Первая вещь, которую делает устройство, — отправляет широковещательный DHCP Discover. И если этот сигнал не доходит до сервера или не получает ответ — всё остальное становится бессмысленным: ни безопасности, ни доступа, ни мониторинга, ни маршрутизации.

В простых одноранговых сетях, где DHCP-сервер находится в одном вещательном домене, всё работает интуитивно. Но как только появляется сегментация, VLAN'ы, маршрутизаторы и распределённая архитектура — всё меняется. Именно здесь ключевую роль начинает играть агент DHCP Relay — механизм, передающий широковещательные запросы через маршрутизируемые границы к удалённому серверу. На первый взгляд, логика проста: получить Discover → отправить Unicast на сервер → дождаться Offer → передать обратно клиенту. Но малейший сбой на любом этапе этой цепи — и клиент зависает в бесконечном ожидании IP. При массовом подключении или перезапуске устройств сеть может буквально "захлебнуться" в жалобах на недоступность, в то время как ядро остаётся «здоровым» — пинги идут, мониторинг молчит, оборудование работает. Именно это делает проблемы с DHCP Relay коварными: их симптомы проявляются как «частичная деградация», часто не распознаваемая как единый сбой.

Как работает DHCP Relay: шаг за шагом

Чтобы понять уязвимости, сначала разложим по этапам, что делает агент Relay. Предположим, у нас есть VLAN 10 (корпоративные рабочие станции), VLAN 20 (IP-телефония), маршрутизатор с интерфейсами в каждой из VLAN, и централизованный DHCP-сервер, расположенный в VLAN 100 или даже за пределами коммутируемой инфраструктуры. DHCP Discover — это широковещательное сообщение (255.255.255.255:67), которое не покидает вещательный домен. На уровне L3 границы оно отбрасывается, если не включена опция DHCP Relay.

Агент Relay делает следующее:

1. Получает широковещательный Discover.
2. Инкапсулирует его в unicast-сообщение и отправляет его на заранее указанный IP-адрес DHCP-сервера.
3. Подставляет в поле GIADDR (Gateway IP Address) IP-адрес интерфейса, на котором был получен Discover — это критически важно.
4. Получает Offer от сервера и отправляет его назад клиенту как ответ.

Если в этой схеме хотя бы один параметр отсутствует или некорректен — клиент не получит IP.

Ошибка 1: Неверно указанный адрес DHCP-сервера

Классическая ошибка — ручной ввод IP-адреса DHCP-сервера в настройках Relay. Особенно если сервер переехал, попал под NAT или сменил интерфейс. При этом маршрутизатор будет по-прежнему пытаться отправлять Discover по старому адресу, получая либо ICMP unreachable, либо просто тишину. Диагностика затруднена тем, что маршрутизатор не генерирует ошибок, пока физически может доставить пакет. Он "думает", что всё хорошо.

Сложность возрастает, если сервер доступен по нескольким интерфейсам, а IP-адрес, прописанный в Relay, не соответствует интерфейсу, настроенному в DHCP-сервере как источник ответа. В Windows Server это особенно критично — сервер может молча игнорировать запросы, поступившие не на «разрешённый» интерфейс.

Решение: Всегда использовать DNS-имена (если поддерживается) или обеспечить строгую маршрутизацию, исключающую неоднозначность. На оборудовании D-Link (например, маршрутизаторы DSR или L3-коммутаторы серии DGS-3130) возможно указание нескольких серверов и применение политики failover, но важно помнить: неправильный адрес не станет «резервом» — он просто сломает цепочку.

Ошибка 2: Отсутствие обратного маршрута от DHCP-сервера

Это один из самых недооценённых и сложных для диагностики сбоев. Пакет Discover доходит до сервера, сервер корректно формирует Offer и отправляет его обратно… но не клиенту, а на "неизвестный" адрес — потому что GIADDR не распознан или не маршрутизируется. Сервер не может отправить Offer в обратную сторону, и клиент так и не узнаёт, что IP уже лежал «на столе».

Если Relay не формирует GIADDR или сервер не имеет маршрута до GIADDR — это тупик. Особенно сложно, когда сервер находится в DMZ, а маршруты до внутренних VLAN прописаны только частично или только в NAT-преобразованиях.

Решение: Настройка статических маршрутов или возвратного маршрута по GIADDR. Это критично. Если используется Firewall между сегментами — необходимо разрешить не только UDP 67/68, но и гарантировать корректную маршрутизацию, включая Source IP, иначе пакеты будут отброшены как «невалидные».

Ошибка 3: DHCP Relay работает на нескольких интерфейсах с одинаковыми опциями

Ситуация, типичная для сценариев с несколькими VLAN, когда Relay включён на всех интерфейсах, но все они ссылаются на один и тот же DHCP-сервер. Если сервер не поддерживает разнесение по GIADDR (или если он игнорирует его), то может выдать IP-адреса из одной подсети на клиентов из другой.

Особенно это опасно при конфигурациях, где администратор считает, что DHCP «автоматически всё разрулит по VLAN» — это не так.

Результат: клиент в VLAN 20 получает IP из пула VLAN 10. Маска не соответствует, шлюз не тот, Default Route указывает в пустоту. А на коммутаторе — полное молчание, MAC-таблица пуста, ARP не отвечает. Часто такие ситуации принимаются за «отвалившийся порт» или «неработающий кабель».

Решение: Убедиться, что сервер обрабатывает GIADDR и раздаёт IP по подсетям строго. В D-Link DHCP Server можно задать разные пулы по GIADDR. В Windows — использовать условные политики (Policy-Based Assignment), а в Linux — настроить isc-dhcp-server с множеством подгрупп в subnet-блоках.

Ошибка 4: Одновременное использование DHCP Relay и локального DHCP-сервера

Сценарий, встречающийся при миграциях или тестировании. Если в сети включены оба механизма — DHCP-сервер и Relay, и они оба обслуживают одну и ту же VLAN — может начаться гонка между ответами. Клиент получит два Offer, и если один из них придёт с меньшей задержкой, а второй — с другим шлюзом, DNS или даже подсетью, поведение будет непредсказуемым.

В Linux клиенты могут принять первый ответ, а в Windows — последний. Какой из них придёт позже — зависит от маршрутов и задержек.

Решение: Исключить двойную работу. Либо работает Relay и централизованный сервер, либо раздача происходит локально. Не допускается включение и того, и другого без строгой приоритезации и разнесения по VLAN.

Ошибка 5: MTU, фрагментация и DHCP Options

Некорректно настроенные туннели, GRE, IPsec или даже неправильно установленные MTU-лимиты могут привести к фрагментации DHCP-пакетов, особенно если сервер использует длинные списки опций (Option 43, 82 и т. д.). Некоторые коммутаторы или маршрутизаторы отбрасывают фрагменты без reassembly, в результате чего клиент получает «обрезанный» Offer и не может принять IP.

Решение: Принудительная установка MSS Clamping на границе VLAN, проверка MTU на туннелях и отказ от избыточных опций в тестовых средах. На оборудовании D-Link последних серий настройка Option 82 доступна напрямую, включая управление поведением при перенаправлении пакетов — это может быть критично в сложных сетях с туннелями между зданиями.

К чему всё это приводит?

Самая коварная особенность DHCP Relay в том, что его сбой часто не распознаётся как «сбой». Нет резких аварий, нет падений коммутаторов или циклов перезагрузки. Просто — кто-то не получил IP. Потом — второй. Через час — третий. Администратор проверяет: коммутатор в норме, пинги есть, сервер работает. И только через серию Wireshark-сессий, анализов DHCP handshake и отслеживания ARP можно понять, что проблема — в одной строке конфигурации, которую никто не трогал месяцами. Особенно сложно, если устройство было перенастроено с сохранением старых Relay-записей или IP-адресов после смены провайдера.

DHCP Relay как точка уязвимости в корпоративной архитектуре

При должной настройке DHCP Relay является мощным механизмом централизованного управления адресацией. Но малейшая ошибка в конфигурации превращает его в точку отказа, затрагивающую все слои инфраструктуры. В больших компаниях сбои DHCP воспринимаются как деградация клиентских станций, в техподдержку поступают жалобы «не подключается сеть», а инженеры тратят часы на проверку VLAN, кабелей и патч-панелей — лишь чтобы понять, что всё работало бы, если бы Discover доходил до сервера.

На курсе «Сетевой администратор» в ВиАкадемии мы разбираем архитектуру DHCP, включая работу агента Relay. Обучение сопровождается практикумами: выстраивание ретрансляции, трассировка Discover, анализ ошибок, настройка резервных серверов и отказоустойчивость DHCP-подсистемы. После курса администратор знает, что DHCP — это не просто «сервер адресов», а точка архитектурного управления, от которой зависит стабильность всей сети.

Если Вы готовы выстраивать продуманную сетевую архитектуру и устранять сбои до того, как они превратятся в инциденты — ждём Вас на курс. Курс «Сетевой администратор» не только обучает, но и готовит к реальной работе в корпоративных инфраструктурах.