IKEv2: renovación de claves frente a reautenticación — por qué la conexión cae más tarde

El túnel se levanta por la mañana y funciona durante horas. Luego cae, se reconecta tras un reintento y hace lo mismo al día siguiente. Nada cambió en la red y nadie tocó una contraseña. Las sesiones que fallan en un límite de renovación normalmente cruzan una de dos operaciones distintas, y solo una de ellas vuelve a comprobar tus credenciales. Leer cuál de las dos se disparó es todo el diagnóstico.

Dos operaciones que se parecen desde fuera

La renovación de claves sustituye asociaciones de seguridad o material de claves dentro del intercambio definido por el protocolo. La autenticación no se repite, así que la identidad aceptada al inicio de la sesión simplemente se traslada.

La reautenticación va más allá: establece una relación autenticada nueva, lo que significa que las credenciales se evalúan de nuevo. Todo lo que caducó, se revocó o cambió en el directorio se hace visible en ese momento.

Qué sustituye realmente una renovación de claves

IKEv2 mantiene dos tipos de asociación con ciclos de vida separados. La IKE SA protege el canal de control y las CHILD SA protegen el tráfico real. Renovar una no es sinónimo de reconectar el cliente.

Esa separación explica un patrón conocido: el tráfico fluye bien, luego se renueva una CHILD SA y la propuesta ya no encaja porque alguien editó la fase 2 en un lado semanas antes. El cambio estuvo ahí sin hacer daño hasta que la renovación lo ejercitó.

Los desajustes de duración se comportan igual. El par que alcanza primero su límite inicia el intercambio, y el otro tiene que aceptarlo.

Qué reevalúa la reautenticación

Con la reautenticación, el certificado de cliente que era válido al iniciar sesión puede haber caducado ya. Una credencial revocada, una contraseña rotada o un segundo factor no disponible aparecen todos aquí, no en el momento de la renovación.

Por eso alargar cada duración parece una solución y no lo es. Has aplazado la comprobación en lugar de pasarla. La próxima renovación llega con el mismo defecto y una ventana de interrupción más corta para advertirlo.

Algunas implementaciones solapan el estado antiguo y el nuevo durante la reautenticación. Otras producen un hueco breve. Por eso, ajustes idénticos en dos proveedores pueden dar experiencias de usuario distintas. Prueba el comportamiento en lugar de suponer que el estándar lo dicta.

Lee las marcas de tiempo antes de cambiar nada

Captura el momento del fallo junto con el estado de la asociación antes y después. Si la asociación antigua se sustituyó sin un intercambio de autenticación, estabas en un límite de renovación. Si un intercambio AUTH aparece justo antes del fallo, estabas en una reautenticación.

strongSwan lo expone como ajustes separados: rekey controla la renovación de claves, reauth controla si ocurre una autenticación nueva, y los valores de margen deciden con cuánta antelación al vencimiento empieza cada una. la documentación sobre la renovación de claves describe la interacción, y merece la pena leerla antes de copiar una duración de un mensaje del foro.

Distingue todo esto de una pérdida de red simple. Un enlace cortado produce un evento de detección de par muerto o una tormenta de retransmisiones, no un intercambio limpio con propuestas coincidentes.

Cambia lo que falló

Un rechazo de credenciales necesita que se arregle el problema de identidad: renueva el certificado, restaura la cuenta, vuelve a inscribir el factor. Un desajuste de propuesta o de duración necesita comparar los parámetros en ambos lados.

Estirar las duraciones para evitar el síntoma es la única opción que siempre parece haber funcionado y nunca funciona.

Prueba una renovación controlada

Fuerza la renovación en lugar de esperar un día por ella. Después repítelo con una reautenticación si el despliegue admite una, y observa ambos extremos.

Un inicio de sesión inicial correcto no ejercita nada de esto. El ciclo de vida posterior es donde estos despliegues se rompen de verdad.