La VPN del router funciona, pero los clientes de la LAN no tienen internet

El estado dice que el túnel está activo, un navegador en el propio router carga páginas y cada dispositivo detrás de él sigue agotando el tiempo de espera. Esa combinación reduce el problema a una capa que la mayoría de las guías de VPN nunca mencionan: el router no es el único host cuyos paquetes deben sobrevivir al túnel. El tráfico generado localmente y el tráfico reenviado toman caminos distintos por la misma caja. Pruebe desde un cliente y la diferencia deja de ser teórica.

Lea el fallo desde un host de la LAN

Empiece por el dispositivo que falla, porque un diagnóstico en el router responde a otra pregunta. Confirme que la puerta de enlace predeterminada del cliente es este router, anote su dirección de origen y su subred, y después mire qué sale de la interfaz del túnel del router.

Si la dirección del cliente se traduce, el lado remoto ve la dirección del túnel y desde allí todo parece sano mientras el cliente sigue fallando. Si no se traduce, el lado remoto debe conocer una ruta de vuelta a la subred del cliente, y muchas puertas de enlace no tienen esa ruta por defecto. En ambos casos el éxito del router es irrelevante, porque sus paquetes se generaron localmente y nunca recorrieron la ruta de reenvío.

El tráfico local y el tráfico reenviado son distintos

Linux y la mayoría del firmware de router tratan los paquetes originados por la propia caja de forma distinta a los paquetes que la atraviesan. La cadena output ve los primeros, la cadena forward ve los segundos, y una política ajustada al tráfico propio del router puede dejar el reenvío intacto.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Compruebe si el reenvío está activado siquiera y luego lea la cadena forward en lugar de la cadena output. Una regla que permite la conexión exterior cifrada no es una regla que permita reenviar paquetes descifrados, y confundir ambas produce exactamente este síntoma. Que el túnel esté activo solo demuestra lo primero.

La ruta de retorno también debe existir

La traducción de origen decide si hace falta una ruta de retorno. Con enmascaramiento en la interfaz del túnel, las respuestas vuelven a la dirección del túnel y el router las destraduce. Sin él, la puerta de enlace remota necesita una ruta explícita a la subred del cliente, y su propia política debe permitir esa dirección.

Anote cuál de los dos diseños usa el despliegue antes de cambiar nada, porque las reparaciones apuntan en direcciones opuestas. Añadir traducción oculta una ruta de retorno ausente y rompe aplicaciones que necesitan la dirección de origen original. Añadir una ruta de retorno sin traducción falla en silencio cuando el cortafuegos remoto descarta el origen desconocido. Elija uno, documéntelo y haga que el otro lado coincida.

El DNS del cliente pertenece a la misma revisión. El resolutor del router puede responder mientras un cliente apuntado a otro servidor no obtiene nada en absoluto.

Verifique un flujo permitido y un flujo denegado

Tras la corrección, pruebe una conexión nueva desde un cliente en lugar de una sesión existente del router. Después confirme que un segmento que no debería usar el túnel sigue sin usarlo.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Compruebe la dirección de origen observada en el extremo remoto, porque le dice qué diseño se está ejecutando realmente. Verifique también una consulta de nombre además de una dirección, porque el comportamiento del resolutor es un camino separado por la misma caja.

Mantenga las reglas limitadas a las redes de clientes que necesitan el túnel y resista la tentación de desactivar el filtro de reenvío para que pase una prueba. Ese cambio repara la prueba y elimina la frontera que el túnel debía proporcionar. Escriba la dirección de origen, la decisión de traducción y la ruta de retorno en una sola nota, con fecha.