DHCP a través dunha VPN: ¿pontear o broadcast ou retransmitilo?

Un portátil novo ao outro lado do túnel non obtén enderezo, mentres que o mesmo portátil funciona na sede central. A primeira sospeita habitual é que o túnel bloquea DHCP. Máis a miúdo o broadcast nunca tivo camiño: un cliente sen configurar envía a 255.255.255.255, e un encamiñador IP corrente non reenvía ese paquete. O túnel fai exactamente o que fai un túnel encamiñado.

Dous deseños poden cambialo, e non son equivalentes. Un transporta o broadcast; o outro retransmite a petición.

O broadcast nunca cruza o encamiñador

Un cliente DHCPv4 sen enderezo envía desde 0.0.0.0 ao enderezo de broadcast limitado nos portos UDP 67 e 68. Ese paquete queda na súa ligazón por deseño. Un encamiñador que o reenviase estaría a inundar cada segmento que atende.

Así, un túnel encamiñado de sitio a sitio conecta o retransmisor cun servidor. Non amplía o dominio de broadcast do cliente, e ningunha regra de cortalumes o fará.

Que amplía realmente un túnel ponteado

Unha VPN ponteada deliberadamente pode transportar broadcast Ethernet dentro da súa topoloxía admitida, e entón DHCP pode cruzar como tráfico local. É unha opción real, pero é unha decisión de deseño de capa 2. Está a ampliar o dominio de fallo e o límite de acceso xunto co broadcast.

A ponte tamén cambia a que poden chegar unha tormenta de broadcast, un varrido ARP ou un servidor DHCP fraudulento. Se non conectaría a oficina remota ao mesmo conmutador, non pontee o túnel só para repartir enderezos. Probe ese raio de impacto antes de activalo.

É unha decisión maior ca a de fornecer un enderezo, e debe tomarse deliberadamente.

Retransmita a petición no seu lugar

A resposta habitual é un retransmisor na rede local do cliente. Recibe o broadcast, convérteo nunha petición unicast e pon o seu propio enderezo no campo de enderezo de pasarela. O servidor responde a ese enderezo do retransmisor.

Para unha oficina remota ilustrativa, o retransmisor sitúase na LAN da oficina e chégase ao servidor pola VPN do sitio. Configure o ámbito para esa oficina, as identidades do retransmisor e do servidor, e a ruta de retorno completa. Permitir UDP 67 polo túnel non lle di ao servidor que conxunto debe usar.

Un retransmisor que reenvía pero nunca recibe resposta adoita ser un problema de ruta de retorno. Comprobe a ruta de volta ao enderezo do retransmisor antes de cambiar o ámbito.

Separe DHCP de ARP e do enderezo do túnel

DHCP viaxa sobre UDP/IP. En Ethernet, un host tamén pode usar ARP para comprobar se un enderezo candidato xa está en uso. Esa comprobación de conflito é unha operación local á ligazón aparte, non o transporte das mensaxes DHCP. Dicir que DHCP é esencialmente ARP é incorrecto; dicir que os dous nunca se relacionan é demasiado amplo.

Un cliente VPN tamén pode obter o seu enderezo de túnel do protocolo VPN ou do propio conxunto do servidor en lugar dun broadcast DHCP. Unha opción cuxo nome conteña DHCP pode describir axustes do cliente empuxados, non un paquete DHCP retransmitido. Comprobe o conxunto do servidor antes de supor que DHCP intervén.

Anote a rede destinataria, o propietario da asignación, o ámbito, se existe un retransmisor e o comportamento esperado durante unha caída. Despois probe unha concesión nova e unha renovación con ese modelo. Se dous sitios poden servir o mesmo conxunto non xestionado, ten un conflito agardando o primeiro portátil itinerante.