DHCP per VPN: estendre el broadcast amb pont o retransmetre’l?

Un portàtil nou a l’altre costat del túnel no obté cap adreça, mentre que el mateix portàtil funciona a la seu central. La primera sospita habitual és que el túnel bloqueja DHCP. Més sovint el broadcast no ha tingut mai camí: un client no configurat envia a 255.255.255.255, i un encaminador IP ordinari no reenvia aquest paquet. El túnel fa exactament el que fa un túnel encaminat.

Dos dissenys poden canviar-ho, i no són equivalents. Un porta el broadcast; l’altre retransmet la petició.

El broadcast no travessa mai l’encaminador

Un client DHCPv4 sense adreça envia des de 0.0.0.0 a l’adreça de broadcast limitat als ports UDP 67 i 68. Aquest paquet es queda al seu enllaç per disseny. Un encaminador que el reenviés inundaria cada segment que serveix.

Així, un túnel encaminat de seu a seu connecta el retransmissor amb un servidor. No amplia el domini de broadcast del client, i cap regla de tallafocs ho farà.

Què amplia realment un túnel amb pont

Una VPN pontada deliberadament pot portar broadcast Ethernet dins de la seva topologia suportada, i llavors DHCP pot travessar com a trànsit local. És una opció real, però és una decisió de disseny de capa 2. Amplieu el domini de fallada i la frontera d’accés juntament amb el broadcast.

El pont també canvia a què poden arribar una tempesta de broadcast, un escombrat ARP o un servidor DHCP fraudulent. Si no connectaríeu l’oficina remota al mateix commutador, no pontueu el túnel només per repartir adreces. Proveu aquest radi d’impacte abans d’activar-lo.

És una decisió més gran que la de subministrar una adreça, i s’ha de prendre deliberadament.

Retransmeteu la petició en lloc d’això

La resposta habitual és un retransmissor a la xarxa local del client. Rep el broadcast, el converteix en una petició unicast i posa la seva pròpia adreça al camp d’adreça de porta d’enllaç. El servidor respon a aquesta adreça del retransmissor.

Per a una oficina remota il·lustrativa, el retransmissor se situa a la LAN de l’oficina i s’arriba al servidor per la VPN del lloc. Configureu l’àmbit per a aquesta oficina, les identitats del retransmissor i del servidor, i el camí de tornada complet. Permetre UDP 67 pel túnel no diu al servidor quin conjunt ha d’utilitzar.

Un retransmissor que reenvia però mai no rep resposta sol ser un problema de camí de tornada. Comproveu la ruta de tornada a l’adreça del retransmissor abans de canviar l’àmbit.

Separeu DHCP d’ARP i de l’adreçament del túnel

DHCP circula sobre UDP/IP. A Ethernet, un equip també pot fer servir ARP per comprovar si una adreça candidata ja és en ús. Aquesta comprovació de conflicte és una operació local a l’enllaç separada, no el transport dels missatges DHCP. Dir que DHCP és essencialment ARP és incorrecte; dir que els dos no es relacionen mai és massa ampli.

Un client VPN també pot obtenir la seva adreça de túnel del protocol VPN o del propi conjunt del servidor en lloc d’un broadcast DHCP. Una opció amb DHCP al nom pot descriure paràmetres del client empenyats, no un paquet DHCP retransmès. Comproveu el conjunt del servidor abans de suposar que DHCP hi intervé.

Anoteu la xarxa destinatària, el propietari de l’assignació, l’àmbit, si hi ha retransmissor i el comportament esperat durant una caiguda. Després proveu una concessió nova i una renovació amb aquest model. Si dos llocs poden servir el mateix conjunt no gestionat, teniu un conflicte esperant el primer portàtil itinerant.