A VPN do router funciona, mas os clientes LAN ficam sem internet

O estado diz que o túnel está ativo, um navegador no próprio router carrega páginas, e cada dispositivo atrás dele continua a expirar. Essa combinação reduz o problema a uma camada que a maioria dos guias de VPN nunca menciona: o router não é o único host cujos pacotes precisam de sobreviver ao túnel. O tráfego gerado localmente e o tráfego reencaminhado seguem caminhos diferentes pela mesma caixa. Teste a partir de um cliente e a diferença deixa de ser teórica.

Leia a falha a partir de um host LAN

Comece pelo dispositivo que falha, porque um diagnóstico executado no router responde a outra pergunta. Confirme que o gateway predefinido do cliente é este router, anote o endereço de origem e a sub-rede, e depois veja o que sai da interface de túnel do router.

Se o endereço do cliente for traduzido, o lado remoto vê o endereço do túnel, e daí tudo parece saudável enquanto o cliente continua a falhar. Se não for traduzido, o lado remoto tem de conhecer uma rota de volta para a sub-rede do cliente, e muitos gateways não têm essa rota por predefinição. De qualquer forma, o sucesso do próprio router é irrelevante, porque os seus pacotes foram gerados localmente e nunca percorreram o caminho de reencaminhamento.

Tráfego local e tráfego reencaminhado são diferentes

O Linux e a maioria do firmware de routers tratam os pacotes originados pela caixa de forma diferente dos pacotes que a atravessam. A cadeia output vê o primeiro tipo, a cadeia forward vê o segundo, e uma política ajustada ao tráfego do próprio router pode deixar o reencaminhamento 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'

Verifique se o reencaminhamento está sequer ativado, e depois leia a cadeia forward em vez da cadeia output. Uma regra que permite a ligação externa cifrada não é uma regra que permite reencaminhar pacotes decifrados, e confundir as duas produz exatamente este sintoma. O túnel estar ativo prova apenas a primeira.

A rota de retorno também tem de existir

A tradução de origem decide se é necessária uma rota de retorno. Com masquerading na interface de túnel, as respostas voltam para o endereço do túnel e o router desfaz a tradução. Sem isso, o gateway remoto precisa de uma rota explícita para a sub-rede do cliente, e a sua própria política tem de permitir esse sentido.

Registe qual dos dois desenhos a implementação usa antes de alterar qualquer coisa, porque as reparações apontam em direções opostas. Acrescentar tradução esconde uma rota de retorno em falta e quebra aplicações que precisam do endereço de origem original. Acrescentar uma rota de retorno sem tradução falha em silêncio quando a firewall remota descarta a origem desconhecida. Escolha um, documente-o e faça o outro lado corresponder.

O DNS dos clientes pertence à mesma revisão. O resolver do router pode responder enquanto um cliente apontado a outro servidor não recebe nada.

Verifique um fluxo permitido e um fluxo negado

Depois da correção, teste uma nova ligação a partir de um cliente em vez de uma sessão existente do router. Confirme depois que um segmento que não deve usar o túnel continua a não o usar.

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

Verifique o endereço de origem observado no extremo remoto, porque isso diz qual desenho está realmente a correr. Verifique também a resolução de nomes além do endereço, porque o comportamento do resolver é um caminho separado pela mesma caixa.

Mantenha as regras limitadas às redes de clientes que precisam do túnel, e resista à tentação de desativar o filtro de reencaminhamento para um teste passar. Essa alteração repara o teste e remove a fronteira que o túnel devia fornecer. Escreva o endereço de origem, a decisão de tradução e a rota de retorno numa única nota, com data.