DHCP gennem en VPN: skal broadcastet broes eller videresendes?
Klienter på den anden side af en tunnel får ingen adresse. Beslut om broadcastet skal bæres eller videresendes, og hold DHCP adskilt fra ARP.
En ny laptop på den anden side af tunnelen får ingen adresse, mens den samme laptop virker på hovedkontoret. Det sædvanlige første gæt er, at tunnelen blokerer DHCP. Oftere har broadcastet aldrig haft en vej: en ukonfigureret klient sender til 255.255.255.255, og en almindelig IP-router videresender ikke den pakke. Tunnelen gør præcis det, en routet tunnel gør.
To designs kan ændre det, og de er ikke ensbetydende. Det ene bærer broadcastet; det andet videresender anmodningen.
Broadcastet krydser aldrig routeren
En DHCPv4-klient uden adresse sender fra 0.0.0.0 til den begrænsede broadcast-adresse på UDP-portene 67 og 68. Den pakke bliver på sit link af design. En router, der videresendte den, ville oversvømme hvert segment, den betjener.
Så en routet site-til-site-tunnel forbinder relæet med en server. Den udvider ikke klientens broadcast-domæne, og ingen firewall-regel får den til det.
Hvad en broet tunnel faktisk udvider
En bevidst broet VPN kan bære Ethernet-broadcast under sin understøttede topologi, og så kan DHCP passere som lokal trafik. Det er en reel mulighed, men det er et designvalg på lag 2. Du udvider fejldomænet og adgangsgrænsen sammen med broadcastet.
Broing ændrer også, hvad en broadcast-storm, en ARP-scanning eller en falsk DHCP-server kan nå. Hvis du ikke ville tilslutte fjernkontoret til samme switch, skal du ikke bro tunnelen bare for at uddele adresser. Test den radius, før du aktiverer det.
Det er en større beslutning end at udlevere en adresse, og den bør træffes bevidst.
Videresend anmodningen i stedet
Det sædvanlige svar er et relæ på klientens lokale netværk. Det modtager broadcastet, omdanner det til en unicast-anmodning og sætter sin egen adresse i gateway-adressefeltet. Serveren svarer til den relæadresse.
For et illustrativt fjernkontor sidder relæet på kontorets LAN, og serveren nås over stedets VPN. Konfigurer scopet for det kontor, relæets og serverens identiteter og den fulde returvej. At tillade UDP 67 gennem tunnelen fortæller ikke serveren, hvilken pulje der skal bruges.
Et relæ, der videresender, men aldrig modtager et svar, er normalt et returvejsproblem. Kontroller ruten tilbage til relæadressen, før du ændrer scopet.
Adskil DHCP fra ARP og fra tunneladressering
DHCP kører over UDP/IP. På Ethernet kan en vært også bruge ARP til at kontrollere, om en kandidatadresse allerede er i brug. Den konfliktkontrol er en separat linklokal operation, ikke transporten for DHCP-beskeder. At sige, at DHCP i det væsentlige er ARP, er forkert; at sige, at de to aldrig har med hinanden at gøre, er for bredt.
En VPN-klient kan også få sin tunneladresse fra VPN-protokollen eller serverens egen pulje i stedet for fra et DHCP-broadcast. En indstilling, hvis navn indeholder DHCP, kan beskrive push'ede klientindstillinger, ikke en videresendt DHCP-pakke. Kontroller serverens pulje, før du antager, at DHCP overhovedet er involveret.
Noter modtagernetværket, tildelingens ejer, scopet, om der findes et relæ, og den forventede adfærd under et udfald. Test derefter en ny lease og en fornyelse gennem den model. Hvis to steder kan betjene den samme ikke-styrede pulje, har du en konflikt, der venter på den første mobile laptop.