Même profil, deux sessions : il se connecte depuis le bureau et reste bloqué en SSH sur une invite que rien ne peut satisfaire. Rien n'est cassé et aucun réglage n'est perdu. NetworkManager demande l'identifiant à un agent de secrets, et un agent de secrets est un composant de bureau qui n'existe pas dans la session que vous utilisez.

Exécutez la séquence ci-dessous et le tunnel monte sans interface graphique, à la réserve que stocker un secret change qui peut utiliser ce profil.

Confirmez le diagnostic avant de modifier quoi que ce soit

La différence entre activation interactive et non interactive, c'est tout le diagnostic. Si nmcli --ask connection up réussit alors qu'une activation ordinaire bloque, le profil est correct et la source du secret manque. Cette seule comparaison vous évite de réécrire une configuration qui fonctionne.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office IPsec" | grep -i flags

Lisez les indicateurs au lieu de les deviner. Les valeurs qui signifient « demander à un agent » sont ce que vous cherchez, et les noms exacts des clés diffèrent d'un greffon VPN à l'autre parce qu'ils vivent dans le dictionnaire de données propre au greffon. Un profil FortiSSL et un profil IPsec n'utilisent pas nécessairement les mêmes noms, alors partez de la sortie de votre propre profil.

Vérifiez aussi que le paquet du greffon pour ce protocole est installé. Un greffon manquant se manifeste comme un type de connexion inconnu ou une erreur d'activation qui ne dit rien sur les mots de passe, et courir après le secret dans cet état fait perdre la même heure deux fois. Une requête de paquet coûte moins qu'un après-midi entier à éditer des fichiers de clés.

Déplacez le secret dans le fichier de clés

Le fichier de connexion se trouve sous /etc/NetworkManager/system-connections/. Les secrets n'y sont pas conservés par défaut, et c'est tout l'intérêt des indicateurs que vous venez de lire. Passer un indicateur à zéro dit à NetworkManager que la valeur est stockée avec le profil au lieu d'être demandée à l'activation.

[vpn]
password-flags=0

[vpn-secrets]
password=YOUR-VPN-PASSWORD

Pour un profil à deux secrets, le schéma se répète : un indicateur par secret dans la section [vpn], et les valeurs dans [vpn-secrets]. Un profil IPsec porte généralement une clé pré-partagée à côté de l'identifiant utilisateur, et le greffon les nomme différemment d'un champ de mot de passe ordinaire, alors copiez les noms de clés depuis la sortie de vpn.data plutôt que depuis un billet de blog qui utilisait un autre greffon. Un seul nom de clé erroné produit un profil qui se charge puis échoue à l'authentification, ce qui se lit exactement comme un mauvais mot de passe. Comparez votre fichier à un profil qui fonctionne du même greffon avant de vous reconnecter.

Mettez entre guillemets les valeurs qui contiennent des espaces, des guillemets ou un signe dollar. Une valeur sans guillemets contenant un $ sera lue littéralement ou développée selon l'endroit où elle est analysée, et l'échec d'authentification qui en résulte ressemble à un mauvais mot de passe.

Corrigez ensuite le propriétaire et le mode du fichier. Ces fichiers de clés sont lus par un service privilégié, et un fichier que d'autres utilisateurs peuvent lire est considéré comme non fiable, ce qui est la raison habituelle pour laquelle un profil modifié semble ignoré. Propriétaire root, mode 600, sans exception.

Rechargez, puis activez

Le fichier est lu au chargement de la connexion, donc l'éditer ne suffit pas. Rechargez les profils puis montez la connexion explicitement.

sudo nmcli connection reload
sudo nmcli connection up "Office IPsec"

Si le rechargement ne prend pas la modification, un redémarrage complet du service le fait, et des rapports existent sur exactement cela. Préférez le rechargement quand d'autres liens comptent, car redémarrer le service coupe chaque connexion gérée, et sur un hôte distant cela peut terminer votre session avant que le tunnel voulu ne monte.

Utilisez l'UUID quand les noms sont ambigus. Les machines à plusieurs profils clients accumulent des quasi-doublons, et activer le mauvais produit un échec qui ressemble à un problème d'identifiants.

Quand le secret stocké n'est pas le problème

Un profil FortiSSL peut échouer même avec un identifiant stocké correct parce que le client ne fait jamais confiance au certificat de la passerelle. Ce réglage n'est pas dans la boîte de dialogue principale ; il se trouve derrière les options avancées du VPN, où l'empreinte du certificat de confiance est saisie. Si le journal mentionne le certificat plutôt que le mot de passe, vous êtes dans cette branche et aucune quantité d'édition de [vpn-secrets] n'aidera.

Deux autres vérifications ont leur place ici. Confirmez que le profil n'a pas été importé d'un fichier qui pointe encore vers un chemin que le greffon ne peut pas lire, et confirmez que le profil est bien l'actif et non un doublon obsolète. Les deux produisent des échecs d'activation qui se lisent comme des erreurs d'authentification.

Décidez si le stockage est acceptable

Une PSK et un mot de passe stockés sont lisibles par tout ce qui tourne en root sur cette machine. Sur une machine que vous contrôlez, c'est un compromis raisonnable pour un service sans interface. Sur un hôte partagé, cela mérite une conversation, car le profil contient désormais un identifiant qui était auparavant protégé par le porte-clés du bureau. Demandez qui d'autre peut atteindre root sur cet hôte avant de décider, pas après que le changement est en place.

Si la politique interdit de stocker des secrets VPN, n'affaiblissez pas le profil pour faire fonctionner une tâche cron. Lancez la connexion depuis une session qui dispose d'un agent, ou utilisez un autre mécanisme pour l'automatisation.

Enfin, notez quels profils portent des secrets pour que personne n'en copie un sur un portable sans s'en apercevoir. Un commentaire au-dessus de la section des secrets avec la date et la raison suffit, et il épargnera à quelqu'un une revue gênante plus tard.

Articles similaires