DHCP gjennom ein VPN: bru broadcastet eller videresende det?
Klientar på den andre sida av ein tunnel får inga adresse. Avgjer om broadcastet skal berast eller videresendast, og hald DHCP skild frå ARP.
Ein ny laptop på den andre sida av tunnelen får inga adresse, medan den same laptoppen fungerer på hovudkontoret. Den vanlege første gjetninga er at tunnelen blokkerer DHCP. Oftare har broadcastet aldri hatt ein veg: ein ukonfigurert klient sender til 255.255.255.255, og ein vanleg IP-ruttar videresender ikkje den pakken. Tunnelen gjer nøyaktig det ein ruta tunnel gjer.
To design kan endre det, og dei er ikkje likeverdige. Det eine ber broadcastet; det andre videresender førespurnaden.
Broadcastet kryssar aldri ruttaren
Ein DHCPv4-klient utan adresse sender frå 0.0.0.0 til den avgrensa broadcast-adressa på UDP-portane 67 og 68. Den pakken blir på lenkja si av design. Ein ruttar som videresende han, ville oversvømme kvart segment han tener.
Så ein ruta side-til-side-tunnel knyter reléet til ein tenar. Han utvidar ikkje broadcast-domenet til klienten, og inga brannmurregel får han til det.
Kva ein brua tunnel faktisk utvidar
Eit medvite brua VPN kan bere Ethernet-broadcast under topologien det støttar, og då kan DHCP passere som lokal trafikk. Det er eit reelt alternativ, men det er eit designval på lag 2. Du utvidar feildomenet og tilgangsgrensa saman med broadcastet.
Bruing endrar òg kva ein broadcast-storm, ein ARP-skanning eller ein falsk DHCP-tenar kan nå. Viss du ikkje ville kopla fjernkontoret til same svitsj, ikkje bru tunnelen berre for å dele ut adresser. Test den radiusen før du slår det på.
Det er ei større avgjerd enn å skaffe ei adresse, og ho bør takast medvite.
Videresend førespurnaden i staden
Det vanlege svaret er eit relé på det lokale nettet til klienten. Det tek imot broadcastet, gjer det om til ein unicast-førespurnad og set si eiga adresse i gateway-adressefeltet. Tenaren svarar til den reléadressa.
For eit illustrerande fjernkontor sit reléet på LAN-et til kontoret, og tenaren blir nådd over VPN-en til staden. Konfigurer omfanget for det kontoret, identitetane til reléet og tenaren, og den fulle returvegen. Å tillate UDP 67 gjennom tunnelen fortel ikkje tenaren kva basseng som skal brukast.
Eit relé som videresender men aldri tek imot eit svar, er vanlegvis eit returvegproblem. Kontroller ruta tilbake til reléadressa før du endrar omfanget.
Skil DHCP frå ARP og frå tunneladressering
DHCP går over UDP/IP. På Ethernet kan ein vert òg bruke ARP for å sjekke om ei kandidatadresse alt er i bruk. Den konfliktsjekken er ein eigen lenkelokal operasjon, ikkje transporten for DHCP-meldingar. Å seie at DHCP i hovudsak er ARP, er feil; å seie at dei to aldri har med kvarandre å gjere, er for breitt.
Ein VPN-klient kan òg få tunneladressa si frå VPN-protokollen eller frå tenaren sitt eige basseng i staden for frå eit DHCP-broadcast. Eit alternativ med DHCP i namnet kan skildre pusja klientinnstillingar, ikkje ein videresend DHCP-pakke. Kontroller bassenget til tenaren før du reknar med at DHCP er involvert i det heile.
Noter mottakarnettverket, eigaren av tildelinga, omfanget, om det finst eit relé, og forventa åtferd under eit avbrot. Test deretter ein ny lease og ei fornying gjennom den modellen. Viss to stader kan tene det same ustyrte bassenget, har du ein konflikt som ventar på den første mobile laptoppen.