Pourquoi un tunnel IPsec chargé renégocie tôt : limites de temps et de volume

Toutes les cinquante minutes environ, un tunnel sur un lien chargé tombe pendant quelques secondes, et le premier suspect est l’horloge. Les associations peuvent se terminer sur une limite de temps ou sur un nombre d’octets, et la frontière qui arrive en premier est celle qui les met à la retraite. Sur un lien qui transporte du trafic réel, une limite de volume peut se déclencher bien avant la fin de l’heure configurée. Donc « trop tôt » est une affirmation sur l’horloge, pas sur l’association.

Comptez ce que compte l’association, pas l’interface

Le total d’octets d’une interface, le débit combiné d’un tableau de bord et le compteur propre de l’association sont trois nombres distincts, et un seul d’entre eux est comparé à la limite. Enregistrez les associations entrante et sortante séparément avec leurs identifiants, afin qu’une renégociation qui touche une direction apparaisse comme un événement directionnel plutôt qu’un mystère. Le compteur de l’association repart aussi à zéro lors d’une renégociation, c’est pourquoi un total pris sur l’interface augmente alors que la valeur qui compte est réinitialisée.

Le calcul vaut la peine d’être fait une fois pour que l’ordre de grandeur cesse de sembler arbitraire. Un budget compté d’un gibioctet épuisé à un rythme constant de 128 mébioctets par minute s’épuise en huit minutes, et c’est une conversion d’unités, pas une mesure de votre tunnel. Si le chiffre obtenu se situe bien en dessous de la limite de temps, le volume est le mécanisme et aucune surveillance de l’horloge n’expliquera l’intervalle. S’il se situe bien au-dessus, la limite d’octets n’est pas votre déclencheur et la recherche appartient ailleurs.

Les seuils souple et strict sont deux événements différents

Un seuil souple demande un remplacement bien avant que la limite stricte ne termine l’association, et les implémentations ajoutent leurs propres marges et randomisation par-dessus ce que vous avez configuré. C’est pourquoi l’intervalle observé n’est presque jamais un nombre rond. L’architecture IPsec décrit des durées de vie exprimées en temps et en nombres d’octets avec les deux types de seuil, et l’expiration la plus précoce fait foi. Traitez une durée de vie imprimée comme un calendrier et vous vous tromperez de la marge.

Lisez la politique effective dans l’état d’exécution au lieu de la déduire d’un nombre dans un fichier, car la marge appartient à l’implémentation, pas à votre intention. Résistez à la tentation d’étirer les limites vers leur maximum pour faire taire le symptôme : un tunnel qui renégocie selon le calendrier se comporte comme prévu, et une durée de vie plus longue ne fait que reporter l’événement tout en gardant une clé compromise utilisable plus longtemps. Quand le remplacement lui-même échoue, la limite est le messager et non la faute.

Lisez la durée de vie effective dans l’état d’exécution

Sur strongSwan, swanctl --list-sas imprime le résumé de l’association avec ses temps de renégociation et de vie, de sorte que la valeur que le démon compte appliquer est visible sans deviner. Sur un hôte Linux sans vue du démon, ip xfrm state indique les limites souples et strictes d’octets et de paquets configurées à côté des compteurs actuels. Ces deux lectures répondent à des questions différentes et toutes deux méritent de rester dans le ticket.

swanctl --list-sas
ip -s xfrm state

Comparez le seuil souple imprimé à l’intervalle que vous avez mesuré, car un remplacement qui commence avec une marge sous la limite stricte est normal, et un remplacement qui ne commence jamais ne l’est pas. Si le démon affiche une durée de vie et que l’état du noyau en affiche une autre, vous regardez deux couches qui ne s’accordent pas, et c’est en soi la conclusion.

Surveillez l’échange qui remplace la SA

Gardez les trois renouvellements séparés, car ils échouent de manières différentes : une renégociation d’IKE SA construit une nouvelle association de contrôle, une renégociation de CHILD SA remplace l’association de données, et la réauthentification répète l’échange d’identité. Dans IKEv2, chaque pair décide de ses propres durées de vie au lieu de négocier une valeur commune, donc un échange que vous n’avez pas lancé est ordinaire. Une divergence de perfect forward secrecy est une cause fréquente de la mort d’une nouvelle child SA précisément à l’intervalle de renégociation, et elle se présente exactement comme une panne de minuterie jusqu’à ce que quelqu’un lise la proposition.

Comparez l’ancienne association à sa successeure et à l’échange qui l’a produite. Un identifiant qui disparaît est un remplacement de routine ; une proposition rejetée, une réponse absente ou l’absence d’un état successeur utilisable est un autre événement avec un autre responsable. Préservez ces preuves avant de changer quoi que ce soit, car les notes propres à la version, la proposition du pair et les durées de vie négociées sont ce qui rend le dossier lisible une semaine plus tard, après la rotation des journaux.

Prouvez le renouvellement au lieu de le masquer

Acceptez le déploiement en passant par un renouvellement que vous avez planifié, et non par un renouvellement qui vous arrive. Forcez une seule renégociation pendant une fenêtre de maintenance, puis confirmez que les deux directions transportent des données ensuite et que le résultat de l’application est inchangé, pas seulement que l’indicateur du tunnel est vert. Notez quelle limite s’est déclenchée et quel échange était en jeu.

Une conclusion de cette forme résiste à l’examen, alors qu’une valeur de minuterie modifiée qui a fait paraître la connexion calme pendant un après-midi n’y résiste pas. Si seule la minuterie a bougé, les preuves ont bougé avec elle.