OpenVPN ne démarre pas : lisez la première ligne, pas la configuration

Un VPN qui meurt à la première seconde est un animal différent de celui qui se connecte puis échoue, et l’erreur habituelle est de les traiter comme identiques. Il n’y a ici ni poignée de main, ni échange de certificats, ni route à examiner. Une ligne du journal décide laquelle de plusieurs réparations sans rapport s’applique, et la sauter coûte un après-midi à modifier une configuration qui n’a jamais été lue. Lisez cette ligne d’abord.

Trois commandes en lecture seule vous y mènent : d’abord journalctl -u openvpn@server -b --no-pager, ensuite systemctl status openvpn@server, et ss -lunp pour les écouteurs UDP et leurs propriétaires.

La première ligne choisit la branche

Un conflit de ports et un binaire absent tuent tous deux le démarrage en une seconde, et ils laissent des premières lignes différentes. Un message indiquant que l’adresse est déjà utilisée nomme le port ; un exécutable absent nomme un chemin qui n’existe plus ; une condition échouée ou un fichier de configuration absent nomme le fichier. Ces trois mènent à des réparations différentes, et aucune ne s’améliore en réinstallant le client. Copiez le premier échec dans vos notes avant d’exécuter quoi que ce soit d’autre.

Surveillez la boucle de réessai qui masque la ligne d’origine. Une unité avec une politique de redémarrage peut enterrer le premier échec sous une douzaine d’identiques, donc journalctl -b filtré par l’unité et lu depuis le haut bat la fin.

Qui d’autre tient le port 1194

Le coupable n’est généralement pas un second serveur que quelqu’un a configuré exprès. Attendez-vous à un client lancé à la main encore vivant dans un autre terminal, à un second profil qui a choisi le même port, ou à un paquet fournisseur dont le propre tunnel tient le 1194. Le propriétaire de la socket apparaît dans ss -lunp ; passez ce PID à systemctl status pour savoir si une unité est responsable. Abaissez-le par son propre chemin de contrôle plutôt qu’avec un signal.

Un signal à un processus géré par une unité déclenche généralement un redémarrage, et la même panne réapparaît quelques instants plus tard comme un problème neuf. Utilisez systemctl stop pour une unité, la commande de service du paquet lui-même pour une installation fournisseur, et un signal seulement pour ce que vous avez lancé à la main dans ce shell.

Unités restantes après une purge

Une purge supprime les binaires ; les fichiers d’unité écrits à la main, typiquement sous /etc/systemd/system, y survivent. Systemd réessaie alors une unité qui pointe vers un chemin qui n’existe plus, et le message concerne ce fichier manquant plutôt que la suppression d’hier. systemctl status affiche le chemin de fragment de l’unité près du haut, vérifiez-le donc avec dpkg -S avant de supprimer quoi que ce soit. Une fois l’orphelin parti, systemctl daemon-reload et systemctl reset-failed nettoient l’état ; sinon chaque vérification d’état ultérieure en hérite.

Quand which openvpn répond par quelque chose sous /usr/local, le binaire en jeu vient d’un installeur fournisseur et non d’apt. Un tel installeur apporte généralement son propre écouteur, sa propre entrée de démarrage et son propre répertoire de configuration, donc supprimer la commande visible laisse la socket occupée.

Désinstallez-le comme le documente le fournisseur, confirmez que le port est libre avec ss -lunp, et ajoutez le client de la distribution seulement si vous en avez besoin.

Remettez l’état d’aplomb avant de réessayer

Nettoyez l’état d’échec avant d’en tirer des conclusions : systemctl reset-failed supprime les compteurs, et systemctl status rapporte alors l’état actuel de l’unité plutôt que son historique. Démarrez-la une fois et lisez le journal de cette exécution plutôt que l’état agrégé de la machine. Une unité qui se déclare active alors que le tunnel ne transporte rien est un problème distinct, et bien plus courant. Les deux se confondent dans les rapports de bogues parce que tous deux finissent par l’utilisateur disant que le VPN ne fonctionne pas.

Notez la branche que vous avez prise : conflit de ports, binaire absent, configuration absente. La prochaine fois, la reconnaissance sera plus rapide.