Pourquoi un service VPN démarré au boot ne peut pas lire votre trousseau de clés

Une connexion qui fonctionne après la connexion utilisateur et échoue avant signifie généralement que la tentative au démarrage n’a pas pu obtenir un secret, et non que le serveur en a rejeté un. L’identifiant existe ; le contexte qui le demande, non. Cette seule distinction évite une réinitialisation de mot de passe inutile.

Suivez la requête : quelque chose démarre la connexion avant qu’une session de bureau existe, et le magasin de secrets qui répond normalement n’est pas encore déverrouillé. Les deux contextes ne sont pas d’accord sur qui possède le secret, et le profil enregistre lequel des deux est censé le fournir.

Ce que le chemin de démarrage demande réellement

Au démarrage, NetworkManager se lance comme service système sans session utilisateur, sans D-Bus de session et sans trousseau de clés déverrouillé. Un profil de connexion peut tout de même être monté, mais uniquement avec des secrets que le service peut atteindre lui-même. Tout ce que possède un agent de secrets attend qu’un humain se connecte et que l’agent apparaisse. Le service fait exactement ce que dit sa configuration ; c’est le profil qu’il faut changer.

L’échec est inscrit dans la connexion plutôt que caché dans un trousseau de clés.

Lire les indicateurs de secret d’une connexion

Demandez à la connexion ce qu’elle attend, pas ce dont le bureau se souvient. La colonne des indicateurs répond directement à la question, et elle survit aux redémarrages dans le fichier de profil sur le disque.

Commencez par la liste des profils, puis confirmez quelle connexion est configurée pour monter d’elle-même. Ensuite, exportez une connexion et lisez les indicateurs de mot de passe :

nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show
nmcli connection show "Work VPN" | grep -i -E "password|secret|key"
journalctl -b -u NetworkManager --grep "secret"

La première commande confirme quels profils existent et si l’un est configuré pour la connexion automatique, ce qui est la façon dont une tentative sans surveillance démarre. La deuxième expose les valeurs des indicateurs, et la troisième montre le service se plaindre qu’aucun agent n’a répondu pour un secret donné. Une ligne de journal qui nomme un secret comme appartenant à un agent, c’est tout le diagnostic en une phrase.

Pourquoi déplacer la connexion vers la portée système change la réponse

Une connexion possédée par un utilisateur est activée sous l’agent de cet utilisateur, c’est pourquoi elle fonctionne parfaitement une fois le bureau lancé. La déplacer vers la portée système retire l’agent du chemin, si bien que le même profil se comporte différemment sans qu’une seule ligne de configuration VPN change.

Ce déplacement est une conception légitime, et il porte une exigence : le secret doit être accessible au service système. Le stocker dans le profil, le fournir via un identifiant de portée système ou accepter une invite interactive au bon moment sont toutes des réponses valables. Laisser l’indicateur 1 et espérer, non.

Une clé privée avec sa propre phrase secrète ajoute une seconde couche. Même un mot de passe de compte stocké ne déverrouillera pas une clé qui demande une phrase secrète, alors vérifiez quel secret l’étape défaillante demande réellement avant de changer quoi que ce soit.

Ce qu’il ne faut pas faire, et ce qu’il faut faire à la place

Rendre chaque fichier d’identifiants lisible par tous, ou désactiver l’authentification pour qu’aucune invite ne soit nécessaire, échange une gêne au démarrage contre une exposition permanente. Les deux masquent aussi la dépendance au lieu de la résoudre, et la prochaine mise à jour de l’image réintroduit la même panne.

Utilisez à cette étape le mécanisme que votre distribution documente pour l’activation sans surveillance, puis confirmez que les indicateurs du profil y correspondent. Vérifiez le résultat depuis un démarrage propre, pas depuis un shell qui a déjà un agent. Notez le propriétaire de la connexion, la source du secret et l’étape qui doit fonctionner, afin qu’un changement ultérieur de démarrage automatique ne puisse pas réintroduire silencieusement une dépendance au fait que quelqu’un déverrouille d’abord un bureau. La documentation fait la différence entre un service réparé et un service qui retombe en panne au prochain trimestre.

Testez depuis un démarrage propre contrôlé plutôt que depuis une nouvelle tentative manuelle après connexion. La nouvelle tentative réussit pour la raison même qui a fait échouer la tentative au démarrage, et c’est précisément la preuve qu’un test rapide détruit.