Depois de uma mudança de IP do servidor, a regra SNAT ainda nomeia a antiga

O servidor mudou para um endereço novo, os clientes ainda se conectam e nada do que enviam chega à internet. Essa separação é a pista: o socket de escuta e o redirecionamento de porta sobreviveram à mudança, então o túnel sobe, enquanto a tradução de origem aplicada aos pacotes encaminhados ainda nomeia um endereço que o host não possui mais. As respostas a esses pacotes reescritos vão para uma máquina que não existe mais.

Conexão e encaminhamento falham em lugares diferentes

O estabelecimento depende do endpoint que os clientes já conhecem: o endereço público, o redirecionamento de porta à frente dele e o ouvinte lá dentro. O tráfego encaminhado depende de uma segunda decisão tomada depois que o pacote entra no túnel, quando o host reescreve sua origem para que as respostas encontrem o caminho de volta.

Uma mudança de endereço quebra apenas a segunda decisão, e é por isso que o sintoma é lido como "conectado, mas sem internet". Isso também explica por que as verificações habituais do lado do cliente parecem saudáveis: o handshake se completa, o cliente recebe um endereço e até um ping para o endereço do túnel do servidor pode responder. Perdem-se horas no cliente por uma falha que mora do outro lado, e por isso a tabela de regras é o primeiro lugar a olhar.

Leia a regra e seus contadores antes de editar

Liste as regras de tradução com contadores e compare a origem configurada com os endereços que o host realmente tem. Uma regra reescrita para um endereço morto costuma mostrar tráfego na entrada, porque os pacotes chegam até ela e são traduzidos, e nada na volta.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Confira três campos enquanto estiver aí: o conjunto na correspondência de origem, a interface de saída se a regra nomear uma, e a exclusão que impede o tráfego entre túneis de ser reescrito. Essa exclusão se perde facilmente durante uma edição, e perdê-la faz o tráfego entre pares parecer funcionar enquanto as respostas tomam um caminho estranho.

Se os contadores ficam em zero, os pacotes nunca chegam a esta regra e o endereço não é o problema atual. Procure uma regra concorrente mais acima na cadeia, o que acontece quando alguém adiciona uma substituição em vez de editar a original. Compare os números das regras com a saída que você anotou um minuto atrás. A ordem faz parte da configuração, não é um detalhe cosmético.

Substitua a origem, ou pare de nomear uma

Quando o host tem um endereço estável, substitua a regra no lugar em vez de acrescentar outra. Substituir pelo número da regra preserva a ordem da qual o resto da cadeia depende.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Quando o endereço é atribuído dinamicamente, não nomeie origem nenhuma e deixe o kernel escolher a atual a partir da interface de saída. Essa variante sobrevive à próxima mudança sem edição, ao custo de esconder qual endereço foi usado.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Confirme que o encaminhamento IPv4 continua ativado por configuração gerenciada e depois torne a regra permanente com o mecanismo da própria distribuição. Uma alteração feita apenas no kernel em execução volta no próximo reinício, normalmente durante uma janela de manutenção que ninguém liga à mudança.

Duas maneiras de errar a substituição

Traduzir o conjunto para o endereço do túnel do servidor em vez do endereço LAN dele manda as respostas direto de volta ao túnel, onde são roteadas para um cliente que nunca as pediu. A conexão trava de um jeito que parece um laço de roteamento, porque é.

Empilhar uma segunda tradução sobre a antiga é o outro erro. A primeira regra correspondente vence, então a entrada obsoleta continua tratando pacotes até ser apagada, e os contadores da regra nova ficam em zero enquanto todos culpam a substituição. Apague a duplicata antes de acrescentar qualquer coisa nova. Depois leia a lista mais uma vez e confirme que exatamente uma tradução corresponde ao conjunto.

Se o túnel também transporta IPv6, repita toda a revisão na outra pilha. Uma rota padrão IPv6 sem tradução e sem prefixo roteado falha igualmente em silêncio, e é fácil esquecer porque tudo acima dela parece idêntico.

Serviços de entrada precisam da tradução oposta

Um serviço em um cliente VPN que precisa ser alcançável de fora precisa de tradução de destino, não de origem: a porta pública é reescrita para o endereço do túnel do cliente antes de entrar. O caminho de encaminhamento então precisa de uma regra explícita que permita esse tráfego.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Nunca traduza a porta que transporta o próprio túnel, porque essa reescrita interrompe a conexão que mantém o serviço alcançável. Mantenha a porta do túnel completamente fora das regras de destino. Verifique depois pelas duas pontas: contadores na regra nova, uma captura curta no dispositivo do túnel e uma requisição a um endereço dentro do túnel antes de tentar a pública.