OpenVPN démarré mais rien imprimé : vérifiez d'abord log-append

Vous lancez OpenVPN depuis un shell avec un fichier de configuration, et le terminal reste là sans aucune sortie. Pas de bannière, pas d'erreur, pas d'invite. L'instinct dit que le lancement a échoué, alors vous lancez une autre copie, puis une autre, et la machine finit avec plusieurs instances à moitié configurées. Avant tout cela, vérifiez dans le profil une directive qui a déjà redirigé le journal ailleurs. Le silence est une propriété de la console, pas du processus.

Le silence a deux explications très différentes

La première est que le processus tourne bien et écrit dans un fichier que vous ne surveillez pas. La seconde est qu'il s'est arrêté immédiatement avec une erreur consignée dans ce même fichier.

Les deux laissent un terminal vide, et une seule question les sépare : y a-t-il un processus maintenant, et que contient le fichier auquel il devait écrire. Répondez-y avant de retoucher la configuration. Relancer pour obtenir une sortie est la façon dont deux instances finissent par se disputer un même périphérique de tunnel et le même port, ce qui produit des erreurs sans aucun rapport avec le problème d'origine.

Trouvez la directive, puis trouvez le processus.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Trouvez la destination qu'utilise le processus en cours

Lisez le profil avec lequel le processus a réellement été lancé, pas celui que vous avez modifié. Une instance gérée par un service charge généralement un autre chemin et s'exécute avec un autre répertoire de travail, si bien qu'un nom de fichier relatif se résout ailleurs que prévu.

Une directive cd explicite rend cette distinction plus nette, car le chemin relatif se déplace avec le changement de répertoire. Si vous avez hérité de cette configuration, le fichier peut se trouver là où personne ne le chercherait aujourd'hui.

Comparez l'heure de modification du fichier au moment où vous l'avez lancé. Un journal de la semaine dernière est une preuve concernant la semaine dernière. Lisez ensuite les dernières lignes du fichier qui a changé, et considérez ce qui s'y trouve comme le message de démarrage qui vous manquait.

log contre log-append : preuve et effacement

log-append ajoute à ce qui est déjà dans le fichier. log ouvre le fichier en écriture et le tronque, si bien que passer de l'un à l'autre peut effacer l'exécution que vous alliez lire.

Si quelqu'un a modifié la directive pendant le débogage, la preuve précédente a déjà disparu et la taille du fichier semblera suspectement petite. Cela vaut la peine de le savoir avant de comparer deux exécutions et de conclure que quelque chose a changé. Supprimez un journal exprès ou conservez-le, mais sachez lequel vous avez fait. Une preuve que vous avez retirée délibérément est plus facile à interpréter qu'une preuve perdue par accident.

Aucune des deux options ne crée les répertoires parents manquants, et aucune ne donne accès via les permissions du système de fichiers ou une sandbox de service. Un chemin qui semble correct dans la configuration peut rester non inscriptible par le compte sous lequel tourne le démon, et dans ce cas le démon peut échouer avant de pouvoir signaler quoi que ce soit. Vérifiez l'existence du répertoire et son propriétaire avant de supposer que le nom du fichier est le problème.

Quand un wrapper de service capture la sortie

Sous systemd, la sortie standard et les erreurs vont au journal sauf si une directive de fichier explicite a la priorité, et un wrapper du fournisseur peut les capturer complètement ailleurs.

C'est pourquoi le même profil se comporte différemment depuis un shell et depuis une unité. L'environnement de l'unité, son répertoire de travail et ses flux standard diffèrent tous de votre shell interactif. Un chemin relatif peut se résoudre dans un contexte et n'aboutir nulle part dans l'autre. Lisez la définition de l'unité quand les deux sont en désaccord, pas le profil.

Comparez les deux dispositions de lancement au lieu de conclure que l'une des deux est cassée. Lisez la ligne de commande de l'unité et son environnement, puis lisez le journal pour la même fenêtre temporelle. Si le wrapper redirige la sortie vers son propre fichier, ce fichier est désormais votre journal, et les directives OpenVPN n'ont aucune importance quant à l'endroit où les messages sont allés.

N'augmentez la verbosité qu'une fois que vous pouvez la lire

Augmenter la verbosité avant d'avoir trouvé la destination ne produit que plus de texte à un endroit que vous ne regardez pas.

Une fois que vous savez où atterrit la sortie, un niveau modéré montre que le profil est analysé et que la connexion est tentée. Deux ou trois suffisent pour un problème de démarrage. Les niveaux supérieurs méritent leur place quand la défaillance est un détail de négociation, et ils font aussi grossir le fichier rapidement.

Lisez ensuite l'erreur réelle. Un terminal silencieux ne prouve rien quant à la montée du tunnel, et la défaillance consignée dans le fichier est celle qui vaut la peine d'être corrigée.