A VPN do router funciona, pero os clientes da LAN non teñen internet

O estado di que o túnel está activo, un navegador no propio router carga páxinas e cada dispositivo detrás del segue esgotando o tempo de espera. Esa combinación reduce o problema a unha capa que a maioría das guías de VPN nunca mencionan: o router non é o único host cuxos paquetes deben sobrevivir ao túnel. O tráfico xerado localmente e o tráfico reenviado percorren camiños distintos pola mesma caixa. Probe desde un cliente e a diferenza deixa de ser teórica.

Lea o fallo desde un host da LAN

Comece polo dispositivo que falla, porque un diagnóstico no router responde a outra pregunta. Confirme que a pasarela predeterminada do cliente é este router, anote o seu enderezo de orixe e a súa subrede, e despois mire que sae da interface do túnel do router.

Se o enderezo do cliente se traduce, o lado remoto ve o enderezo do túnel, e desde alí todo parece san mentres o cliente segue fallando. Se non se traduce, o lado remoto debe coñecer unha ruta de volta á subrede do cliente, e moitas pasarelas non teñen esa ruta por defecto. En ambos os casos o éxito do router é irrelevante, porque os seus paquetes xeráronse localmente e nunca percorreron o camiño do reenvío.

O tráfico local e o tráfico reenviado son distintos

Linux e a maioría do firmware de router tratan os paquetes orixinados pola propia caixa de forma distinta aos paquetes que a atravesan. A cadea output ve os primeiros, a cadea forward ve os segundos, e unha política axustada ao tráfico propio do router pode deixar o 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'

Comprobe se o reenvío está activado sequera e despois lea a cadea forward en lugar da cadea output. Unha regra que permite a conexión exterior cifrada non é unha regra que permita reenviar paquetes descifrados, e confundir ambas produce exactamente este síntoma. Que o túnel estea activo só demostra o primeiro.

A ruta de retorno tamén debe existir

A tradución de orixe decide se fai falta unha ruta de retorno. Co enmascaramento na interface do túnel, as respostas volven ao enderezo do túnel e o router desfai a tradución. Sen el, a pasarela remota necesita unha ruta explícita á subrede do cliente, e a súa propia política debe permitir esa dirección.

Anote cal dos dous deseños usa o despregamento antes de cambiar nada, porque as reparacións apuntan en direccións opostas. Engadir tradución agocha unha ruta de retorno ausente e rompe aplicacións que necesitan o enderezo de orixe orixinal. Engadir unha ruta de retorno sen tradución falla en silencio cando a devasa remota descarta a orixe descoñecida. Escolla un, documénteo e faga que o outro lado coincida.

O DNS do cliente pertence á mesma revisión. O resolutor do router pode responder mentres un cliente apuntado a outro servidor non obtén nada de nada.

Verifique un fluxo permitido e un fluxo denegado

Tras a corrección, probe unha conexión nova desde un cliente en lugar dunha sesión existente do router. Despois confirme que un segmento que non debería usar o túnel segue sen usalo.

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

Comprobe o enderezo de orixe observado no extremo remoto, porque lle di que deseño se está executando realmente. Verifique tamén unha consulta de nome ademais dun enderezo, porque o comportamento do resolutor é un camiño separado pola mesma caixa.

Manteña as regras limitadas ás redes de clientes que necesitan o túnel, e resista a tentación de desactivar o filtro de reenvío para que pase unha proba. Ese cambio repara a proba e elimina a fronteira que o túnel debía proporcionar. Escriba o enderezo de orixe, a decisión de tradución e a ruta de retorno nunha soa nota, con data.