Quelle instance OpenVPN utilise réellement ton profil PiVPN ?

PiVPN écrit une configuration serveur et un profil client, puis s’arrête ; il ne devient jamais le processus qui transporte ton trafic. Un handshake raté, un client qui compose le mauvais point de terminaison ou un service qui revient de travers après un redémarrage ne s’expliquent donc pas depuis les menus de l’installateur. Ces symptômes appartiennent au démon OpenVPN qui tourne maintenant, à la configuration que ce démon a réellement chargée et au journal vers lequel il a été pointé. Quatre commandes en lecture seule suffisent généralement, et aucune ne touche à tes certificats ni à tes clés.

L’assistant et le démon sont des objets différents

La confusion s’explique facilement : un dossier contient le fichier généré par l’assistant, le fichier que lit le démon et parfois une copie périmée des deux. Un assistant est un script de provisioning. Il installe des paquets, écrit des fichiers d’unité et imprime un profil client, puis son travail s’arrête. Ce qui reste, c’est une entrée dans le gestionnaire de services et une ligne de commande.

Sur un hôte systemd, pars de l’unité active plutôt que de la liste du dossier. Le nom dépend du paquetage : les images Debian et Raspberry Pi OS exposent souvent une instance de modèle comme openvpn-server@server, tandis que les installations plus anciennes utilisent openvpn@server. Demande au gestionnaire laquelle tourne au lieu de deviner d’après un nom de fichier.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Lis ExecStart= dans cette sortie. Elle nomme l’exécutable et les options que le gestionnaire lance réellement, y compris tout --config chemin ; un fichier de configuration voisin qu’aucune commande ne référence ne fait pas partie du tunnel en cours.

Suis la chaîne de configuration que le démon a résolue

OpenVPN ne scanne pas un dossier à la recherche de réglages. Il lit le fichier passé avec --config, suit toute config directive qu’il contient, puis applique les options de la ligne de commande. Le manuel 2.6 décrit cet ordre, et cela compte quand deux fichiers ne s’accordent pas sur le port, le périphérique ou le chiffrement.

Vide d’abord l’invocation effective, puis regarde les directives qui décident de l’identité et de l’accessibilité. Les deux commandes sont en lecture seule et sûres sur un serveur actif, même si la seconde imprime des chemins que tu ne veux peut-être pas dans un ticket public.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Un fichier .ovpn dans un répertoire personnel est un artefact client. Le démon serveur ne le lit jamais, donc modifier ce fichier pour corriger un échec de handshake côté serveur ne sert à rien.

Les inclusions sont l’autre piège. Une ligne config tire un second fichier dont les options sont traitées à cet endroit, si bien qu’une directive ultérieure à valeur unique peut supplanter ce que le fichier principal semble dire. Si le fichier visible paraît correct et que le démon se comporte toujours autrement, lis le fichier inclus avant de changer quoi que ce soit.

Fais correspondre le journal au processus, pas à l’erreur dont tu te souviens

Deux destinations de journal sont courantes, et une seule est le journal systemd. Avec log-append réglé, le démon écrit dans ce fichier et le journal ne garde guère plus que les lignes de démarrage. Sans cela, journalctl est la source des événements.

journalctl -u openvpn-server@server -n 80 --no-pager

Corrèle une tentative de connexion avec une fenêtre temporelle. Note le point de terminaison du client, puis lis les événements serveur des mêmes secondes. Un handshake TLS qui n’atteint jamais l’échange de certificats indique un problème d’accessibilité ou une inadéquation de protocole, tandis qu’un refus d’authentification arrive une fois les paramètres du tunnel déjà convenus.

Une vieille entrée de journal ne prouve rien sur un profil téléchargé il y a cinq minutes. Régénère le fichier client, reconnecte-toi une fois et ne lis que les lignes apparues pendant cette tentative.

Note la première panne précise plutôt que la dernière générique. Une erreur de bind, un échange externe sans réponse, un refus de certificat et un refus de compte t’envoient chacun vers une couche différente, et un délai d’expiration à la fin masque souvent l’événement utile au-dessus.

Reconstruire le tunnel n’est pas une étape de diagnostic

Le raccourci tentant est de monter un second tunnel plus simple : clé statique, pas de certificats, pas d’authentification supplémentaire. Il se connectera souvent, et il prouve seulement que deux hôtes peuvent faire passer UDP ou TCP entre eux. Il ne dit rien sur la raison de l’échec du déploiement authentifié par certificat, et il remplace discrètement le modèle de sécurité qu’on t’a demandé de garder.

La même chose vaut pour désactiver tls-auth ou tls-crypt, assouplir verify-x509-name, ou supprimer un second facteur pour obtenir un statut vert. Un tunnel qui se connecte parce que la vérification a été retirée est un autre système, pas un système réparé.

Fais un seul changement limité à la couche que le journal a nommée, redémarre la même unité et répète l’unique tentative de connexion. Cela garde la comparaison honnête et laisse un changement que tu peux annuler.

Ce qu’il faut transmettre à la personne suivante

Note quatre faits pendant que tu les as encore : la version d’OpenVPN issue de openvpn --version, l’unité active, la chaîne de configuration avec ses inclusions et la fenêtre de journal couvrant une tentative. Ces quatre éléments transforment une plainte vague en cas reproductible.

Expurge avant de partager. Les clés privées, auth-user-pass et autres fichiers, le matériel de clé statique et les paquets clients complets n’ont pas leur place dans un ticket ; les noms d’options et la forme de la chaîne suffisent en général à un second regard.

Si la chaîne est intacte et que le journal pointe encore vers le réseau, l’étape suivante est le chemin entre client et serveur plutôt qu’une autre installation. C’est la seule partie de l’histoire que l’assistant n’a jamais possédée.