OpenVPN affiche active (exited) ? Trouvez l’instance que vous avez démarrée

Vous vérifiez le tunnel, lancez systemctl status openvpn et obtenez active (exited) sans Main PID et avec une liste de processus vide. La lecture naturelle est que le service a démarré puis est mort, donc vous ouvrez l’unité, trouvez /bin/true et concluez que le paquet est cassé. Dans l’empaquetage Debian, cet état est le wrapper qui fonctionne comme prévu, et le tunnel vit dans l’une des unités d’instance qu’il démarre. L’unité agrégée ne vous dira jamais quelle instance l’a construite.

Ce que active (exited) signifie vraiment sur cette unité

L’unité empaquetée est ponctuelle : son ExecStart est /bin/true, et RemainAfterExit=yes est ce qui maintient une unité terminée signalée comme active (exited). Retirez cette directive et la même tâche /bin/true réussie se termine en inactive (dead), exactement l’état que les gens attendent et lisent mal dans l’autre sens. La commande est un espace réservé, et l’unité rend compte d’un travail que d’autres unités effectuent. Rien dans cet agencement n’est cassé, et remplacer /bin/true change le contrat d’empaquetage plutôt que le tunnel.

Le wrapper délègue. Il démarre les unités d’instance fournies par la configuration du paquet ou par son générateur systemd, c’est pourquoi une liste de processus vide ne prouve rien sur le tunnel. Quand aucune instance n’est sélectionnée, le wrapper réussit quand même et ne démarre toujours rien. L’état répond à la question de savoir si le wrapper a tourné, pas s’il existe un tunnel.

Lisez les trois lignes de la sortie status plutôt que le mot entre parenthèses. Loaded nomme le fichier d’unité que systemd a lu, Active porte l’horodatage de la dernière exécution réussie, et l’absence de Main PID correspond à une tâche ponctuelle terminée. Ces trois lignes sont aussi comment distinguer ce wrapper d’un service tombé une seconde après son démarrage.

Listez les unités avant de relire le status

Demandez à systemd ce qui existe avant de demander ce qui tourne. Un modèle peut être installé sans qu’aucune instance ne soit créée, et seule une unité créée porte un tunnel. Commencez par l’ensemble chargé :

systemctl list-units 'openvpn*'

Cette liste est ce que systemd a chargé en ce moment, et c’est ce qui ressemble le plus à un inventaire de tunnels. Les fichiers d’unité installés répondent à une autre question, et cette liste montre encore un modèle quand rien n’est créé :

systemctl list-unit-files 'openvpn*'

Lisez les deux listes ensemble, car un modèle dans la seconde et une instance dans la première sont des réponses différentes. Un modèle qui existe et une instance qui tourne ne sont pas le même fait, et seule la seconde signifie un tunnel. Les dispositions de paquet varient aussi entre distributions et versions d’OpenVPN. Un modèle openvpn@ plus ancien, une paire client et server séparée et un wrapper de distribution peuvent tous être légitimes dans leur propre empaquetage.

Adaptez-vous à votre machine plutôt qu’au tutoriel que vous avez trouvé. Le nom d’instance dans la sortie de quelqu’un d’autre peut être office alors que le vôtre est home ou work. Ce qui se transmet est la méthode, pas la chaîne.

Suivez le nom d’instance jusqu’au fichier qu’elle lit

Dans le modèle client amont, le répertoire de travail de l’unité est /etc/openvpn/client et sa commande y prend %i.conf, donc openvpn-client@office lit /etc/openvpn/client/office.conf. Confirmez cette correspondance sur l’unité installée au lieu de faire confiance à l’exemple, car le modèle que vous avez peut être plus ancien ou une réécriture de la distribution :

systemctl cat [email protected]

Lisez les drop-in qui apparaissent en bas de cette sortie, car un fichier sous .d/ peut changer ExecStart, le répertoire de travail ou le chemin de configuration. Un profil téléchargé sous le nom office.ovpn n’est pas le fichier que l’instance ouvre. Cet écart est la raison habituelle pour laquelle une erreur nomme un chemin que vous n’avez jamais modifié.

Les chemins relatifs dans le profil sont le piège suivant. Déplacer le fichier principal en laissant les références ca, cert et key relatives échange une erreur de fichier manquant contre une autre erreur de fichier manquant. La seconde pointe vers un fichier dont vous étiez sûr qu’il existait, et c’est pourquoi le répertoire du profil compte plus que le nom du fichier.

Démarrez-la, puis lisez le journal de cette instance

Démarrez l’instance que vous venez d’inspecter, car le journal de l’unité agrégée ne contiendra pas les erreurs du tunnel. Lisez ensuite le journal de ce démarrage et cherchez dans cet ordre une erreur de configuration, une erreur d’accès au fichier et une erreur de connexion, car chacune échoue à une étape différente du démarrage.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Démarrer et activer sont deux décisions distinctes : start exécute l’unité maintenant, enable prépare le prochain démarrage, et enable --now fait les deux en une étape. daemon-reload relit les définitions d’unité et ne redémarre pas un processus en cours et n’applique pas un profil modifié. Après avoir changé le profil, redémarrez l’instance, car c’est ce qui relit le fichier.

Ne mettez pas un second gestionnaire sur le même tunnel

NetworkManager et les gestionnaires de session OpenVPN 3 possèdent leur propre état de connexion, et une instance systemd à côté de l’un d’eux met deux propriétaires sur le même tunnel. Le symptôme est un tunnel qui monte et est remplacé quelques secondes plus tard, ou un qui refuse de rester arrêté. Choisissez le gestionnaire que votre distribution documente pour le bureau, et utilisez systemd délibérément sur un serveur.

Vérifiez s’il existe déjà un propriétaire avant de démarrer une instance. Quand une applet de bureau affiche la connexion, l’instance que vous démarrez la concurrence au lieu de la compléter. Désactivez le gestionnaire que vous n’utilisez pas au lieu d’exécuter les deux et d’espérer que l’ordre tienne. Ce conflit explique aussi des journaux où un tunnel est établi puis démonté par un processus que vous n’avez jamais démarré.

Répondez à la question d’origine avec le nom de l’instance, le fichier qu’elle a lu et la ligne de journal qui a échoué. Les notes d’OpenVPN sur l’intégration à systemd décrivent la disposition du modèle et la correspondance de fichier par laquelle le nom d’instance est résolu.