Por qué un túnel IPsec ocupado renueva claves antes de tiempo: límites de tiempo y de volumen

Aproximadamente cada cincuenta minutos, un túnel en un enlace ocupado cae durante unos segundos, y el primer sospechoso es el reloj. Las asociaciones pueden terminar por un límite de tiempo o por un recuento de bytes, y la frontera que llegue primero es la que las jubila. En un enlace que transporta tráfico real, un límite de volumen puede dispararse mucho antes de que termine la hora configurada. Así que «demasiado pronto» es una afirmación sobre el reloj, no sobre la asociación.

Cuente lo que cuenta la asociación, no la interfaz

El total de bytes de una interfaz, el caudal combinado de un panel y el contador propio de la asociación son tres números separados, y solo uno de ellos se compara con el límite. Registre las asociaciones de entrada y de salida por separado con sus identificadores, para que un cambio de claves que toque una dirección aparezca como un evento direccional en lugar de un misterio. El contador de la asociación también vuelve a empezar en el cambio de claves, por eso un total tomado de la interfaz crece mientras el valor que importa se reinicia.

Vale la pena hacer la aritmética una vez para que el orden de magnitud deje de parecer arbitrario. Un presupuesto contado de un gibibyte agotado a un ritmo constante de 128 mebibytes por minuto se consume en ocho minutos, y eso es una conversión de unidades, no una medición de su túnel. Si la cifra resultante queda muy por debajo del límite de tiempo, el volumen es el mecanismo y ninguna vigilancia del reloj explicará el intervalo. Si queda muy por encima, el límite de bytes no es su desencadenante y la búsqueda pertenece a otro lugar.

Los umbrales blando y duro son dos eventos distintos

Un umbral blando pide un reemplazo mucho antes de que el límite duro termine la asociación, y las implementaciones añaden sus propios márgenes y aleatorización encima de lo que usted configuró. Por eso el intervalo observado casi nunca es un número redondo. La arquitectura IPsec describe vidas útiles expresadas en tiempo y recuentos de bytes con los dos tipos de umbral, y manda la expiración más temprana. Si trata una vida útil impresa como un calendario, se equivocará en el tamaño del margen.

Lea la política efectiva del estado en ejecución en lugar de inferirla de un número en un archivo, porque el margen pertenece a la implementación, no a su intención. Resista la tentación de estirar los límites hacia su máximo para silenciar el síntoma: un túnel que cambia claves según el calendario se comporta como está diseñado, y una vida útil más larga solo aplaza el evento mientras mantiene una clave comprometida utilizable más tiempo. Cuando el propio reemplazo falla, el límite es el mensajero y no la culpa.

Lea la vida útil efectiva del estado en ejecución

En strongSwan, swanctl --list-sas imprime el resumen de la asociación con sus tiempos de cambio de claves y de vida, así que el valor que el demonio pretende imponer se ve sin adivinar. En un anfitrión Linux sin vista de demonio, ip xfrm state informa los límites blandos y duros de bytes y paquetes configurados junto a los contadores actuales. Esas dos lecturas responden a preguntas distintas y ambas merecen quedarse en el ticket.

swanctl --list-sas
ip -s xfrm state

Compare el umbral blando impreso con el intervalo que midió, porque un reemplazo que empieza con un margen por debajo del límite duro es normal y uno que nunca empieza no lo es. Si el demonio muestra una vida útil y el estado del núcleo muestra otra, está mirando dos capas que no concuerdan, y eso mismo es el hallazgo.

Vigile el intercambio que reemplaza la SA

Mantenga las tres renovaciones separadas, porque fallan de maneras distintas: un cambio de claves de IKE SA construye una nueva asociación de control, un cambio de claves de CHILD SA reemplaza la asociación de datos, y la reautenticación repite el intercambio de identidad. En IKEv2 cada par decide sus propias vidas útiles en lugar de negociar un valor compartido, así que un intercambio que usted no inició es normal. Una discrepancia de perfect forward secrecy es una causa frecuente de que una child SA nueva muera justo en el intervalo de cambio de claves, y se presenta exactamente como una falla de temporizador hasta que alguien lee la propuesta.

Compare la asociación antigua con su sucesora y con el intercambio que la produjo. Un identificador que desaparece es un reemplazo rutinario; una propuesta rechazada, una respuesta ausente o la falta de un estado sucesor utilizable es un evento distinto con otro propietario. Preserve esa evidencia antes de cambiar nada, porque las notas específicas de la versión, la propuesta del par y las vidas útiles negociadas son lo que hace legible el caso una semana después, cuando los registros ya han rotado.

Demuestre la renovación en lugar de ocultarla

Acepte el despliegue pasando por una renovación que planificó y no por una que le ocurre. Fuerce un solo cambio de claves dentro de una ventana de mantenimiento y luego confirme que ambas direcciones transportan datos después y que el resultado de la aplicación no cambia, no solo que el indicador del túnel está verde. Registre qué límite se disparó y qué intercambio intervino.

Una conclusión de esa forma sobrevive al escrutinio, mientras que un valor de temporizador cambiado que hizo parecer tranquila la conexión durante una tarde no sobrevive. Si solo se movió el temporizador, la evidencia se movió con él.