Pourquoi votre tunnel IPsec fonctionne jusqu’au premier renouvellement de clé CHILD SA

Le tunnel est monté, le ping a répondu et tout le monde a validé. Quatre heures plus tard la session tombe, les pairs journalisent une erreur de proposition ou d’échange de clés, et la première supposition est que quelque chose a changé sur le réseau. Rien n’a changé. Un tunnel qui transporte du trafic a prouvé que les deux pairs s’accordent sur la manière de s’authentifier et de protéger la première association enfant, et il n’a rien prouvé sur l’échange de clés qu’ils exigeront au renouvellement. Le désaccord se situe dans l’écart entre ces deux événements.

Connecté ne signifie pas que les réglages PFS concordent

Avec IKEv2, la première association enfant est créée pendant l’échange d’authentification, et ses clés dérivent de matière que l’association IKE a déjà produite. Aucun échange Diffie-Hellman séparé n’a lieu pour cet enfant, donc une politique qui en exige un au renouvellement n’est pas éprouvée au montage.

Le renouvellement est un autre échange. Lorsqu’une association enfant est renouvelée, les pairs peuvent effectuer un nouvel échange de clés avec le groupe nommé dans leurs propositions, et c’est le premier moment où les réglages de groupe sont comparés. Deux pairs en désaccord peuvent donc s’authentifier, installer une association enfant et faire passer du trafic, puis échouer au renouvellement.

Où se cache le désaccord dans la chaîne de proposition

Dans strongSwan le groupe est ajouté à la proposition enfant, ce qui explique qu’une chaîne comme aes256gcm16-prfsha256-ecp256 ressemble à un choix de chiffrement mais porte aussi une exigence d’échange de clés. Un pair qui ne propose que aes256gcm16-prfsha256 n’a pas cette exigence, et les deux listes se recoupent sur le chiffrement tout en divergeant sur l’échange.

Lisez la proposition enfant et la proposition IKE comme deux listes distinctes. Un groupe qui apparaît dans la liste IKE ne dit rien de la liste enfant, et modifier l’une en lisant l’autre est la façon habituelle de manquer cela.

Lisez l’échec, pas le fichier que vous avez modifié

Trouvez le notify qui a terminé l’échange. Un renouvellement de clé enfant qui renvoie « aucune proposition acceptable » désigne les listes de propositions ; une demande de renouvellement qui ne reçoit jamais de réponse désigne le chemin ou un pair qui a cessé d’écouter. Ces deux cas demandent des corrections différentes, et la formulation de la ligne de journal les sépare.

Confirmez la configuration en cours, pas celle du disque. Un fichier enregistré mais non chargé, ou une connexion relue depuis un autre include, produira un désaccord qu’aucune modification du fichier visible ne peut corriger.

Trois événements que tout le monde appelle renouvellement de clé

Le renouvellement de clé de l’association IKE, la réauthentification IKE et le renouvellement de clé de l’association enfant sont des opérations distinctes avec des règles de proposition distinctes. Un échec signalé sur l’une ne dit rien directement des autres, et un journal qui les mélange se lit comme une seule panne récurrente alors qu’il y en a trois.

Notez quel événement le pair nomme, puis vérifiez les propositions pour cet événement uniquement. Changez une liste, rechargez et forcez à nouveau le même événement. Si le journal nomme une réauthentification, c’est la proposition IKE qu’il faut lire. S’il nomme un renouvellement de clé enfant, la proposition enfant porte le groupe qui compte.

Désactiver le renouvellement n’est pas une correction

Mettre le temps de renouvellement à zéro supprime l’échange qui échoue, et le tunnel survit alors jusqu’à son démontage ou au redémarrage du pair. Ce que vous avez acheté, c’est une clé qui dure plus longtemps et un désaccord qui vous retrouvera lors d’une migration, d’un audit ou d’une mise à jour fournisseur. Il en va de même des durées de vie étirées bien au-delà de la politique qu’attend l’autre côté.

Alignez plutôt les propositions. Choisissez un groupe que les deux pairs implémentent, placez-le dans la proposition enfant aux deux extrémités, et gardez la politique de renouvellement dans la plage que l’organisation exige réellement.

Prouvez-le avec l’échange qui a échoué

Raccourcissez le temps de renouvellement enfant dans une fenêtre de maintenance pour que l’événement arrive en minutes plutôt qu’en heures, ou déclenchez un renouvellement manuel. Surveillez ensuite un renouvellement réussi et confirmez que le trafic continue à le traverser, car un nouveau handshake qui installe une association enfant mais abandonne le flux applicatif est un autre défaut.

Rétablissez ensuite la durée de vie normale et conservez les deux enregistrements d’événement, celui qui a échoué et celui qui a réussi. La preuve que vous voulez, c’est que la connexion survive à son propre cycle de vie, pas qu’elle ait survécu à un ping.