DHCP over en VPN: skal broadcastet broes eller videresendes?
Klienter på andre siden av en tunnel får ingen adresse. Bestem om broadcastet skal bæres eller videresendes, og hold DHCP adskilt fra ARP.
En ny laptop på andre siden av tunnelen får ingen adresse, mens samme laptop virker på hovedkontoret. Den vanlige første antagelsen er at tunnelen blokkerer DHCP. Som oftest har broadcastet aldri hatt noen vei: en ukonfigurert klient sender til 255.255.255.255, og en vanlig IP-ruter videresender ikke den pakken. Tunnelen gjør akkurat det en rutet tunnel gjør.
To utforminger kan endre dette, og de er ikke likeverdige. Den ene bærer broadcastet; den 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. Denne pakken holder seg på sin lenke etter design. En ruter som videresendte den, ville oversvømme hvert segment den betjener.
Derfor kobler en rutet side-til-side-tunnel reléet til en server. Den utvider ikke broadcast-domenet til klienten, og ingen brannmurregel vil få den til det.
Hva en broet tunnel faktisk utvider
En bevisst broet VPN kan bære Ethernet-broadcast innenfor 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 ondsinnet DHCP-server kan nå. Hvis du ikke ville koblet fjernkontoret til samme switch, bør du ikke bro tunnelen bare for å dele ut adresser. Test den påvirkningsradiusen før du aktiverer den.
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 denne reléadressen.
For et illustrerende fjernkontor sitter reléet på kontorets LAN, og serveren nås via stedets VPN. Konfigurer omfanget for dette kontoret, identitetene til reléet og serveren, og hele 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 problem med returveien. Sjekk ruten tilbake til reléadressen før du endrer omfanget.
Hold DHCP atskilt 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. Denne konfliktsjekken er en separat lenkelokal operasjon, ikke transporten for DHCP-meldinger. Å si at DHCP i hovedsak er ARP, er feil; å si at de to aldri har noe med hverandre å gjøre, er for vidt.
En VPN-klient kan også hente tunneladressen sin fra VPN-protokollen eller fra serverens egen pool i stedet for fra et DHCP-broadcast. Et alternativ som inneholder DHCP i navnet, kan beskrive pushede klientinnstillinger, ikke en videresendt DHCP-pakke. Sjekk serverens pool før du antar at DHCP i det hele tatt er involvert.
Noter mottakernettverket, eieren av tildelingen, omfanget, om det finnes et relé, og forventet oppførsel under en avbrudd. Test deretter en ny lease og en fornyelse gjennom denne modellen. Hvis to steder kan betjene den samme ustyrte poolen, har du en konflikt som venter på den første mobile laptopen.