Votre SA IKEv2 est active mais aucune SA enfant n'existe : lisez l'échange

IKE dit que le tunnel est actif, que la SA enfant manque, et les deux affirmations peuvent être vraies en même temps. Une relation de contrôle établie n'est pas une association de données, et les deux objets ont des durées de vie, des négociations et des modes d'échec distincts. Signaler la première comme une connectivité, c'est ainsi qu'un ticket finit par affirmer que le tunnel est actif alors que rien ne fonctionne. Lisez la liste des associations plutôt que l'étiquette de synthèse de la connexion, car cette liste est le seul endroit où l'objet manquant est visible. Ce qui suit est l'ordre dans lequel la liste prend sens.

Deux associations, deux tâches

Une SA IKE porte le canal de contrôle : identités, clés et les propositions pour l'échange de contrôle lui-même. Une SA enfant porte la protection ESP, avec ses propres algorithmes et ses propres sélecteurs de trafic. L'authentification et la création de la SA enfant vont généralement ensemble, car la première SA enfant est négociée à l'intérieur d'IKE_AUTH, et c'est précisément ce couplage qui surprend les gens quant à la séparation.

Cela explique aussi les deux formes d'échec que vous rencontrerez. Une SA enfant rejetée pendant l'échange initial entraîne normalement la SA IKE avec elle, si bien que vous ne voyez aucun canal de contrôle établi. Une SA IKE qui reste seule signifie plus souvent que la première SA enfant a réussi et qu'une tentative ultérieure de créer une SA enfant a échoué, par exemple lors d'un renouvellement de clés. Les horodatages séparent ces cas plus vite que n'importe quelle revue de configuration.

Quelle couche a refusé

Lorsqu'une SA enfant est rejetée, la notification nomme la couche. Un rejet de proposition signifie que les pairs n'ont pas pu s'accorder sur les algorithmes, souvent parce que l'un exige un autre groupe de secret parfait vers l'avant ou un chiffrement que l'autre n'acceptera pas. Un rejet de sélecteur signifie que l'ensemble de trafic a été refusé d'emblée, et c'est un argument de couverture, non cryptographique.

Parfois l'absence de SA enfant est le design. Une SA IKE sans SA enfant est une extension définie utilisée là où l'association de données doit être créée à la demande, donc l'absence est correcte et la SA enfant apparaît lorsque le trafic correspondant arrive. Les notes de strongSwan sur IKEv2 couvrent à la fois le style à la demande et les réglages de proposition qui décident du premier cas.

Vérifiez s'il existe une configuration à la demande ou un piège avant de diagnostiquer une panne. Si les SA enfant sont créées paresseusement, l'absence de SA enfant au repos est l'état attendu et le vrai test est de savoir si le trafic en fait monter une. Ce test sépare aussi un design paresseux d'une défaillance silencieuse, car une création échouée laisse le déclencheur sans réponse plutôt que simplement au repos.

Puis interrogez le chemin de données

Une fois qu'une SA enfant existe, les compteurs répondent à la question suivante. ip -s xfrm state rapporte les comptes de paquets et d'octets par association, et une SA enfant qui ne porte rien alors que vous générez du trafic pointe vers l'appariement ou le routage plutôt que vers une association manquante. swanctl --list-sas imprime les sélecteurs de la SA enfant à côté de ces compteurs, et c'est ce qui confirme que le paquet se trouve dans l'ensemble accepté.

Gardez l'authentification réussie et l'échange de SA enfant échoué séparés dans le compte rendu. Un rapport qui dit que l'authentification a échoué envoie l'ingénieur suivant au magasin de certificats, et la phrase exacte est bien plus courte : la SA IKE est montée, et la SA enfant pour ce flux n'a jamais été acceptée.

Corrélez les deux extrémités

Pour un serveur que vous exploitez, prenez les journaux du client et de la passerelle pour le même échange au lieu de comparer deux tentatives de reconnexion à une heure d'intervalle. Les notifications devraient concorder des deux côtés, et là où elles ne concordent pas, vous avez trouvé le pair mal configuré.

Corrigez la négociation de la SA enfant, puis retestez avec du trafic à l'intérieur du sélecteur prévu. C'est le seul test qui prouve que l'objet manquant est désormais présent, car une liste d'associations rafraîchie au repos peut sembler identique avant et après la correction.