Votre VPN ne fonctionne qu’après la connexion à cause du trousseau

La commande fonctionne lorsque vous êtes connecté, alors vous la mettez dans un script de démarrage et vous rentrez chez vous. Le lendemain matin, la machine est en ligne et le tunnel ne l’est pas. Le mythe veut qu’une invocation qui fonctionne soit un service qui fonctionne. En pratique, la différence est généralement l’une de deux choses : le profil appartient à votre session utilisateur plutôt qu’au système, ou le secret est déverrouillé par quelque chose qui n’existe qu’après votre connexion. Les deux fonctionnent parfaitement lors d’un test manuel et échouent exactement au moment où personne ne regarde.

Pourquoi la connexion le fait fonctionner

Une connexion graphique démarre un bus de session et un agent du service de secrets, et c’est là que de nombreux clients orientés bureau conservent le mot de passe du profil ou la phrase secrète de la clé privée. Une activation qui s’exécute en tant que votre utilisateur après la connexion peut demander le secret à cet agent et réussir. La même activation exécutée par une unité de démarrage n’a ni session, ni bus, ni agent, si bien que la recherche échoue ou se bloque sur une invite que personne ne voit.

Exécutez le même profil avant et après la connexion et vous obtenez deux résultats différents à partir d’une seule configuration. C’est la signature d’une dépendance aux identifiants, et non d’un tunnel cassé, et cela explique pourquoi un test manuel dans un terminal prouve moins qu’il n’y paraît. Le tunnel va bien ; ce qui déverrouille son secret manque.

Décidez quel propriétaire démarre le tunnel

Il existe deux modèles pris en charge, et les mélanger est l’autre façon dont cela échoue. NetworkManager peut activer une connexion à l’échelle du système, ce qui convient lorsque la machine centralise déjà son réseau à cet endroit. Sinon, une unité systemd dédiée exécute le VPN directement et possède l’interface elle-même.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

Ne faites pas tourner les deux propriétaires sur une même configuration. Si NetworkManager gère l’interface et qu’une unité la monte aussi, ils se disputeront les routes et le DNS, et l’état résultant dépend de qui a terminé en dernier.

Placez le secret là où un service peut le lire

Un service en arrière-plan ne peut pas répondre à une invite. Les phrases secrètes de certificat, les mots de passe de compte et les fichiers d’authentification référencés ont tous besoin d’un agencement de stockage que l’unité peut atteindre sans humain, détenu par le compte qui exécute le service et illisible pour tous les autres.

Le raccourci tentant consiste à rendre le fichier lisible par tous jusqu’à ce que l’erreur de permission disparaisse. Cela échange un échec de démarrage contre une exposition durable des identifiants, et c’est le genre de changement que personne ne revient voir. Utilisez le mécanisme auquel le déploiement fait déjà confiance : un fichier d’identifiants restreint, une clé non chiffrée protégée par les permissions du fichier, ou une connexion à l’échelle du système avec son propre magasin de secrets.

Testez l’événement qui se produit réellement

Démarrer le service manuellement après la connexion ne teste presque rien. Redémarrez, ou désactivez la connexion graphique pendant un cycle, et regardez l’unité se lever d’elle-même. C’est le seul test qui exerce ensemble la disponibilité des identifiants, l’état du réseau et l’ordre des unités. C’est aussi le test qui reproduit la panne signalée par l’utilisateur, ce qu’un démarrage manuel ne fait jamais.

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

L’ordre compte autant que les identifiants. Une unité qui démarre avant que la liaison montante sous-jacente ne soit configurée abandonnera, et certaines distributions diffèrent sur le point de savoir si elles attendent la connectivité. Si l’unité signale un échec au démarrage mais réussit lorsqu’elle est lancée à la main trente secondes plus tard, vous avez trouvé un problème d’ordre et non un problème de secret.

Vérifiez les routes et le DNS, pas seulement l’interface

Une interface qui existe n’est pas un tunnel qui fonctionne. Après un démarrage sans surveillance, vérifiez les routes, l’état du résolveur et une destination par adresse avant de vérifier un nom. Vérifiez ensuite l’application pour laquelle le tunnel existe.

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

Si l’adresse fonctionne et que le nom non, le problème restant est la politique DNS et non le tunnel. Notez quel propriétaire démarre le service et où vit le secret, car la prochaine personne à redémarrer cette machine aura besoin des deux faits.