OpenVPN au démarrage sous Ubuntu : NetworkManager ou systemd ?

La plupart des guides présentent ce choix comme cosmétique : soit vous laissez NetworkManager monter le tunnel, soit vous activez une instance systemd et c’est terminé. Les deux chemins diffèrent sur un point qui décide du résultat sur une machine sans écran, et il n’a rien à voir avec l’outil le plus récent. NetworkManager déverrouille les secrets par une session ; une instance systemd n’a aucune session à déverrouiller. Choisissez celle dont la gestion des secrets correspond à la machine devant vous.

Tout le reste, de l’installation des routes au comportement de reconnexion, découle de cette première décision.

Le trousseau de clés est la différence dont personne ne parle

Quand NetworkManager possède un profil VPN, le mot de passe peut vivre dans le trousseau de connexion, qui est déverrouillé lorsqu’un utilisateur se connecte. Cela fonctionne bien sur un portable : la personne est présente, le trousseau s’ouvre, le tunnel monte. Sur un serveur qui démarre sans surveillance, personne n’est là pour déverrouiller quoi que ce soit, donc le profil attend un secret qui n’arrive jamais. La connexion semble configurée et ne s’active jamais.

L’instance systemd évite ce problème en lisant un fichier d’identifiants sur le disque, ce qui fait du fichier ce que vous protégez. chmod 400 plus la propriété par root est le minimum, et le fichier devrait rester hors des sauvegardes et des modèles d’image que vous ne contrôlez pas.

Attacher le VPN à une connexion ne garantit pas le démarrage

Dans nm-connection-editor, sélectionnez la connexion filaire ou sans fil plutôt que le VPN, ouvrez l’onglet General, cochez l’option de connexion automatique à un VPN et nommez le profil. NetworkManager active alors le VPN comme connexion secondaire lorsque la connexion principale atteint l’état connecté. C’est une dépendance, pas une règle de pare-feu. Les paquets peuvent encore sortir pendant les secondes qui précèdent le montage du tunnel, et un secret stocké qui ne se déverrouille pas laisse la machine en ligne sans lui.

Si l’exigence est que rien ne sorte sans le tunnel, dites-le et construisez un coupe-circuit, car ce réglage n’en fournira pas. Testez aussi la mise en veille et la reprise, car la connexion secondaire est réévaluée au retour.

L’instance systemd a besoin d’un nom de fichier qui correspond

Placez le profil dans le répertoire client attendu par le paquet, par exemple /etc/openvpn/client/office.conf, et référencez-y le fichier d’identifiants avec auth-user-pass office.cred. Le nom de l’instance est le nom du fichier sans le suffixe, donc openvpn-client@office lit office.conf. Activez-la avec sudo systemctl enable --now openvpn-client@office et confirmez la correspondance avec systemctl cat openvpn-client@office au lieu de faire confiance à un exemple de blog.

Les chemins à l’intérieur du profil sont résolus par rapport au répertoire de travail de l’unité, pas au profil lui-même, donc une ligne relative ca ou auth-user-pass peut échouer au démarrage alors qu’elle fonctionne lors d’un test manuel. Utilisez des chemins absolus pour tout ce que l’unité doit trouver. Ensuite, lisez journalctl -u openvpn-client@office -b après un vrai démarrage ; une unité qui se déclare active sans tunnel nomme généralement un fichier manquant dans ce journal.

Les paquets plus anciens fournissent un autre nom de modèle, donc systemctl list-unit-files 'openvpn*' détermine lequel existe sur cet hôte.

Le comportement de reconnexion est une décision distincte

Un profil avec ping-restart reconstruit le tunnel après une chute, et une unité avec une directive de redémarrage fait quelque chose de similaire au niveau du service. Ce sont des politiques que vous choisissez, pas des valeurs par défaut que vous héritez. Si la connexion ne doit monter qu’à la demande, retirez délibérément le comportement de redémarrage et notez pourquoi. Si l’unité démarre avant que le réseau soit utilisable, elle a besoin d’une politique de nouvelle tentative, car une tentative ratée au démarrage ne se répète pas d’elle-même.

L’arrêt est tout aussi littéral : sudo systemctl disable --now openvpn-client@office arrête l’instance en cours et supprime le lien de démarrage. La désactivation seule laisse le tunnel tourner jusqu’au prochain redémarrage, ce qui surprend quiconque teste en désactivant et en regardant l’interface rester active.

Redémarrez, puis vérifiez quatre choses dans l’ordre

Redémarrer le service teste le service ; redémarrer la machine teste le chemin de démarrage. Après le redémarrage, confirmez que l’unité est montée, puis qu’une route existe pour le sous-réseau distant, puis quelle adresse la machine présente à internet, et enfin que les noms se résolvent par le tunnel. Ces quatre vérifications échouent dans cet ordre quand quelque chose ne va pas, ce qui rend le premier échec utile.

Une unité active sans route signifie généralement que le profil s’est connecté mais que le serveur n’a poussé aucune route, ou que la route a été installée sur une interface qui a ensuite disparu. Une route sans résolution de noms fonctionnelle pointe vers la configuration DNS plutôt que vers le tunnel lui-même.

Décidez à l’avance de ce qui doit se passer lorsque le tunnel ne peut pas monter. Revenir à une connectivité simple est une politique, et elle devrait être écrite plutôt que laissée au gestionnaire qui a démarré en premier.