OpenVPN ne démarre pas sans erreur ? Regardez le journal

La commande revient, le service apparaît en échec, et rien qui ressemble à une explication n’atteint le terminal. Ce silence est le symptôme que les gens décrivent comme « OpenVPN ne démarre pas », et il ne signifie presque jamais que le programme est mort sans rien dire. Il signifie que le message est allé vers un canal que vous ne lisiez pas, ou que ce que vous avez lancé n’était pas ce que vous avez configuré. Les deux cas se diagnostiquent en moins d’une minute dès que vous cessez de considérer le profil comme le suspect.

Quatre endroits absorbent la sortie : le journal de l’unité, le greffon qui possède la connexion, l’autre extrémité du tunnel et un binaire différent de celui que vous croyez en cours d’exécution. Chacun a sa propre vérification.

Le silence signifie que vous ne regardiez pas le bon canal

Une invocation au premier plan imprime dans votre terminal. Une unité imprime dans le journal, et une unité en échec peut sortir avant même d’écrire quoi que ce soit si la défaillance tient à la façon dont elle a été démarrée plutôt qu’à ce qu’on lui a dit. La distinction compte : aucune entrée de journal signifie que le processus n’a jamais vraiment tourné, tandis qu’une entrée suivie d’une sortie signifie qu’il a tourné et rejeté quelque chose.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Ajoutez systemctl show -p Result -p ExecMainStatus openvpn-client@office pour séparer une sortie propre d’un signal. Un statut de 1 avec un Result=exit-code est une décision du programme ; Result=signal ou un délai d’attente pointent plutôt vers l’environnement, et aucune quantité d’édition du profil n’y changera rien. Notez les deux valeurs avant de redémarrer quoi que ce soit, car un redémarrage efface l’état transitoire qui les a produites.

Le nom de l’instance fait partie du chemin

L’unité de modèle empaquetée ne prend pas un chemin de fichier. Elle prend un nom d’instance, et ce nom est ajouté à un répertoire pour trouver le profil : office se résout en /etc/openvpn/client/office.conf dans l’empaquetage Debian et Ubuntu. Un fichier nommé office-v2.conf démarré en tant que @office n’est jamais lu, et l’unité sort silencieusement car de son point de vue il n’y avait rien à faire. Le répertoire de recherche diffère entre le mode client et le mode serveur, donc la même erreur pointe ailleurs quand vous changez de modèle.

Cet écart est la cause la plus courante de la défaillance silencieuse, et il est invisible dans le profil parce que le profil est correct. Listez ce qui existe réellement et comparez les deux noms caractère par caractère, y compris toute extension attendue par l’empaquetage.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Si l’unité est activée mais qu’aucune instance n’est listée, l’activation elle-même peut référencer un nom qui a été renommé plus tard. Réactiver la bonne instance suffit généralement, et l’ancien fichier d’unité laissé sur place mérite d’être supprimé pour ne pas tromper la personne suivante. Un fichier d’unité oublié est une petite chose qui coûte une heure à quelqu’un plus tard.

Quand le greffon possède le tunnel, le terminal ne voit rien

Une connexion lancée depuis l’applet du bureau appartient à NetworkManager, et sa sortie OpenVPN va dans le journal de ce service plutôt que dans un shell que vous avez ouvert. Exécuter le client à la main et ne rien voir est attendu dans cette configuration, car le processus lancé à la main n’est pas celui qui porte la connexion.

Cherchez dans le journal le service qui le possède, puis reproduisez l’analyse avec une verbosité que vous pouvez lire. Les deux commandes ci-dessous regardent des propriétaires différents de la même défaillance.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

L’exécution autonome sert à lire des messages, non à remplacer la connexion gérée, et les deux diffèrent ensuite : l’intégration DNS, les routes et la durée de vie appartiennent au greffon. Corriger une erreur d’analyse dans l’exécution autonome ne corrige pas automatiquement la résolution de noms une fois que l’applet prend le relais, donc gardez les deux observations séparées.

Deux binaires, un PATH

Une compilation manuelle installée sous /usr/local gagne lors d’un appel depuis un shell, car /usr/local/sbin précède /usr/sbin dans le PATH par défaut d’Ubuntu. Une unité n’utilise pas votre PATH ; elle exécute le chemin absolu inscrit dans ExecStart. La version qui fonctionne dans votre terminal et celle qui échoue comme service peuvent donc être réellement des programmes différents.

Comparez les deux avant de reconstruire quoi que ce soit. La troisième commande est celle qui tranche.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Une autre différence d’environnement se cache au même endroit. Une unité empaquetée s’appuie sur un répertoire d’exécution sous /run que systemd crée pour elle ; une unité de remplacement écrite à la main qui omet ce réglage peut échouer avant d’ouvrir le moindre fichier, et l’échec ressemble à un refus générique sans aucun message OpenVPN.

Les défaillances que le client ne peut pas signaler

Certains résultats se décident à l’autre bout. Une passerelle qui répond avec un statut HTTP et ferme la connexion vous a informé de son propre état, et la prochaine étape utile est son journal ou le compte derrière l’identifiant, pas vos fichiers locaux. Rien de local n’est cassé dans ce scénario, et éditer le profil pour compenser rend le diagnostic suivant plus difficile. Lisez ce journal avant de toucher à la configuration du client.

Un autre cas silencieux est un client qui fonctionne correctement. Un tunnel en mode client n’écoute jamais sur un port, donc une vérification qui attend un écouteur ouvert ne signalera rien et ressemblera à une défaillance. Confirmez quel mode vous avez démarré avant de tirer une conclusion d’une liste de ports vide.

Travaillez les couches dans l’ordre : l’unité existe-t-elle et le nom d’instance est-il correct, quelque chose a-t-il atteint le journal ou le fichier --log, quel binaire et quel profil ont réellement tourné, et la défaillance est-elle locale ou distante. Chaque réponse retire une couche. Partir du profil revient à réécrire un fichier qui n’a peut-être jamais été ouvert.