Por qué tu VPN se cae cada vez que rotan las claves

La conexión funciona durante una hora y luego muere, y el cliente no informa nada más útil que disconnected. Ese periodo es la pista, porque algo del intercambio de renovación difiere del handshake inicial. El temporizador solo decide cuándo te lo encuentras. Guarda los mensajes de ese intercambio en lugar de la etiqueta final.

Lee la etapa, no la etiqueta

En IKEv2 la asociación IKE y la asociación CHILD se renuevan con calendarios separados. Una propuesta aceptable para la primera negociación no es automáticamente aceptable para la segunda. Una puede completarse mientras la otra se rechaza, lo que produce un túnel que existe a medias. Captura el intercambio con la herramienta que lo posee en lugar de una línea del registro del cliente:

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

Para OpenVPN, el evento equivalente es una renegociación gobernada por la versión y los ajustes de despliegue. Su comportamiento de autenticación tiene sus propios modos de fallo. El mensaje que importa nombra la etapa fallida, y deberías registrarlo literalmente en lugar de parafrasearlo en un ticket.

Anota también las marcas de tiempo. Una caída en un intervalo fijo tras la última negociación exitosa es un hallazgo muy distinto de una que llega al azar durante el uso, y el intervalo suele ser la única evidencia que sobrevive.

Compara la propuesta que falla

Una propuesta rechazada produce un mensaje claro en el respondedor. La causa habitual es una diferencia entre ambos extremos en algoritmo, longitud de clave, grupo o duración. La negociación CHILD inicial pudo tener éxito porque la inició el otro lado, lo que significa que usó la lista de propuestas del otro lado. Mira ambos extremos antes de cambiar nada.

Las discrepancias de duración merecen especial atención, porque un valor que parecía generoso en un extremo puede hacer que el otro inicie una renovación que no puede completar. La documentación del comportamiento de recambio de claves describe cómo se dispara la renovación de la asociación y cómo los dos extremos pueden diferir en sus expectativas de tiempo. Compara lo que cada extremo dice soportar en lugar de lo que sugiere el archivo de configuración.

Un perfil antiguo o una plantilla de proveedor pueden fijar una propuesta que la versión actual ya no ofrece. La discrepancia solo aparece cuando se fuerza una negociación nueva.

Separa un problema de credenciales de un par inalcanzable

Una renovación que falla la autenticación se ve parecida en el cliente y completamente distinta en el servidor. Si una credencial se vuelve a comprobar en la renegociación, un certificado caducado, una cuenta revocada o una contraseña cambiada producirán una caída exactamente en el intervalo de renovación, mientras todas las conexiones anteriores tuvieron éxito. Un par inalcanzable es la tercera posibilidad, y no produce ningún rechazo: los paquetes salen y nada responde. Ese caso normalmente sigue a un cambio de red en lugar de a un temporizador, así que comprueba si el fallo llega tras un roaming, un periodo de inactividad o un cambio de ruta.

Distingue los tres por lo que registró el extremo remoto. Un rechazo con motivo, un fallo de autenticación y el silencio son tres correcciones distintas. Reiniciar el cliente los colapsa en una observación inútil.

Comprueba las fechas del certificado y el estado de la cuenta antes de culpar a la red. Ambos son baratos de inspeccionar y ambos son invisibles en el mensaje del propio cliente.

Fuerza una renovación y lee el resultado

Fuerza una renovación con el método soportado por el operador en lugar de esperar una hora a la siguiente. Mantén intacta la política de fallo requerida mientras lo haces. Desactivar la verificación o estirar las duraciones hasta un día hace desaparecer el síntoma de tus registros sin corregir nada. También deja una interrupción más larga esperando a la siguiente persona.

Cuando el arreglo esté en su sitio, comprueba el túnel renovado y luego haz una petición nueva desde la aplicación. Una sesión de aplicación que estaba viva cuando cambió la asociación puede necesitar su propia recuperación aunque el túnel vuelva a estar sano. Los usuarios lo reportarán como que la VPN sigue rota.

Registra las versiones de la release, los temporizadores negociados y la etapa que falló. La siguiente recurrencia podrá compararse entonces con esta en lugar de describirse otra vez de memoria.