Túnel activo, sin internet: dónde se detiene el reenvío

El cliente se conecta, el túnel lleva pings a la puerta de enlace y nada más allá responde. Ese estado es normal en una puerta de enlace que solo debía dar acceso a redes protegidas, y es un fallo en una que se anuncia como salida de túnel completo. Antes de cambiar reglas, confirme qué servicio se prometió. Después siga una sola petición pública por los cuatro puntos donde puede detenerse. Una petición y una captura de paquetes resuelven más que una página de conjeturas.

Confirme si la salida a internet fue alguna vez el diseño

Un perfil de túnel dividido solo envía las subredes protegidas al VPN, así que la navegación pública sigue por el enlace local y nunca toca la puerta de enlace. Un perfil de túnel completo instala una ruta predeterminada dentro del túnel, lo que hace que la puerta de enlace sea responsable de todo el trayecto. Ambos son diseños legítimos, y confundirlos produce un informe de fallo donde no lo hay. Lea las rutas anunciadas por el cliente antes de probar cualquier otra cosa, porque la tabla de rutas responde la pregunta que el ticket suele plantear mal.

Lo que instala el cliente no siempre es lo que pretende el perfil. Una ruta empujada puede quedar anulada por una ruta local con menor métrica, y un cliente que conserva su ruta de LAN mientras añade una ruta predeterminada se comporta como un túnel dividido para esa subred.

Siga una sola petición pública

Elija un único destino y sígalo desde el cliente hacia fuera. En el cliente, compruebe que el paquete elige realmente el túnel y qué dirección local usa como origen. Después revise la puerta de enlace: si el paquete llega y si sale por la interfaz pública. Cada una de esas respuestas elimina una categoría entera de causas.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Si la puerta de enlace nunca ve el paquete, la ruta del cliente o la selección del túnel están mal. Si llega y no sale, el problema está en la puerta de enlace, y se aplican las tres comprobaciones restantes.

Revise reenvío, ruta y traducción

La guía de reenvío que se distribuye con strongSwan sirve para una puerta de enlace de cualquier tipo de túnel: el núcleo debe poder mover paquetes entre interfaces, y una ruta utilizable debe apuntar hacia internet. La política del cortafuegos debe permitir después el tráfico, y la dirección de origen debe ser una que el lado público pueda responder. Una dirección de cliente privada reenviada sin cambios hacia internet nunca recibe respuesta.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

La traducción de origen es la pieza que suele faltar. Con ella, la puerta de enlace reescribe el origen del cliente a su dirección pública y sigue el flujo; sin ella, la respuesta no tiene adónde ir. Las plataformas en la nube añaden un segundo límite, donde la tabla de rutas o el grupo de seguridad de la instancia pueden descartar tráfico que el cortafuegos invitado permite. Ese límite es fácil de pasar por alto porque el sistema invitado parece bien configurado desde dentro.

El filtrado de ruta inversa en una configuración asimétrica también puede descartar paquetes válidos. Lea el contador de esa regla en lugar de suponer que está bien, porque un ajuste estricto en la interfaz pública rechaza el tráfico que llega por una ruta distinta de la que predice la tabla de rutas.

Ruta de respuesta y resolución son dos respuestas distintas

Vigile también la respuesta, no solo la petición. Si la petición sale traducida y la respuesta vuelve al flujo traducido, el reenvío funciona aunque la aplicación siga fallando, y la siguiente investigación corresponde a la aplicación o al DNS.

Un sitio que devuelve un error HTTP es prueba de que el reenvío a internet funciona. Un nombre que no resuelve mientras el acceso por dirección funciona es un problema de resolución, no de NAT.

Tras una corrección precisa, vuelva a probar el cliente y también cualquier recurso privado restringido a propósito. Conceder acceso a internet no debe ampliar en silencio el acceso a todas las redes conectadas a la puerta de enlace.