A IP pública cambiou e a VPN deixou de pasar tráfico

Unha reconexión do provedor ou un cambio na tradución augas arriba altera a orixe pública dunha sesión VPN, mentres a dirección privada local do cliente adoita quedar exactamente como estaba. Entón o túnel parece conectado aínda que nada útil o atravesa. Ambas as observacións son certas á vez, e iso é o que fai confuso o informe.

Percorra as catro comprobacións en orde e detéñase na primeira que falla.

Que dirección cambiou realmente

Compare o estado da interface local coa orixe que observa un extremo remoto, nun punto onde teña autorización para mirar. Unha dirección pública nova non implica unha pasarela local nova, e un cambio de interface local tampouco garante que a orixe pública se moveu. A tradución no medio significa que son dous feitos independentes. Anote a ruta exacta e a hora en que a observou, porque unha etiqueta de xeolocalización copiada dun informe antigo responde a outra pregunta.

Pregunte especificamente se cambiou a orixe exterior, a dirección interior do túnel ou ambas. Só o primeiro explica un par que segue enviando por unha ruta que xa non existe.

Deixe que o protocolo xestione o traslado

Os protocolos difiren en como aprenden que un par se moveu, e a diferenza importa para decidir se debería intervir. WireGuard actualiza o extremo dun par cando recibe un paquete que se autentica coa chave dese par, e por iso un cambio de dirección pode absorberse sen ningunha configuración. IKEv2 ten MOBIKE para o mesmo propósito onde ambos os extremos o admiten. Os deseños máis antigos recupéranse reconstruíndo o túnel.

O que non debería facer é aceptar unha mensaxe non autenticada como proba de que a identidade dun par se moveu. Falsificar un datagrama que afirma unha dirección nova é trivial, e un cliente que cre que se lle pode dirixir ao extremo do atacante. O protocolo autenticado é o mecanismo; unha notificación nono é.

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

Borrar a vinculación exterior obsoleta

Cando o protocolo si admite roaming e o tráfico segue fallando, o obstáculo adoita ser equipo con estado no medio ou unha política no extremo afastado. Un cortafuegos que seguía o fluxo antigo pode conservar a entrada obsoleta, e unha regra de acceso do servidor ligada á orixe antiga descartará a nova en silencio. Limpar o mapeo e volver comprobar a regra é máis rápido que substituír as credenciais.

Manteña o bloqueo necesario mentres investiga. Abrir a política de par en par para comprobar se o túnel se recupera non lle ensina nada sobre a causa e deixa o despregue peor do que o atopou.

Volva probar cunha petición nova

Unha sesión de aplicación establecida antes do cambio non o sobrevive, porque a cuádrupla sobre a que se construíu xa non existe. Xere unha petición nova tras a recuperación e confirme que se completa, en lugar de mirar como unha descarga antiga queda en cero e concluír que o túnel segue roto. Ese único matiz resolve boa parte destes informes.

Despois anote as dúas metades do diagnóstico: que cambiou augas arriba e que paso de recuperación admitido restableceu o fluxo. A próxima vez será máis rápida, e a nota é o que a fai máis rápida.

Se unha petición nova ten éxito e a antiga nunca se retoma, o túnel quedou arranxado e a aplicación só necesita reconectarse.