DHCP gjennom en VPN: bro broadcastet eller videresende det?
Klienter på den andre siden av en tunnel får ingen adresse. Bestem om broadcastet skal bæres eller videresendes, og hold DHCP atskilt fra ARP.
En ny laptop på den andre siden av tunnelen får ingen adresse, mens den samme laptopen fungerer på hovedkontoret. Den vanlige første gjetningen er at tunnelen blokkerer DHCP. Oftere har broadcastet aldri hatt en vei: en ukonfigurert klient sender til 255.255.255.255, og en vanlig IP-ruter videresender ikke den pakken. Tunnelen gjør nøyaktig det en rutet tunnel gjør.
To design kan endre det, og de er ikke likeverdige. Det ene bærer broadcastet; det andre videresender forespørselen.
Broadcastet krysser aldri ruteren
En DHCPv4-klient uten adresse sender fra 0.0.0.0 til den begrensede broadcast-adressen på UDP-portene 67 og 68. Den pakken blir på sin lenke av design. En ruter som videresendte den, ville oversvømme hvert segment den betjener.
Så en rutet side-til-side-tunnel kobler reléet til en server. Den utvider ikke klientens broadcast-domene, og ingen brannmurregel får den til det.
Hva en broet tunnel faktisk utvider
En bevisst broet VPN kan bære Ethernet-broadcast under sin støttede topologi, og da kan DHCP passere som lokal trafikk. Det er et reelt alternativ, men det er et designvalg på lag 2. Du utvider feildomenet og tilgangsgrensen sammen med broadcastet.
Broing endrer også hva en broadcast-storm, en ARP-skanning eller en falsk DHCP-server kan nå. Hvis du ikke ville koblet fjernkontoret til samme svitsj, ikke bro tunnelen bare for å dele ut adresser. Test den radiusen før du aktiverer det.
Det er en større beslutning enn å skaffe en adresse, og den bør tas bevisst.
Videresend forespørselen i stedet
Det vanlige svaret er et relé på klientens lokale nettverk. Det mottar broadcastet, gjør det om til en unicast-forespørsel og setter sin egen adresse i gateway-adressefeltet. Serveren svarer til den reléadressen.
For et illustrerende fjernkontor sitter reléet på kontorets LAN, og serveren nås over stedets VPN. Konfigurer omfanget for det kontoret, identitetene til reléet og serveren, og den fulle returveien. Å tillate UDP 67 gjennom tunnelen forteller ikke serveren hvilken pool som skal brukes.
Et relé som videresender men aldri mottar et svar, er vanligvis et returveiproblem. Kontroller ruten tilbake til reléadressen før du endrer omfanget.
Skille DHCP fra ARP og fra tunneladressering
DHCP går over UDP/IP. På Ethernet kan en vert også bruke ARP for å sjekke om en kandidatadresse allerede er i bruk. Den konfliktsjekken er en egen lenkelokal operasjon, ikke transporten for DHCP-meldinger. Å si at DHCP i hovedsak er ARP, er feil; å si at de to aldri har med hverandre å gjøre, er for bredt.
En VPN-klient kan også få tunneladressen sin fra VPN-protokollen eller fra serverens egen pool i stedet for fra et DHCP-broadcast. Et alternativ med DHCP i navnet kan beskrive pushede klientinnstillinger, ikke en videresendt DHCP-pakke. Kontroller serverens pool før du antar at DHCP er involvert i det hele tatt.
Noter mottakernettverket, eieren av tildelingen, omfanget, om det finnes et relé, og forventet oppførsel under et avbrudd. Test deretter en ny lease og en fornyelse gjennom den modellen. Hvis to steder kan betjene den samme ustyrte poolen, har du en konflikt som venter på den første mobile laptopen.