DHCP prin VPN: punte pentru broadcast sau redirecționare?
Clienții de pe cealaltă parte a unui tunel nu primesc adresă. Decideți dacă transportați broadcastul sau îl redirecționați, și țineți DHCP separat de ARP.
Un laptop nou de pe cealaltă parte a tunelului nu primește adresă, în timp ce același laptop funcționează la sediul central. Prima presupunere obișnuită este că tunelul blochează DHCP. Mai des broadcastul nu a avut niciodată o cale: un client neconfigurat trimite către 255.255.255.255, iar un router IP obișnuit nu redirecționează acel pachet. Tunelul face exact ce face un tunel rutat.
Două proiecte pot schimba asta, și nu sunt echivalente. Unul transportă broadcastul; celălalt redirecționează cererea.
Broadcastul nu traversează niciodată routerul
Un client DHCPv4 fără adresă trimite de la 0.0.0.0 către adresa de broadcast limitat pe porturile UDP 67 și 68. Acel pachet rămâne pe legătura sa prin proiectare. Un router care l-ar redirecționa ar inunda fiecare segment pe care îl deservește.
Așadar, un tunel rutat de la site la site conectează releul la un server. Nu extinde domeniul de broadcast al clientului, și nicio regulă de firewall nu va face asta.
Ce extinde de fapt un tunel punte
Un VPN punte în mod deliberat poate transporta broadcast Ethernet în topologia sa acceptată, iar atunci DHCP poate trece ca trafic local. Este o opțiune reală, dar este o decizie de proiectare de nivel 2. Extindeți domeniul de eșec și limita de acces odată cu broadcastul.
Puntea schimbă și ce pot atinge o furtună de broadcast, o scanare ARP sau un server DHCP rău intenționat. Dacă nu ați conecta biroul la distanță la același switch, nu punte tunelul doar pentru a distribui adrese. Testați acea rază de impact înainte de a-l activa.
Este o decizie mai mare decât furnizarea unei adrese și ar trebui luată deliberat.
Redirecționați cererea în schimb
Răspunsul obișnuit este un releu în rețeaua locală a clientului. Primește broadcastul, îl transformă într-o cerere unicast și pune propria adresă în câmpul de adresă al gateway-ului. Serverul răspunde la acea adresă a releului.
Pentru un birou la distanță ilustrativ, releul stă în LAN-ul biroului, iar serverul este accesat prin VPN-ul site-ului. Configurați domeniul pentru acel birou, identitățile releului și ale serverului, și calea completă de întoarcere. Permiterea UDP 67 prin tunel nu îi spune serverului ce pool să folosească.
Un releu care redirecționează dar nu primește niciodată un răspuns este de obicei o problemă de cale de întoarcere. Verificați ruta înapoi la adresa releului înainte de a schimba domeniul.
Separați DHCP de ARP și de adresarea tunelului
DHCP circulă peste UDP/IP. În Ethernet, un host poate folosi și ARP pentru a verifica dacă o adresă candidată este deja utilizată. Acea verificare de conflict este o operațiune locală la legătură separată, nu transportul mesajelor DHCP. A spune că DHCP este în esență ARP este greșit; a spune că cele două nu au niciodată legătură este prea larg.
Un client VPN poate obține adresa tunelului și din protocolul VPN sau din pool-ul propriu al serverului, în loc de un broadcast DHCP. O opțiune al cărei nume conține DHCP poate descrie setări ale clientului împinse, nu un pachet DHCP redirecționat. Verificați pool-ul serverului înainte de a presupune că DHCP este implicat.
Notați rețeaua destinatară, proprietarul alocării, domeniul, dacă există un releu și comportamentul așteptat în timpul unei întreruperi. Apoi testați o închiriere nouă și o reînnoire prin acel model. Dacă două site-uri pot deservi același pool negestionat, aveți un conflict care așteaptă primul laptop itinerant.