DHCP a través de una VPN: ¿puentear el broadcast o retransmitirlo?

Un portátil nuevo al otro lado del túnel no obtiene dirección, mientras que el mismo portátil funciona en la sede central. La primera sospecha habitual es que el túnel bloquea DHCP. Más a menudo el broadcast nunca tuvo camino: un cliente sin configurar envía a 255.255.255.255, y un enrutador IP corriente no reenvía ese paquete. El túnel hace exactamente lo que hace un túnel enrutado.

Dos diseños pueden cambiarlo, y no son equivalentes. Uno transporta el broadcast; el otro retransmite la petición.

El broadcast nunca cruza el enrutador

Un cliente DHCPv4 sin dirección envía desde 0.0.0.0 a la dirección de broadcast limitado en los puertos UDP 67 y 68. Ese paquete se queda en su enlace por diseño. Un enrutador que lo reenviara estaría inundando cada segmento que atiende.

Así, un túnel enrutado de sitio a sitio conecta el retransmisor con un servidor. No amplía el dominio de broadcast del cliente, y ninguna regla de cortafuegos lo hará.

Qué amplía realmente un túnel puenteado

Una VPN puenteada deliberadamente puede transportar broadcast Ethernet dentro de su topología admitida, y entonces DHCP puede cruzar como tráfico local. Es una opción real, pero es una decisión de diseño de capa 2. Está ampliando el dominio de fallo y el límite de acceso junto con el broadcast.

El puenteo también cambia a qué pueden llegar una tormenta de broadcast, un barrido ARP o un servidor DHCP fraudulento. Si no conectaría la oficina remota al mismo conmutador, no puentee el túnel solo para repartir direcciones. Pruebe ese radio de impacto antes de activarlo.

Es una decisión mayor que la de suministrar una dirección, y debe tomarse deliberadamente.

Retransmita la petición en su lugar

La respuesta habitual es un retransmisor en la red local del cliente. Recibe el broadcast, lo convierte en una petición unicast y pone su propia dirección en el campo de dirección de puerta de enlace. El servidor responde a esa dirección del retransmisor.

Para una oficina remota ilustrativa, el retransmisor se sitúa en la LAN de la oficina y se llega al servidor por la VPN del sitio. Configure el ámbito para esa oficina, las identidades del retransmisor y del servidor, y la ruta de retorno completa. Permitir UDP 67 por el túnel no le dice al servidor qué conjunto debe usar.

Un retransmisor que reenvía pero nunca recibe respuesta suele ser un problema de ruta de retorno. Compruebe la ruta de vuelta a la dirección del retransmisor antes de cambiar el ámbito.

Separe DHCP de ARP y del direccionamiento del túnel

DHCP viaja sobre UDP/IP. En Ethernet, un host también puede usar ARP para comprobar si una dirección candidata ya está en uso. Esa comprobación de conflicto es una operación local al enlace aparte, no el transporte de los mensajes DHCP. Decir que DHCP es esencialmente ARP es incorrecto; decir que los dos nunca se relacionan es demasiado amplio.

Un cliente VPN también puede obtener su dirección de túnel del protocolo VPN o del propio conjunto del servidor en lugar de un broadcast DHCP. Una opción cuyo nombre contenga DHCP puede describir ajustes del cliente empujados, no un paquete DHCP retransmitido. Compruebe el conjunto del servidor antes de suponer que DHCP interviene.

Anote la red destinataria, el propietario de la asignación, el ámbito, si existe un retransmisor y el comportamiento esperado durante una caída. Después pruebe una concesión nueva y una renovación con ese modelo. Si dos sitios pueden servir el mismo conjunto no gestionado, tiene un conflicto esperando al primer portátil itinerante.