L’échange IKEv2 aboutit, puis l’authentification échoue : où chercher

Un client qui reçoit une réponse IKEv2 a prouvé que la passerelle est joignable, que les deux parties peuvent négocier une proposition et que l’échange de clés initial s’est terminé. Il n’a pas prouvé que quiconque est authentifié. L’échange suivant transporte des identités, des certificats ou EAP, et c’est là que la connexion s’arrête généralement. Lire laquelle de ces vérifications a échoué, c’est tout le diagnostic, et le message d’erreur seul le dit rarement.

Vérification 1 : lire l’étape, pas le message

Un rejet peut venir de trois endroits : le client qui refuse l’identité du serveur, la passerelle qui refuse la preuve du client et un service d’authentification externe qui refuse le compte.

Chacun produit une ligne de journal différente sur une machine différente, et chacun a un correctif différent. Un rejet côté client du certificat du serveur est un problème de confiance ou de nommage sur le client ; un rejet côté passerelle du certificat du client est un problème de confiance sur la passerelle ; un échec EAP est un problème de compte ou de back-end. Le message que vous voyez est généralement le résumé par le client de l’un de ces cas, ce qui explique pourquoi le journal de la passerelle compte autant que celui du client.

Vérification 2 : quelle identité a été contrôlée

Un client peut refuser le certificat du serveur ou l’identité attendue avant qu’aucun identifiant utilisateur ne soit proposé, et une adresse de serveur qui fonctionne ne remplace pas ce contrôle. L’identifiant attendu par le client doit correspondre à ce que présente la passerelle, ce qui est un fait de configuration et non un fait de réseau.

En termes strongSwan, il s’agit de rightid côté client et de l’identité propre de la passerelle de l’autre côté, et une discordance échoue avant même que EAP ne soit abordé.

La passerelle, séparément, peut refuser le certificat du client, sa preuve de clé ou l’authentification de son compte, et ces trois cas ne sont pas interchangeables. Réinitialiser le mot de passe d’un utilisateur ne renouvelle pas un certificat d’appareil, et réinstaller un certificat d’appareil ne corrige pas une identité de serveur erronée. Pour les échecs de certificat, vérifiez d’abord l’horloge, puis la chaîne de confiance, puis l’identifiant attendu ; un client dont l’horloge est décalée de quelques minutes échoue à un contrôle de validité qui ressemble à un échec de confiance. swanctl --list-certs aux deux extrémités montre ce que chaque partie détient réellement.

Vérification 3 : si EAP est en jeu

Le client et le serveur doivent s’accorder sur une méthode prise en charge, et le back-end doit accepter l’identité fournie.

Un nom d’utilisateur peut nécessiter un suffixe de domaine ou un format de compte particulier exigé par le déploiement, et ce format est documenté plutôt que devinable. Fournir les champs documentés par l’opérateur est plus rapide que d’essayer des variantes, et cela évite un second problème : des tentatives répétées peuvent déclencher un verrouillage de compte, qui masque ensuite l’étape d’origine derrière un nouvel échec. Si la méthode est EAP-MSCHAPv2 contre un annuaire, l’échec peut appartenir à l’annuaire plutôt qu’au VPN.

Ne testez pas les problèmes d’identité en désactivant les contrôles d’identité. Cela transforme un échec diagnosticable en échec non diagnosticable et laisse la connexion plus faible qu’avant.

Vérification 4 : ce qui se passe après une connexion réussie

Une fois IKE_AUTH terminé, la négociation CHILD_SA décide quels sélecteurs de trafic sont installés, et c’est là qu’une connexion peut réussir tout en ne faisant rien passer.

Une connexion récemment fonctionnelle révèle souvent un problème de sélecteur ou de route qui était auparavant masqué par l’échec d’authentification. Si le tunnel monte et qu’une application ne joint toujours pas sa destination, examinez les sélecteurs et les routes négociés plutôt que l’identité. Modifier les paramètres d’identité à ce stade vise la mauvaise étape et casse généralement une connexion qui fonctionne. Confirmez avec swanctl --list-sas, qui montre les enfants et leurs sélecteurs séparément de l’IKE SA.

Vérification 5 : ce qu’il faut transmettre au support

Une chronologie expurgée et le rejet précis valent plus qu’une exportation de diagnostic complète, et l’exportation peut contenir des clés privées ou des identifiants que vous ne devriez pas partager.

Notez l’heure avec le fuseau horaire, les versions du client et de la passerelle, la méthode, la chaîne d’identité proposée plutôt que le mot de passe, et l’étape exacte qui l’a rejetée. La documentation de configuration IKEv2 de strongSwan décrit les paramètres d’identité et EAP qui déterminent ces résultats, et c’est la référence à lire avant de modifier un champ. Changez ensuite une seule chose et retestez une connexion neuve, car une session en cache vous parlera de l’ancienne configuration.