IKE-SA établie, CHILD-SA absente : où les données s’arrêtent

Le client dit s’être authentifié, l’état IKE paraît sain et les compteurs de paquets restent à zéro. Cette combinaison n’est pas une contradiction : IKEv2 garde séparées la relation de contrôle et la relation de données, et la première peut réussir tandis que la seconde ne monte jamais. Le parent mène la négociation, l’enfant porte le trafic. Lisez les deux couches séparément avant de déclarer le tunnel hors service.

Ce que font les deux SA

L’IKE-SA est la relation de contrôle : elle authentifie les pairs et transporte les échanges qui négocient, remplacent et suppriment la protection. Elle ne transporte jamais les paquets de vos applications. Un parent sain prouve donc seulement que les deux extrémités peuvent s’accorder sur une politique de sécurité, et rien de plus.

Une CHILD-SA est la relation de données, créée sous le parent, avec des sélecteurs de trafic et du matériel de clé pour un ensemble protégé. Elle est directionnelle, donc la sortie d’état liste une association entrante et une sortante avec des identifiants distincts, et généralement des compteurs distincts pour chaque direction. Cet appariement explique pourquoi une direction peut fonctionner alors que l’autre tombe, et pourquoi la phrase le tunnel est monté ne dit rien du trafic. Un parent peut aussi porter plusieurs enfants, et c’est ainsi qu’une seule étiquette de connexion cache celui dont vous avez besoin.

Lisez les entrées enfants, pas l’étiquette de connexion

Ouvrez ensemble l’état du parent et la liste des enfants, et trouvez l’enfant dont les sélecteurs correspondent au flux que vous testez. Notez ses sélecteurs de trafic, les algorithmes négociés, sa durée de vie et les compteurs dans les deux sens. S’il existe plusieurs enfants, comparez par sélecteurs et non par position, car la position change après un renouvellement de clés. Écrivez les identifiants avant de modifier quoi que ce soit.

Si le parent liste un ensemble de trafic différent de celui que vous testez, vous lisez le mauvais enfant. C’est un problème de sélecteurs, pas un tunnel cassé.

Notez aussi les horodatages. Un renouvellement de clés peut remplacer une couche pendant que l’autre reste établie, et un enfant qui semble neuf peut être le remplaçant de celui que vous surveilliez. Comparez les identifiants avant de conclure qu’un enfant a disparu.

Quand aucun enfant n’existe

L’authentification peut réussir tandis que la proposition de données ou les sélecteurs échouent, et le parent reste sans aucun enfant. La cause habituelle est une divergence d’algorithme ou de sélecteurs de trafic, et les deux pairs journalisent la proposition refusée. Lisez les deux extrémités, car le côté que vous atteignez peut n’afficher que le refus. Corrigez la divergence au lieu de redémarrer le parent, ce qui répète la même négociation ratée et ajoute une coupure aux preuves.

Un parent qui se rétablit sans cesse est une panne différente d’un parent qui reste debout sans enfant. Dans le second cas, les journaux nomment la proposition refusée, alors recueillez cette proposition des deux extrémités avant de modifier une politique.

Quand l’enfant existe mais que les compteurs restent à zéro

Envoyez une requête neuve qui corresponde aux sélecteurs de l’enfant. Une requête vers une destination hors de cette politique ne fera pas bouger ses compteurs, aussi réussie paraisse-t-elle.

Vérifiez la route qui doit pousser le flux dans le tunnel, car un enfant sans trafic est souvent un enfant vers lequel rien n’est routé. Des compteurs qui ne bougent que dans un sens indiquent une divergence de sélecteurs ou de politique sur le chemin de retour. Regardez les sélecteurs de retour du pair distant avant de toucher au côté local. Une requête neuve vous donne aussi un horodatage à corréler avec la sortie d’état des deux extrémités.

Nommez la couche dans le rapport

Rapportez la panne sous forme de trois champs plutôt que d’un verdict : la couche qui a échoué, l’échange ou l’enfant que vous avez inspecté, et les preuves dont vous disposez. La couche est l’une des trois : le parent ne s’est jamais établi, la négociation de l’enfant a été refusée, ou un enfant existe et le trafic ne l’atteint pas. La preuve est l’identifiant de l’enfant avec ses sélecteurs et ses compteurs, ou la proposition refusée citée depuis les deux journaux. Quiconque lit cela peut aller droit à l’échange qui compte au lieu de demander quel VPN vous voulez dire.

La documentation strongSwan sur IKEv2 montre comment ces couches apparaissent dans la sortie d’état. Joignez la sortie de l’enfant que vous avez testé, pas seulement le résumé du parent.