Túnel activo, sen internet: onde se detén o reenvío

O cliente conecta, o túnel leva pings á pasarela e nada máis alá responde. Ese estado é normal nunha pasarela que só debía dar acceso a redes protexidas, e é unha avaría nunha que se anuncia como saída de túnel completo. Antes de cambiar regras, confirme que servizo se prometeu. Despois siga unha única petición pública polos catro puntos onde se pode deter. Unha petición e unha captura de paquetes resolven máis que unha páxina de suposicións.

Confirme se a saída a internet foi algunha vez o deseño

Un perfil de túnel dividido só encamiña as subredes protexidas cara á VPN, así que a navegación pública continúa polo enlace local e nunca toca a pasarela. Un perfil de túnel completo instala unha ruta por defecto dentro do túnel, o que fai a pasarela responsable de todo o camiño. Ambos son deseños lexítimos, e confundilos produce un informe de avaría onde non o hai. Lea as rutas anunciadas polo cliente antes de probar calquera outra cousa, porque a táboa de rutas responde a pregunta que o ticket adoita formular mal.

O que instala o cliente non sempre é o que pretende o perfil. Unha ruta enviada pode quedar anulada por unha ruta local cunha métrica máis baixa, e un cliente que conserva a súa ruta de LAN mentres engade unha ruta por defecto compórtase como un túnel dividido para esa subrede.

Siga unha soa petición pública

Escolla un único destino e ségao desde o cliente cara a fóra. No cliente, comprobe que o paquete escolle realmente o túnel e que enderezo local usa como orixe. Despois revise a pasarela: se o paquete chega e se sae pola interface pública. Cada unha desas respostas elimina unha categoría enteira 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

Se a pasarela nunca ve o paquete, a ruta do cliente ou a selección do túnel son incorrectas. Se chega e non sae, o problema está na pasarela, e aplícanse as tres comprobacións restantes.

Revise reenvío, ruta e tradución

A guía de reenvío que se entrega con strongSwan vale para unha pasarela de calquera tipo de túnel: o núcleo debe poder mover paquetes entre interfaces, e unha ruta utilizábel debe apuntar cara a internet. A política da devasa debe permitir despois o tráfico, e o enderezo de orixe debe ser un que o lado público poida responder. Un enderezo de cliente privado reenviado sen cambios cara a internet nunca recibe resposta.

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

A tradución de orixe é a peza que adoita faltar. Con ela, a pasarela reescribe a orixe do cliente cara ao seu enderezo público e segue o fluxo; sen ela, a resposta non ten onde ir. As plataformas na nube engaden un segundo límite, onde a táboa de rutas ou o grupo de seguridade da instancia poden descartar tráfico que a devasa convidada permite. Ese límite é fácil de pasar por alto porque o sistema convidado parece ben configurado desde dentro.

O filtrado de ruta inversa nunha configuración asimétrica tamén pode descartar paquetes válidos. Lea o contador desa regra en lugar de supor que está ben, porque un axuste estrito na interface pública rexeita o tráfico que chega por un camiño distinto do que predí a táboa de rutas.

Ruta de resposta e resolución son dúas respostas distintas

Vixíe tamén a resposta, non só a petición. Se a petición sae traducida e a resposta volve ao fluxo traducido, o reenvío funciona aínda que a aplicación siga fallando, e a seguinte investigación corresponde á aplicación ou ao DNS.

Un sitio que devolve un erro HTTP é proba de que o reenvío a internet funciona. Un nome que non resolve mentres o acceso por enderezo funciona é un problema de resolución, non de NAT.

Tras unha corrección precisa, volva probar o cliente e mais calquera recurso privado restrinxido a propósito. Conceder acceso a internet non debe ampliar en silencio o acceso a todas as redes conectadas á pasarela.