La IP pública cambió y la VPN dejó de pasar tráfico

Una reconexión del proveedor o un cambio en la traducción aguas arriba altera el origen público de una sesión VPN, mientras la dirección privada local del cliente suele quedar exactamente como estaba. Entonces el túnel parece conectado aunque nada útil lo atraviesa. Ambas observaciones son ciertas a la vez, y eso es lo que hace confuso el informe.

Recorra las cuatro comprobaciones en orden y deténgase en la primera que falle.

Qué dirección cambió realmente

Compare el estado de la interfaz local con el origen que observa un extremo remoto, en un punto donde tenga autorización para mirar. Una dirección pública nueva no implica una puerta de enlace local nueva, y un cambio de interfaz local tampoco garantiza que el origen público se haya movido. La traducción intermedia significa que son dos hechos independientes. Anote la ruta exacta y la hora en que la observó, porque una etiqueta de geolocalización copiada de un informe antiguo responde a otra pregunta.

Pregunte específicamente si cambió el origen exterior, la dirección interior del túnel o ambos. Solo lo primero explica un par que sigue enviando por una ruta que ya no existe.

Deje que el protocolo gestione el traslado

Los protocolos difieren en cómo aprenden que un par se ha movido, y la diferencia importa para decidir si debería intervenir. WireGuard actualiza el extremo de un par cuando recibe un paquete que se autentica con la clave de ese par, y por eso un cambio de dirección puede absorberse sin ninguna configuración. IKEv2 tiene MOBIKE para el mismo propósito donde ambos extremos lo admiten. Los diseños más antiguos se recuperan reconstruyendo el túnel.

Lo que no debería hacer es aceptar un mensaje no autenticado como prueba de que la identidad de un par se ha movido. Falsificar un datagrama que afirma una dirección nueva es trivial, y un cliente que cree que se le puede dirigir al extremo del atacante. El protocolo autenticado es el mecanismo; una notificación no lo es.

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

Borre la vinculación exterior obsoleta

Cuando el protocolo sí admite roaming y el tráfico sigue fallando, el obstáculo suele ser equipo con estado en medio o una política en el extremo lejano. Un cortafuegos que seguía el flujo antiguo puede conservar la entrada obsoleta, y una regla de acceso del servidor ligada al origen antiguo descartará la nueva en silencio. Limpiar el mapeo y volver a comprobar la regla es más rápido que sustituir las credenciales.

Mantenga el bloqueo necesario mientras investiga. Abrir la política de par en par para comprobar si el túnel se recupera no le enseña nada sobre la causa y deja el despliegue peor de como lo encontró.

Vuelva a probar con una petición nueva

Una sesión de aplicación establecida antes del cambio no lo sobrevive, porque la cuádrupla sobre la que se construyó ya no existe. Genere una petición nueva tras la recuperación y confirme que se completa, en lugar de mirar cómo una descarga antigua se queda en cero y concluir que el túnel sigue roto. Esa sola distinción resuelve buena parte de estos informes.

Después anote las dos mitades del diagnóstico: qué cambió aguas arriba y qué paso de recuperación admitido restableció el flujo. La próxima vez será más rápida, y la nota es lo que la hace más rápida.

Si una petición nueva funciona y la antigua nunca se reanuda, el túnel quedó arreglado y la aplicación solo necesita reconectarse.