Conectado ao OpenVPN mas nada carrega: um percurso a partir do cliente

A janela do cliente diz Conectado, o endereço do túnel está lá, e o navegador continua girando. Essa combinação é normal, porque um handshake bem-sucedido só prova que o túnel foi construído; ele não diz nada sobre o servidor encaminhar seus pacotes, reescrever a origem deles ou responder às suas consultas DNS. O erro que a maioria comete é abrir primeiro a configuração do servidor. Em vez disso, avance do cliente para fora, porque cada passo abaixo diz se o próximo sequer vale a pena verificar.

Comece no cliente e avance para fora

Faça três testes nesta ordem e anote onde o primeiro falha. Faça ping no endereço do túnel do servidor, o que prova que o túnel em si transporta tráfego. Faça ping em um endereço público por número, o que prova o encaminhamento e a tradução sem envolver a resolução de nomes. Depois tente resolver um nome de host, que é o único teste que usa DNS. Cada resultado remove uma camada inteira da suspeita.

Não pule para o terceiro teste porque o navegador parece mais rápido. Um carregamento de página malsucedido cobre as três camadas de uma vez, e é por aí que as pessoas começam e depois reconstroem um túnel que funcionava. Uma página que falha não diz qual das três quebrou.

Duas capturas mostram onde os pacotes param

Com um ping para um endereço público rodando a partir do cliente, faça uma captura na interface do túnel e outra no enlace ascendente que deveria alcançar a internet. Execute as duas ao mesmo tempo para que os carimbos de tempo coincidam.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Se as requisições aparecem no túnel e nunca no enlace ascendente, o servidor as descartou entre o túnel e o cabo, e a causa é o encaminhamento ou a política de firewall de encaminhamento, não o NAT. Se aparecem nos dois, o servidor fez a parte dele e a resposta falta mais adiante, o que aponta para a tradução, um filtro acima ou uma restrição do provedor.

Pegue o nome do enlace ascendente na tabela de rotas, não em um tutorial. Imagens de nuvem e adaptadores renomeados raramente correspondem à interface de exemplo de um guia, e uma captura feita no dispositivo errado parece exatamente um servidor que não encaminha:

ip -4 route get 9.9.9.9

O campo dev dessa saída é o nome que a regra NAT vai precisar depois, então guarde-o.

O encaminhamento é um interruptor do núcleo e uma política de firewall

O núcleo precisa concordar em encaminhar, no mínimo. Leia o valor atual e depois torne o ajuste permanente em vez de escrevê-lo só no núcleo em execução:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

O encaminhamento é só metade. Em um host com UFW a política de encaminhamento é definida em /etc/default/ufw e precisa ser ACCEPT antes que uma recarga tenha efeito. Um descarte padrão no caminho de encaminhamento deixa o handshake perfeitamente saudável enquanto descarta em silêncio cada pacote que tenta sair pelo túnel, e esse é exatamente o sintoma com que você começou.

Hosts que gerenciam nftables diretamente têm a mesma pergunta em outra sintaxe. Olhe os contadores da cadeia de encaminhamento enquanto um teste do cliente roda, porque uma cadeia consultada e uma cadeia que descarta parecem idênticas em um arquivo de configuração.

Nomeie a interface de saída real na regra NAT

A tradução de origem pertence à interface que realmente sai do host, com o pool que o servidor distribui. As duas metades dessa regra precisam descrever a realidade, e nenhuma é opcional.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

A falha clássica é uma regra copiada de um guia que diz -o eth0 em uma máquina cujo adaptador tem outro nome. A regra instala sem aviso, não corresponde a nada, e o cliente continua sem internet. O pool é a outra metade do mesmo erro: se o servidor distribui 10.44.0.0/24 e a regra cobre 10.8.0.0/24, nada vai corresponder nunca.

Olhe os contadores em vez de confiar no texto da regra. A listagem informa pacotes por regra, e uma regra que nunca corresponde fica em zero por mais correta que pareça. Dê a ela um minuto de tráfego real do cliente antes de ler qualquer coisa nesse número:

iptables -t nat -L POSTROUTING -v -n

Uma contagem de pacotes zero após um teste real do cliente significa que a correspondência está errada, não que o túnel esteja quebrado. Assim que corresponder, salve o conjunto de regras para que sobreviva a um reinício; um conserto que vive só no histórico do seu shell desaparece no primeiro reinício.

Se o servidor também for uma instância NAT na nuvem, a plataforma também tem voz. Uma instância que traduz endereços geralmente precisa da verificação de origem e destino desativada onde o provedor oferece esse ajuste, e a própria porta VPN precisa ser alcançável de fora.

O DNS é a segunda falha atrás da primeira

Ping por endereço funcionar enquanto os nomes falham é um problema de resolvedor, e tem causa própria. Um cliente que mantém o resolvedor local envia essas consultas para dentro de um túnel completo e espera uma resposta que nunca chega, porque o resolvedor local agora está do lado errado da rota.

Empurre um resolvedor a partir do servidor para que o cliente saiba onde perguntar. Duas entradas dão ao cliente uma alternativa se a primeira não for alcançável, e ambas deveriam ser resolvedores que o túnel realmente permite.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Clientes Windows podem depois voltar ao resolvedor local de qualquer forma, e é exatamente o que o block-outside-dns existe para impedir, ao custo de perder nomes que só a rede local consegue resolver. Clientes Linux com systemd-resolved costumam ignorar um resolvedor empurrado a menos que um script o instale, então verifique resolvectl status para o dispositivo do túnel antes de concluir que o empurrão foi ignorado.

Termine o percurso como um usuário o vive. Carregue uma página real a partir do cliente, confirme o endereço de onde ela sai, reinicie o servidor, reconecte e repita os três testes. Só essa segunda passagem prova que as regras salvas, a política de firewall e o resolvedor empurrado sobreviveram todos juntos.