¿Reclave, reconexión o reautenticación? ¿Cuál necesitas?

Una sesión que lleva horas activa no conservará las mismas claves para siempre, y eso es intencionado. Tres sucesos distintos se describen como rotación de claves: material de sesión nuevo bajo una asociación existente, una reconstrucción completa de la conexión y una repetición de la comprobación de identidad. Cada uno tiene un desencadenante, un coste y una firma de fallo diferentes. Si eliges el equivocado, la solución o no hace nada o tumba el túnel sin motivo.

La decisión depende de qué capa ha caducado realmente.

Tres operaciones a las que llaman rotación

Un reclave crea claves de tráfico nuevas dentro de la relación de control existente, usando el mecanismo que define el protocolo. IKEv2 lo hace con una nueva asociación de seguridad hija, TLS 1.3 con un mensaje de actualización de clave y WireGuard con un handshake nuevo cuando se alcanzan sus límites de tiempo o de mensajes. Las direcciones del túnel y la identidad autenticada se quedan donde estaban.

Una reconexión descarta la conexión y la vuelve a construir desde el principio, lo que repite la asignación de direcciones, la instalación de rutas y cualquier negociación que hiciera el primer intento.

La reautenticación repite la propia prueba de identidad, que puede implicar una credencial, un certificado o un segundo factor. Puede ocurrir con o sin reconexión, según el producto.

Qué nota el usuario en la renovación

Un reclave debería ser casi invisible. Los identificadores de asociación cambian, los contadores pueden reiniciarse y las aplicaciones conservan sus sockets; una pausa breve en una dirección es normal durante el intercambio. Ver un identificador nuevo en un listado de estado no es prueba de una avería. La línea de registro que sigue al intercambio es la que te dice si ha terminado.

Una caída real en la renovación apunta a un punto concreto. Un desajuste de propuesta, una credencial caducada o un cambio de ruta producen cada uno una línea de registro distinta, y solo uno de ellos se corrige ajustando las duraciones.

Dónde divergen las tres en la práctica

Si lo único que ha caducado es el material de clave, reclava. Si la dirección del par, la ruta o el enlace NAT han cambiado y los paquetes ya no llegan, reconecta. Si la organización exige una comprobación periódica de identidad, eso es reautenticación y ningún ajuste de duraciones la sustituye.

Los valores por defecto del protocolo suelen contener la respuesta correcta. WireGuard reclava tras un umbral de tiempo y de volumen de datos sin intervención del usuario; las duraciones de IKEv2 se negocian por asociación hija; los túneles basados en TLS rotan claves dentro de la sesión existente. Subir las duraciones para evitar un error recurrente aplaza el fallo y alarga la exposición si una clave queda comprometida.

Una advertencia importa para sesiones largas: la frecuencia por sí sola no crea secreto hacia adelante. La propiedad depende de cómo se relacionan las claves de sesión con los secretos a largo plazo y de si las claves antiguas se destruyen, lo que es una cuestión de diseño e implementación, no un ajuste.

Elige los valores por defecto y luego registra la etapa

Mantén los valores por defecto del proveedor salvo que un requisito documentado diga lo contrario, y cambia las duraciones en ambos pares si las cambias. Después registra a qué etapa llegó cada suceso, para que la próxima ocurrencia se pueda comprobar contra el mismo punto del handshake.

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

Tras una corrección, haz una renovación controlada y envía tráfico de aplicación nuevo por la asociación nueva. Un túnel que se declara establecido pero no reenvía nada es el fallo que esta comprobación existe para atrapar.