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 взагалі задіяний.

Запишіть мережу отримувача, власника виділення, область, наявність ретранслятора та очікувану поведінку під час збою. Потім перевірте нову оренду й поновлення за цією моделлю. Якщо два майданчики можуть обслуговувати один і той самий некерований пул, у вас є конфлікт, що чекає на перший мандрівний ноутбук.