Por que un túnel IPsec ocupado renova claves antes de tempo: límites de tempo e de volume

Aproximadamente cada cincuenta minutos, un túnel nunha ligazón ocupada cae durante uns segundos, e o primeiro sospeitoso é o reloxo. As asociacións poden rematar por un límite de tempo ou por un reconto de bytes, e a fronteira que chegue primeiro é a que as xubila. Nunha ligazón que transporta tráfico real, un límite de volume pode dispararse moito antes de que remate a hora configurada. Así que «demasiado pronto» é unha afirmación sobre o reloxo, non sobre a asociación.

Conte o que conta a asociación, non a interface

O total de bytes dunha interface, o caudal combinado dun panel e o contador propio da asociación son tres números separados, e só un deles se compara co límite. Rexistre as asociacións de entrada e de saída por separado cos seus identificadores, para que un cambio de claves que toque unha dirección apareza como un acontecemento direccional en lugar dun misterio. O contador da asociación tamén volve comezar no cambio de claves, por iso un total tomado da interface medra mentres o valor que importa se reinicia.

Vale a pena facer a aritmética unha vez para que a orde de magnitude deixe de parecer arbitraria. Un orzamento contado dun xibibyte esgotado a un ritmo constante de 128 mebibytes por minuto consómese en oito minutos, e iso é unha conversión de unidades, non unha medición do seu túnel. Se a cifra resultante queda moi por baixo do límite de tempo, o volume é o mecanismo e ningunha vixilancia do reloxo explicará o intervalo. Se queda moi por riba, o límite de bytes non é o seu desencadeante e a busca pertence a outro lugar.

Os limiares feble e duro son dous acontecementos distintos

Un limiar feble pide unha substitución moito antes de que o límite duro remate a asociación, e as implementacións engaden as súas propias marxes e aleatorización por riba do que vostede configurou. Por iso o intervalo observado case nunca é un número redondo. A arquitectura IPsec describe vidas útiles expresadas en tempo e recontos de bytes cos dous tipos de limiar, e manda a expiración máis temperá. Se trata unha vida útil impresa como un calendario, equivocarase no tamaño da marxe.

Lea a política efectiva do estado en execución en lugar de inferila dun número nun ficheiro, porque a marxe pertence á implementación, non á súa intención. Resista a tentación de estirar os límites cara ao seu máximo para silenciar o síntoma: un túnel que cambia claves segundo o calendario compórtase como está deseñado, e unha vida útil máis longa só apraza o acontecemento mentres mantén unha clave comprometida utilizábel máis tempo. Cando o propio substituto falla, o límite é o mensaxeiro e non a culpa.

Lea a vida útil efectiva do estado en execución

En strongSwan, swanctl --list-sas imprime o resumo da asociación cos seus tempos de cambio de claves e de vida, así que o valor que o demo pretende impor vese sen adiviñar. Nun anfitrión Linux sen vista de demo, ip xfrm state informa os límites febles e duros de bytes e paquetes configurados xunto aos contadores actuais. Esa dúas lecturas responden a preguntas distintas e ambas merecen quedar no tícket.

swanctl --list-sas
ip -s xfrm state

Compare o limiar feble impreso co intervalo que mediu, porque unha substitución que comeza cunha marxe por baixo do límite duro é normal e unha que nunca comeza non o é. Se o demo mostra unha vida útil e o estado do núcleo mostra outra, está a mirar dúas capas que non concordan, e iso mesmo é o achado.

Vixíe o intercambio que substitúe a SA

Manteña as tres renovacións separadas, porque fallan de maneiras distintas: un cambio de claves de IKE SA constrúe unha nova asociación de control, un cambio de claves de CHILD SA substitúe a asociación de datos, e a reautenticación repite o intercambio de identidade. En IKEv2 cada par decide as súas propias vidas útiles en lugar de negociar un valor compartido, así que un intercambio que vostede non iniciou é normal. Unha discrepancia de perfect forward secrecy é unha causa frecuente de que unha child SA nova morra xusto no intervalo de cambio de claves, e preséntase exactamente como unha falla de temporizador ata que alguén le a proposta.

Compare a asociación antiga coa súa sucesora e co intercambio que a produciu. Un identificador que desaparece é unha substitución rutineira; unha proposta rexeitada, unha resposta ausente ou a falta dun estado sucesor utilizábel é un acontecemento distinto con outro propietario. Preserve esa evidencia antes de cambiar nada, porque as notas específicas da versión, a proposta do par e as vidas útiles negociadas son o que fai lexíbel o caso unha semana despois, cando os rexistros xa rotaron.

Demostre a renovación en lugar de ocultala

Acepte o despregamento pasando por unha renovación que planificou e non por unha que lle ocorre. Force un único cambio de claves dentro dunha xanela de mantemento e despois confirme que ambas direccións transportan datos e que o resultado da aplicación non cambia, non só que o indicador do túnel está verde. Rexistre que límite se disparou e que intercambio interveu.

Unha conclusión desa forma sobrevive ao escrutinio, mentres que un valor de temporizador cambiado que fixo parecer tranquila a conexión durante unha tarde non sobrevive. Se só se moveu o temporizador, a evidencia moveuse con el.