Túnel ativo, sem internet: onde o encaminhamento para

O cliente conecta, o túnel leva pings ao gateway e nada além dele responde. Esse estado é normal para um gateway que só deveria dar acesso a redes protegidas, e é uma falha para um anunciado como saída de túnel completo. Antes de mudar regras, confirme qual serviço foi prometido. Depois siga uma única requisição pública pelos quatro pontos em que ela pode parar. Uma requisição e uma captura de pacotes resolvem mais do que uma página de suposições.

Confirme se a saída para a internet era mesmo o projeto

Um perfil de túnel dividido encaminha apenas as sub-redes protegidas para a VPN, então a navegação pública continua pelo link local e nunca toca o gateway. Um perfil de túnel completo instala uma rota padrão dentro do túnel, o que torna o gateway responsável por todo o caminho. Os dois são projetos legítimos, e confundi-los produz um relatório de falha onde não há nenhuma. Leia as rotas anunciadas pelo cliente antes de testar qualquer outra coisa, porque a tabela de rotas responde à pergunta que o chamado costuma fazer errado.

O que o cliente instala nem sempre é o que o perfil pretende. Uma rota enviada pode ser sobreposta por uma rota local com métrica menor, e um cliente que mantém a rota da LAN ao adicionar uma rota padrão se comporta como um túnel dividido para essa sub-rede.

Siga uma única requisição pública

Escolha um único destino e siga-o do cliente para fora. No cliente, verifique se o pacote realmente escolhe o túnel e qual endereço local usa como origem. Depois verifique o gateway: o pacote chega, e sai pela interface pública. Cada uma dessas respostas elimina uma categoria inteira 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 o gateway nunca vê o pacote, a rota do cliente ou a seleção do túnel está errada. Se ele chega e não sai, o problema está no gateway, e as três verificações restantes se aplicam.

Verifique encaminhamento, rota e tradução

O guia de encaminhamento fornecido com o strongSwan vale para um gateway de qualquer tipo de túnel: o kernel precisa ter permissão para mover pacotes entre interfaces, e uma rota utilizável deve apontar para a internet. A política do firewall deve então permitir o tráfego, e o endereço de origem deve ser um que o lado público consiga responder. Um endereço de cliente privado encaminhado sem alteração para a internet nunca recebe 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 tradução de origem é a peça que costuma faltar. Com ela, o gateway reescreve a origem do cliente para o seu endereço público e acompanha o fluxo; sem ela, a resposta não tem para onde ir. As plataformas de nuvem acrescentam uma segunda fronteira, onde a tabela de rotas ou o grupo de segurança da instância podem descartar tráfego que o firewall convidado permite. Essa fronteira é fácil de passar despercebida porque o sistema convidado parece configurado corretamente por dentro.

A filtragem de caminho reverso em uma configuração assimétrica também pode descartar pacotes válidos. Leia o contador dessa regra em vez de supor que está tudo bem, porque uma configuração rígida na interface pública rejeita o tráfego que chega por um caminho diferente do previsto pela tabela de rotas.

Caminho de resposta e resolvedor são duas respostas diferentes

Observe também a resposta, não apenas a requisição. Se a requisição sai traduzida e a resposta volta ao fluxo traduzido, o encaminhamento funciona mesmo quando a aplicação ainda falha, e a próxima investigação pertence à aplicação ou ao DNS.

Um site que devolve um erro HTTP é prova de que o encaminhamento para a internet funciona. Um nome que não resolve enquanto o acesso por endereço funciona é um problema de resolvedor, não de NAT.

Após uma correção pontual, teste novamente o cliente e qualquer recurso privado restrito de propósito. Conceder acesso à internet não deve ampliar silenciosamente o acesso a todas as redes conectadas ao gateway.