DHCP cez VPN: premostiť broadcast alebo ho preposielať?
Klienti na druhej strane tunela nedostanú adresu. Rozhodnite sa, či broadcast prenášať, alebo preposielať, a držte DHCP oddelene od ARP.
Nový notebook na druhej strane tunela nedostane adresu, zatiaľ čo ten istý notebook v centrále funguje. Zvyčajný prvý predpoklad je, že tunel blokuje DHCP. Častejšie broadcast nikdy nemal cestu: nenakonfigurovaný klient posiela na 255.255.255.255 a bežný IP router tento paket nepreposiela. Tunel robí presne to, čo robí routovaný tunel.
Dva návrhy to môžu zmeniť a nie sú rovnocenné. Jeden broadcast prenáša; druhý požiadavku preposiela.
Broadcast nikdy neprejde routerom
Klient DHCPv4 bez adresy posiela z 0.0.0.0 na adresu obmedzeného broadcastu na UDP portoch 67 a 68. Tento paket podľa návrhu zostáva na svojom spoji. Router, ktorý by ho preposlal, by zaplavil každý segment, ktorému slúži.
Routovaný tunel medzi lokalitami teda prepája relay so serverom. Nerozširuje broadcastovú doménu klienta a žiadne pravidlo firewallu to nezmení.
Čo premostený tunel skutočne rozširuje
Zámerne premostená VPN môže prenášať Ethernet broadcast v rámci svojej podporovanej topológie a potom môže DHCP prejsť ako lokálna prevádzka. Je to reálna možnosť, ale je to dizajnové rozhodnutie vrstvy 2. Rozširujete doménu zlyhania a hranicu prístupu spolu s broadcastom.
Mostovanie tiež mení, kam sa môže dostať broadcastová búrka, ARP sken alebo podvodný DHCP server. Ak by ste vzdialenú pobočku nepripojili do toho istého prepínača, nemostujte tunel len preto, aby ste prideľovali adresy. Otestujte tento polomer dopadu, kým to zapnete.
Je to väčšie rozhodnutie ako dodať adresu a malo by sa urobiť vedome.
Namiesto toho požiadavku preposielajte
Zvyčajnou odpoveďou je relay v lokálnej sieti klienta. Prijme broadcast, prevedie ho na unicast požiadavku a vloží svoju vlastnú adresu do poľa adresy brány. Server odpovedá na túto adresu relayu.
Pre ilustratívnu vzdialenú pobočku relay sedí v LAN pobočky a na server sa dosahuje cez VPN lokality. Nakonfigurujte rozsah pre túto pobočku, identity relayu a servera a úplnú spiatočnú cestu. Povolenie UDP 67 tunelom serveru nepovie, ktorý fond má použiť.
Relay, ktorý preposiela, ale nikdy nedostane odpoveď, je zvyčajne problém spiatočnej cesty. Než zmeníte rozsah, skontrolujte cestu späť k adrese relayu.
Oddeľte DHCP od ARP a od adresovania tunela
DHCP beží nad UDP/IP. Na Ethernete môže hostiteľ použiť aj ARP na overenie, či kandidátska adresa už nie je obsadená. Táto kontrola konfliktu je samostatná operácia lokálna na spoji, nie transport správ DHCP. Hovoriť, že DHCP je v podstate ARP, je nesprávne; hovoriť, že tieto dve nikdy nesúvisia, je príliš široké.
Klient VPN môže svoju adresu tunela získať aj z protokolu VPN alebo z vlastného fondu servera, nie z broadcastu DHCP. Voľba, ktorej názov obsahuje DHCP, môže opisovať pretlačené nastavenia klienta, nie preposlaný paket DHCP. Skontrolujte fond servera, kým budete predpokladať, že DHCP vôbec zasahuje.
Zaznamenajte cieľovú sieť, vlastníka pridelenia, rozsah, či existuje relay a očakávané správanie počas výpadku. Potom otestujte nový prenájom aj obnovenie týmto modelom. Ak dve lokality môžu obsluhovať ten istý nespravovaný fond, máte konflikt, ktorý čaká na prvý roamingový notebook.