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 наогул задзейнічаны.

Запішыце сетку атрымальніка, уладальніка выдзялення, вобласць, наяўнасць рэтранслятара і чаканыя паводзіны падчас збою. Затым праверце новую арэнду і яе прадаўжэнне па гэтай мадэлі. Калі дзве пляцоўкі могуць абслугоўваць адзін і той жа некіраваны пул, у вас ёсць канфлікт, які чакае першага вандравальнага ноўтбука.