Systemd ou NetworkManager : qui démarre le VPN au boot ?

Deux machines Ubuntu issues de la même image, un seul profil VPN, des résultats opposés à la connexion : sur l’une, le tunnel est déjà monté avant l’apparition du bureau, sur l’autre il ne monte jamais. Le profil n’est pas la variable ici. Ce qui diffère, c’est lequel de trois composants a reçu l’ordre de le démarrer, et ces trois-là ne partagent pas un même interrupteur.

Les comparer côte à côte est plus rapide que deviner. Chacun échoue d’une manière reconnaissable, et c’est précisément ce qui rend la comparaison utile.

Trois démarreurs, trois déclencheurs différents

Le service openvpn empaqueté est la voie la plus ancienne. Son script d’init lit une liste de démarrage automatique dans /etc/default/openvpn. Si cette liste est commentée ou laissée vide, le script démarre toutes les configurations qu’il trouve dans ce répertoire plutôt que celle que vous avez ajoutée. Un seul fichier ajouté pour un tunnel peut en monter plusieurs sans bruit.

La deuxième ligne est celle que les gens configurent mal. NetworkManager détient le profil importé et le lancera, mais uniquement comme secondaire d’une autre connexion, ce qui signifie que le déclencheur appartient à la liaison réseau et non au VPN.

Comparez le coût de mise en place et la portée

La voie du script d’init coûte une ligne et couvre toutes les configurations de la machine. C’est bien pour un routeur et faux pour un portable qui rejoint des réseaux différents. La voie NetworkManager coûte une recherche d’UUID et lie le tunnel à une connexion de base. Il monte sur le Wi-Fi du bureau et reste en bas sur un réseau d’hôtel.

Une unité écrite à la main coûte le plus cher et achète le plus de contrôle, y compris l’ordonnancement par rapport aux autres services. La portée est le facteur décisif. Si la machine n’a qu’un réseau et qu’un tunnel, le service empaqueté est honnête et prévisible. Si le tunnel doit suivre un Wi-Fi précis, le secondaire est le seul des trois à exprimer cette condition sans script supplémentaire.

Choisissez un propriétaire et retirez les autres

Un profil démarré par deux propriétaires produit un timing qui change d’un boot à l’autre, ce qui est pire que l’un ou l’autre mécanisme seul. Choisissez le propriétaire, puis désactivez la voie concurrente exprès plutôt que par accident.

# who is configured to start something?
grep -v '^#' /etc/default/openvpn
systemctl list-units 'openvpn*'
nmcli -g connection.secondaries connection show 'Work Wi-Fi'

# NetworkManager: attach the tunnel to the base link by UUID
TUNNEL=$(nmcli -g UUID connection show 'Corp Tunnel')
nmcli connection modify 'Work Wi-Fi' +connection.secondaries "$TUNNEL"

Si c’est la voie empaquetée que l’on retire, faites-le dans le bon ordre : mettez AUTOSTART à none, lancez systemctl daemon-reload pour que les unités générées reprennent la nouvelle liste, puis désactivez l’instance modèle dont vous ne voulez plus. Sauter le rechargement laisse les anciennes unités actives, ce qui donne l’impression que le changement n’a eu aucun effet.

Un arrêt qui se bloque est un problème distinct à la réponse bornée. TimeoutStopSec plafonne le temps d’attente de systemd avant l’envoi de SIGKILL. Un fichier drop-in est le bon endroit pour le fixer, car modifier l’unité empaquetée fait perdre le changement à la prochaine mise à jour.

Vérifiez ce qui a réellement démarré

Redémarrez et lisez les preuves au lieu de faire confiance au fichier de configuration. L’unité propriétaire du tunnel affichera un état actif et un horodatage de démarrage cohérent avec le boot, et l’interface VPN existera avant que vous ne vous connectiez.

systemctl is-enabled openvpn-client@office
systemctl status openvpn-client@office --no-pager
nmcli -f GENERAL.STATE,connection.secondaries connection show 'Work Wi-Fi'
ip -brief link show tun0

Une vérification de plus a sa place ici : confirmez que le ExecStart de l’unité pointe bien vers le binaire que vous croyez. Un client compilé localement ou un paquet snap demande souvent un chemin explicite ou une enveloppe snap run, car systemd n’hérite pas de l’ordre de recherche de votre shell. Comparer command -v openvpn avec le fichier de l’unité règle cela en quelques secondes.

Écrivez le propriétaire choisi dans les notes de la machine, à côté du nom du profil. La prochaine personne qui diagnostiquera un tunnel manquant partira de cette ligne au lieu de refaire la comparaison.