Dirección VPN frente a concesión DHCP de la LAN: ¿quién asigna la IP del túnel?

Conecte el cliente y mire el adaptador en lugar del icono de Wi-Fi. Una dirección como 10.80.0.14 puede estar en un túnel aunque ningún servidor DHCP de la LAN de la oficina haya registrado nunca esa concesión. El proceso que eligió el número decide dónde empieza el diagnóstico.

En el cliente todo parece igual: una dirección IPv4, una máscara, a veces una puerta de enlace predeterminada. La diferencia aparece solo cuando pregunta quién responde por esa dirección y quién guarda un registro de ella.

Lea la dirección del túnel desde el lado del cliente

Windows muestra la distinción si lee todo el bloque y no la primera línea. ipconfig /all imprime una descripción del adaptador, una dirección física y una línea DHCP. Un adaptador de marcación PPP o IKEv2 suele informar DHCP como deshabilitado, porque la conexión negoció su dirección durante la marcación en lugar de tomarla de un servidor de la LAN. Un adaptador de túnel con DHCP habilitado es inusual y merece una investigación aparte.

Linux reparte la misma información entre dos herramientas. ip -4 addr show dev tun0 da la dirección y la longitud del prefijo. nmcli -f IP4 connection show work revela si el valor vino del perfil de conexión, de un intercambio DHCP en el enlace o de una configuración empujada. WireGuard es el caso más claro, porque wg-quick aplica la línea Address del archivo de configuración cuando aparece la interfaz y ningún par asigna nada al conectarse.

El prefijo también dice algo. Un /32, o una máscara de 255.255.255.255, significa que la puerta de enlace espera enrutar a una sola dirección de host, mientras que una máscara más amplia sugiere una subred en el enlace en algún lugar detrás del túnel.

Qué transporta la carga de configuración de IKEv2

IKEv2 tiene un mecanismo dedicado a esta tarea. La carga de configuración descrita en RFC 7296, sección 3.15.1 transporta atributos como INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS y sus equivalentes IPv6. El cliente envía un atributo de longitud cero cuando no tiene preferencia, y el respondedor devuelve el valor que quiere que se use. Ese intercambio viaja dentro de IKE_AUTH, ya cifrado, así que ninguna difusión DHCP cruza nunca el túnel.

Se siguen dos consecuencias. Primera, la dirección la elige el respondedor o cualquier backend de autorización que consulte, y por eso un grupo puede vivir en la puerta de enlace, en una respuesta RADIUS o en un mapeo del proveedor de identidad. Segunda, el atributo DNS está separado del atributo de dirección. Recibir 10.80.0.14 no dice nada sobre qué resolución volvió, ni si volvió alguna.

El atributo de máscara de red es opcional en la práctica. Muchos despliegues devuelven solo una dirección y dejan que el cliente instale una ruta de host, y por eso el mismo grupo puede parecer un /32 en un cliente y un /24 en otro.

Donde chocan un ámbito DHCP de la LAN y un grupo de VPN

El problema empieza cuando ambos asignadores apuntan al mismo rango. Un servidor DHCP para 10.20.30.0/24 no sabe nada de un grupo de VPN configurado para 10.20.30.128/25, así que nada le impide conceder 10.20.30.140 a una impresora mientras la puerta de enlace entrega la misma dirección a un cliente remoto. El choque permanece silencioso durante días y luego aparece como un duplicado intermitente.

Un diseño enrutado de sitio a sitio evita el choque por construcción. Un host en la sucursal conserva la dirección que le dio su servidor DHCP local. Las interfaces de túnel de ambas puertas de enlace llevan sus propias direcciones de enlace, y la tabla de rutas decide cómo viajan los paquetes. Las direcciones de los clientes de acceso remoto son una tercera categoría y no deben mezclarse con las direcciones de enlace de la puerta de enlace.

Puentear el túnel hacia la LAN elimina esa separación. Si el diseño necesita de verdad un solo dominio de difusión, el extremo de la VPN tiene que participar en las mismas decisiones de asignación que el servidor DHCP, mediante un relé o una fuente autoritativa compartida, en lugar de emitir direcciones por su cuenta.

Verifique qué proceso posee la dirección

Demuestre la propiedad antes de cambiar un ámbito. En el cliente, anote la dirección y el prefijo. En la LAN, busque en la base de datos de concesiones. En la puerta de enlace, liste los grupos que está configurada para repartir. Una dirección hallada en el archivo de concesiones pertenece a un servidor DHCP, lo que significa que el túnel está puenteado o relayado; una dirección hallada solo en el grupo de la puerta de enlace pertenece al extremo del túnel.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Anote cuatro cosas cuando la respuesta esté clara: qué componente asigna la dirección del cliente, qué rango está reservado para ella, cómo llega el tráfico de vuelta a ese rango y qué recursos la aceptan. Esas cuatro entradas convierten una línea de adaptador virtual en un hecho operativo.

Repita la comprobación del atributo DNS mientras está allí. Un grupo que reparte direcciones pero ningún resolutor deja al cliente en su DNS local, lo que es un fallo distinto de un grupo que reparte una dirección que la LAN ya usa.