O OpenVPN conecta mas nada passa: encontre a camada onde o pacote cai

OpenVPN diz conectado e nenhum tráfego se move, uma frase que cobre pelo menos cinco falhas não relacionadas. Editar regras do firewall antes de saber qual camada falha multiplica as incógnitas e deixa uma bagunça para o próximo engenheiro. Trabalhe em vez disso do processo para fora, porque cada passo abaixo ou limpa um estágio ou estreita onde o pacote morre. A ordem importa aqui: uma captura feita antes de saber qual endereço está vinculado provará algo, só não o que você precisa.

O socket está vinculado ou não está

Um serviço que relata ativo ainda pode estar vinculado a um endereço ou transporte que você nunca pretendeu. Consulte o próprio socket: ss -lunp lista os ouvintes UDP e ss -ltnp os TCP, e a coluna que vale a pena ler é o endereço local, não o estado.

Uma resposta vazia geralmente significa uma de três coisas: o processo encerrou depois de iniciar, carregou outro arquivo de configuração, ou escuta em um endereço diferente daquele que é discado.

ss -lunp | grep 1194
ss -ltnp | grep 1194

Uma diretiva local fixa o ouvinte a um único endereço, então um cliente direcionado a outro lugar no mesmo host é recusado enquanto o serviço de fora ainda parece saudável. Um nome de instância também pode apontar para um arquivo que você nunca editou, o que acontece em hosts executando dois perfis lado a lado.

Capture o pacote externo, não o túnel

Filtre na interface física e na porta real, com sua própria interface substituída: tcpdump -ni eth0 udp port 1194. Pacotes de saída sem nada que volte apontam para o que está acima: filtragem do provedor, um dispositivo NAT ou um endereço remoto que não é o que você pensa. O silêncio nas duas direções aponta para o roteamento do cliente ou um firewall local. Respostas que chegam sem progresso do túnel apontam para o canal de controle, ou seja, uma divergência de chave ou cifra, não para a filtragem.

Capture as duas direções e mantenha o arquivo curto. Uma captura longa enterra os três segundos interessantes, e a resposta quase sempre está na primeira troca.

Primeiro os contadores, rastreamento só quando eles mentem

Comece pelos contadores, porque não custam nada. Ou nft list ruleset ou iptables -L -n -v responde à única pergunta que importa aqui: a regra casou? A ordem decide o resultado, porque a primeira correspondência vence, por isso um DROP amplo antes de um ACCEPT posterior deixa esse ACCEPT morto e por isso acrescentar uma regra tão raramente conserta algo.

A propriedade também derruba as pessoas. O kernel atribui os pacotes gerados localmente ao processo que abriu o socket, e o OpenVPN normalmente roda como root, então uma regra vinculada a um ID de usuário comum nunca vê o tráfego do próprio túnel. Verifique o UID proprietário antes de decidir que a regra está errada.

Só quando os contadores permanecem ambíguos um log vale o barulho, e mesmo assim só para uma fatia estreita: uma regra iptables que limita a taxa e prefixa suas linhas, ou uma regra nftables com meta nftrace set 1 enquanto nft monitor trace executa. Um rastreamento nomeia a cadeia e a regra que aceitou ou descartou o pacote. Remova ambos depois e mantenha o registro de carga fora.

Verifique também o transporte. Um serviço de firewall limitado a TCP não diz nada sobre um ouvinte UDP naquele número, então uma regra lida corretamente ainda pode descartar cada pacote.

Roteamento e o caminho de volta

Um pacote aceito que ainda assim desaparece precisa que seu caminho de destino seja examinado. ip route get informa a rota escolhida para um endereço, e a filtragem de caminho reverso pode descartar uma resposta que chega por uma interface que a tabela principal nunca escolheria. O sintoma parece exatamente um descarte do firewall, por isso esta verificação vem antes de outra regra NAT.

Em um gateway, inspecione o encaminhamento e a cadeia forward em vez da cadeia input. Depois confirme que o lado remoto sabe como alcançar o endereço de origem, porque um caminho de saída que funciona sem nada que volte é silêncio nos dois casos.

O que o registro deve dizer

Para cada mudança, anote o estágio que você testou, a evidência que leu e o valor do contador nos dois lados. É essa nota que faz "agora funciona" sobreviver à próxima revisão.

Dois atalhos mantêm a nota honesta. Um pacote que nunca saiu do host não pode ter sido descartado por uma regra em outro lugar, por mais convincente que pareça a configuração do lado remoto. Um pacote que saiu e voltou move a pergunta acima da camada de rede, onde os contadores do firewall não têm mais nada a lhe dizer.