O IP público mudou e a VPN parou de passar tráfego

Uma reconexão do fornecedor ou uma alteração na tradução a montante altera a origem pública de uma sessão VPN, enquanto o endereço privado local do cliente costuma ficar exatamente como estava. O túnel passa então a parecer ligado enquanto nada de útil o atravessa. Ambas as observações são verdadeiras ao mesmo tempo, e é isso que torna o relatório confuso.

Percorra as quatro verificações por ordem e pare na primeira que falhar.

Que endereço mudou realmente

Compare o estado da interface local com a origem que um ponto final remoto observa, num ponto onde tenha autorização para olhar. Um novo endereço público não implica um novo gateway local, e uma alteração da interface local também não garante que a origem pública se tenha deslocado. A tradução pelo meio significa que são dois factos independentes. Registe o caminho exato e a hora a que o observou, porque uma etiqueta de geolocalização copiada de um relatório antigo responde a outra pergunta.

Pergunte especificamente se mudou a origem exterior, o endereço interior do túnel, ou ambos. Só o primeiro explica um par que continua a enviar para um caminho que já não existe.

Deixe o protocolo tratar do deslocamento

Os protocolos diferem na forma como aprendem que um par se deslocou, e a diferença importa para decidir se deve intervir. O WireGuard atualiza o ponto final de um par quando recebe um pacote que se autentica com a chave desse par, e é por isso que uma mudança de endereço pode ser absorvida sem qualquer configuração. O IKEv2 tem o MOBIKE para o mesmo fim onde ambas as pontas o suportam. As conceções mais antigas recuperam reconstruindo o túnel.

O que não deve fazer é aceitar uma mensagem não autenticada como prova de que a identidade de um par se deslocou. Falsificar um datagrama que afirma um novo endereço é trivial, e um cliente que acredita que pode ser encaminhado para o ponto final do atacante. O protocolo autenticado é o mecanismo; uma notificação não é.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

Limpe a ligação exterior obsoleta

Quando o protocolo suporta roaming e o tráfego continua a falhar, o obstáculo é muitas vezes equipamento com estado no meio ou uma política na ponta distante. Uma firewall que seguia o fluxo antigo pode manter a entrada obsoleta, e uma regra de acesso do lado do servidor ligada à origem antiga descartará a nova em silêncio. Limpar o mapeamento e reverificar a regra é mais rápido do que substituir as credenciais.

Mantenha o bloqueio necessário enquanto investiga. Abrir a política de par em par para testar se o túnel recupera não lhe ensina nada sobre a causa e deixa a implementação pior do que a encontrou.

Teste novamente com um pedido novo

Uma sessão de aplicação estabelecida antes da alteração não lhe sobrevive, porque o quádruplo em que se baseava já não existe. Gere um novo pedido após a recuperação e confirme que se conclui, em vez de ver um download antigo parado em zero e concluir que o túnel continua avariado. É essa única distinção que resolve grande parte destes relatórios.

Depois registe as duas metades do diagnóstico: o que mudou a montante e que passo de recuperação suportado restabeleceu o fluxo. A próxima ocorrência será mais rápida, e a nota é o que a torna mais rápida.

Se um novo pedido tiver sucesso e o antigo nunca recomeçar, o túnel foi reparado e a aplicação só precisa de se reconectar.