IKEv2 n'est pas un seul échange : IKE SA, authentification, puis CHILD SA
La réponse d'une passerelle prouve l'accessibilité, pas l'identité. Suivez IKE_SA_INIT, IKE_AUTH et le premier CHILD SA, puis vérifiez ce qui doit être vrai avant que le trafic ne circule.
Vous pouvez croire qu'une connexion IKEv2 est un seul échange qui se termine par le chiffrement de votre trafic. Il y en a au moins deux, et le premier n'authentifie personne. Les pairs commencent par des messages de contrôle, s'accordent sur des paramètres cryptographiques, prouvent leur identité et ne négocient qu'ensuite l'état qui transporte les paquets applicatifs. Cet ordre explique le décalage que les gens signalent sans cesse : la passerelle répond, le client affiche connecté, et l'application privée expire toujours. Voici ce que fait réellement chaque étape, et ce qui doit être vrai après elle.
Le mythe : si la passerelle répond, vous êtes connecté
Une réponse au premier message prouve que le point d'extrémité est joignable et disposé à parler. Elle ne prouve pas qu'un compte a été accepté, qu'une chaîne de certificats a été validée, ni qu'une politique de données a été installée.
Ces échecs arrivent plus tard, et ils produisent des symptômes différents. Un rejet de certificat ou un échec EAP survient après que le premier échange a déjà réussi, ce qui explique pourquoi un ping vers UDP 500 et une icône verte dans le client vous apprennent si peu.
IKE_SA_INIT : s'accorder sur des paramètres, pas sur une identité
Le premier échange porte les propositions pour l'association de sécurité IKE : algorithmes de chiffrement et d'intégrité, fonction pseudo-aléatoire et groupe Diffie-Hellman. Les pairs échangent aussi des nonces, et chaque côté dérive le matériel de clés de l'IKE SA à partir du secret partagé que ces valeurs produisent. Rien dans cet échange n'établit qui est l'autre partie. Il établit que les deux côtés peuvent calculer les mêmes clés et qu'ils s'accordent sur une proposition. Un répondeur à qui aucune proposition ne plaît rejette l'échange ici, et c'est pourquoi une incompatibilité de version ou d'algorithme ressemble à un serveur hors service.
L'IKE SA créé à ce stade protège tous les échanges de gestion ultérieurs. C'est son travail, et c'est un travail différent de la protection de vos paquets.
IKE_AUTH : prouver l'identité, puis construire le premier CHILD SA
Le second échange porte l'identité. Avec des certificats, chaque pair signe avec sa clé privée et présente une chaîne que l'autre doit valider ; avec EAP, le répondeur met l'initiateur au défi par la méthode choisie. C'est là qu'un mauvais nom de serveur, un certificat expiré ou un mot de passe refusé finit par apparaître.
Dans le cas normal, IKE_AUTH négocie aussi le premier CHILD SA, si bien que la protection des données est convenue dans le même aller-retour. L'initiateur propose des sélecteurs de trafic, le répondeur les restreint ou les refuse, et les clés du chemin de données sont dérivées de l'IKE SA. Cela signifie qu'un seul échange peut échouer à deux endroits très différents : l'identité ou la politique. Lisez la charge utile de notification ou l'erreur plutôt que l'échec générique de la négociation, parce que le correctif de l'un est un certificat et celui de l'autre un décalage de sous-réseau.
Deux SA, deux rôles
| Association | Protège | Comportement de durée de vie |
|---|---|---|
| IKE SA | Échanges de gestion : renouvellement des clés, suppression, charges utiles de configuration | Renouvelé selon son propre calendrier ; le chemin de données peut survivre au changement |
| CHILD SA | Trafic applicatif correspondant aux sélecteurs de trafic | Renouvelé indépendamment, souvent plus fréquemment |
Les garder séparés explique deux comportements qui ressemblent à des bogues. Un tunnel peut apparaître établi alors qu'un renouvellement de clés échoue en arrière-plan, et un CHILD SA peut être remplacé sans que le client perde la connexion.
Sur strongSwan, la référence de configuration IKEv2 et swanctl --list-sas montrent les deux niveaux, et ip xfrm state plus ip xfrm policy montrent ce que le noyau a réellement installé. Comparer ces deux vues est le moyen le plus rapide de voir si la négociation a abouti ou si elle en a seulement eu l'air. Si le démon liste un CHILD SA pour lequel le noyau n'a aucun état, l'installation a échoué en silence. Si le noyau détient un état que le démon ne connaît pas, vous regardez un reste d'une tentative précédente.
Ce qui doit encore être vrai une fois le tunnel monté
Les sélecteurs de trafic définissent quelles adresses sont couvertes. Si le client propose un sous-réseau et que le serveur en attend un autre, le CHILD SA s'installe mais ne transporte rien d'utile, et l'erreur apparaît comme un problème de routage plutôt que de négociation. Ensuite, la pile locale doit coopérer : transfert activé là où l'hôte route, routes pointant vers le tunnel, règles de pare-feu autorisant les paquets décapsulés et un résolveur interne si des noms privés sont impliqués. Chacun de ces points échoue séparément et aucun n'est corrigé en redémarrant le démon IKE.
Gardez le journal visible pendant le diagnostic : l'échange initial, puis la validation d'identité, puis l'authentification utilisateur là où elle s'applique, puis l'installation du CHILD, puis le trafic applicatif. L'étape qui s'arrête est celle à corriger, et un échec de routage ultérieur n'est jamais une raison de relâcher les contrôles d'identité déjà passés.