PSK L2TP/IPsec refusée : passez par la boîte de dialogue, puis par les fichiers

Vous collez la clé pré-partagée du message de l’administrateur dans la boîte de dialogue NetworkManager, cochez la case pour l’afficher, et elle correspond caractère pour caractère. La connexion se termine quand même par un échec d’authentification avant que le tunnel soit monté. La première fois que j’ai vu cela, j’ai supposé que la clé était fausse ; elle ne l’était pas. Deux autres choses décident de ce que le démon lit réellement : le fichier de secrets que le greffon écrit pour cette connexion, et le fait que la valeur ait traversé la boîte de dialogue sans changement.

Le parcours ci-dessous suit la clé du champ jusqu’au fichier, et c’est cet ordre qui vous dit où elle s’est perdue. Faites-le sur la machine qui échoue, pas sur celle qui fonctionne, car la différence entre ces deux machines est généralement la disposition des fichiers et non la clé.

Commencez par la boîte de dialogue, mais ne faites pas confiance au champ

Ouvrez l’onglet IPsec de la connexion et retapez la clé au lieu de la coller. Une clé copiée depuis un message de chat, un PDF ou un gestionnaire de mots de passe peut arriver avec un saut de ligne final que le champ n’affiche pas, et les caractères visibles semblent toujours corrects.

Cliquez sur la commande d’affichage du mot de passe et regardez la fin de la chaîne, pas le milieu. Si le curseur laisse une ligne vide sous le texte, supprimez-la et retapez le dernier caractère. Cette seule correction règle une part surprenante de ces signalements, et elle coûte moins que la lecture de n’importe quel journal.

Si la clé vient d’un système de tickets qui coupe les longues lignes, demandez-la par un canal qui ne les coupe pas. Comparez les longueurs avec l’administrateur plutôt que d’examiner deux chaînes côte à côte ; un caractère perdu à un point de coupure est invisible dans une police proportionnelle.

Suivez la clé dans /etc/ipsec.d

Le greffon ne transmet jamais la PSK au démon IPsec comme argument sur une ligne de commande. Il stocke plutôt la valeur dans un fichier de secrets et fait en sorte que le démon inclue ce fichier, en ajoutant une ligne include dans /etc/ipsec.secrets s’il n’y en a pas. Ce que la boîte de dialogue détient est une entrée pour ce fichier généré, pas la valeur en usage.

Listez ce qui existe avant de changer quoi que ce soit :

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Les anciennes versions du greffon écrivaient un fichier par connexion, nommé d’après l’UUID de la connexion, par exemple /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Supprimer un profil dans l’applet ne supprime pas ce fichier de manière fiable. Si un ancien fichier d’un serveur précédent est encore sur le disque et encore inclus, le démon peut choisir un secret appartenant à un profil que vous n’utilisez plus, et la connexion échoue alors que le champ visible est correct.

Comprenez ce que le changement 1.2.12 a fait aux mises à niveau

La version 1.2.12 du greffon a remplacé les fichiers de secrets par connexion par un seul fichier partagé, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Une mise à niveau ne nettoie pas les anciens fichiers par UUID, et une ligne include /etc/ipsec.d/*.secrets existante les inclut toujours. La version 1.2.16 a changé le traitement des propositions par défaut, pas la disposition des secrets.

Cette histoire explique pourquoi deux machines dotées de ce qui ressemble au même profil se comportent différemment. La clé est identique ; l’ensemble des fichiers que le démon inclut ne l’est pas. Quand vous retirez un fichier orphelin, mettez-le de côté plutôt que de le supprimer, confirmez la connexion, puis supprimez-le une fois l’état fonctionnel consigné. Le renommer garde l’ancienne valeur récupérable si la panne se révèle être ailleurs.

Séparez les caractères que le format de stockage ne peut pas contenir

La documentation strongSwan sur la chaîne de secret partagé indique que la valeur ne peut contenir ni saut de ligne ni guillemet double. Une clé collée depuis un document peut porter l’un ou l’autre sans aucune différence visuelle dans une boîte de dialogue normale.

Depuis 1.2.12, la valeur stockée n’est plus du texte brut. Le greffon encode la PSK en base64 avant qu’elle atteigne le fichier, et les notes de version présentent cet encodage comme la raison pour laquelle un guillemet double est désormais acceptable dans une clé. Un guillemet tapé dans le champ est donc représentable ; ce n’est pas vrai de tous les caractères de contrôle.

La longueur est une autre contrainte. Aucun minimum universel ne s’applique aux logiciels L2TP/IPsec : certains clients acceptent des clés plus courtes que vingt caractères et certaines passerelles imposent un minimum. Si une clé courte est refusée, la règle relève de la politique du serveur ou de la validation de ce client, et relever quelque chose localement n’y changera rien.

Lisez quelle couche d’authentification a échoué

Exécutez d’abord ipsec --version, car strongSwan et Libreswan utilisent des noms de fichiers et une syntaxe différents, et un conseil pour l’un peut endommager l’autre. Lisez ensuite l’étape de l’échec dans le message du client ou le journal du démon : une plainte au sujet de la clé pré-partagée est un événement différent d’un nom d’utilisateur et d’un mot de passe refusés.

La PSK authentifie les extrémités du tunnel. Le nom d’utilisateur et le mot de passe authentifient la personne à l’intérieur de L2TP, et PPP s’en occupe une fois l’association IPsec montée. Une PSK correcte avec un mauvais compte échoue quand même, et changer de compte ne réparera pas une clé que le démon n’a jamais lue correctement.

Quand vous fermez le ticket, notez les quatre éléments : version du greffon, fichier de secrets utilisé, si la clé a été retapée ou collée, et la couche nommée dans l’erreur. Ainsi, quiconque refera ce parcours plus tard pourra sauter directement à la différence entre la machine qui fonctionne et celle qui échoue.