DHCP через VPN: прокидывать широковещание мостом или пересылать?

Новый ноутбук на другой стороне туннеля не получает адрес, хотя тот же ноутбук работает в головном офисе. Обычное первое предположение — туннель блокирует DHCP. Чаще широковещательному запросу просто не было пути: не настроенный клиент отправляет на 255.255.255.255, а обычный IP-маршрутизатор этот пакет не пересылает. Туннель делает ровно то, что делает маршрутизируемый туннель.

Две схемы могут это изменить, и они не эквивалентны. Одна переносит широковещание, другая пересылает запрос.

Широковещание никогда не пересекает маршрутизатор

Клиент DHCPv4 без адреса отправляет с 0.0.0.0 на ограниченный широковещательный адрес через UDP-порты 67 и 68. Этот пакет по замыслу остаётся на своём канале. Маршрутизатор, который бы его пересылал, затапливал бы каждый обслуживаемый им сегмент.

Поэтому маршрутизируемый туннель между площадками соединяет ретранслятор с сервером. Он не расширяет широковещательный домен клиента, и никакое правило межсетевого экрана этого не сделает.

Что на самом деле расширяет мостовой туннель

Намеренно объединённый мостом VPN может переносить широковещание Ethernet в рамках поддерживаемой топологии, и тогда DHCP может проходить как локальный трафик. Это реальный вариант, но это проектное решение уровня 2. Вы расширяете домен отказов и границу доступа вместе с широковещанием.

Мост также меняет то, куда могут добраться широковещательный шторм, ARP-сканирование или поддельный DHCP-сервер. Если вы не подключили бы удалённый офис к тому же коммутатору, не объединяйте туннель мостом только ради выдачи адресов. Проверьте этот радиус поражения, прежде чем включать.

Это более крупное решение, чем выдача адреса, и принимать его нужно осознанно.

Вместо этого пересылайте запрос

Обычный ответ — ретранслятор в локальной сети клиента. Он принимает широковещание, превращает его в unicast-запрос и помещает свой адрес в поле адреса шлюза. Сервер отвечает на этот адрес ретранслятора.

Для примера с удалённым офисом ретранслятор стоит в LAN офиса, а сервер доступен через VPN площадки. Настройте область для этого офиса, идентификаторы ретранслятора и сервера, а также полный обратный путь. Разрешение UDP 67 через туннель не говорит серверу, какой пул использовать.

Ретранслятор, который пересылает, но никогда не получает ответ, обычно означает проблему обратного пути. Проверьте маршрут обратно к адресу ретранслятора, прежде чем менять область.

Отделите DHCP от ARP и от адресации туннеля

DHCP работает поверх UDP/IP. В Ethernet хост может также использовать ARP, чтобы проверить, не занят ли уже адрес-кандидат. Эта проверка конфликта — отдельная локальная для канала операция, а не транспорт для сообщений DHCP. Утверждать, что DHCP — это по сути ARP, неверно; утверждать, что эти двое никогда не связаны, слишком широко.

VPN-клиент может получить адрес туннеля и из протокола VPN или из собственного пула сервера, а не из широковещания DHCP. Параметр, в имени которого есть DHCP, может описывать протолкнутые настройки клиента, а не пересланный пакет DHCP. Проверьте пул сервера, прежде чем предполагать, что DHCP вообще задействован.

Запишите сеть получателя, владельца выделения, область, наличие ретранслятора и ожидаемое поведение при сбое. Затем проверьте новую аренду и продление по этой модели. Если две площадки могут обслуживать один и тот же неуправляемый пул, у вас есть конфликт, ожидающий первого перемещающегося ноутбука.