Quel binaire openvpn s’exécute ? Vérifiez le chemin de lancement

Un ancien contournement a déplacé l’exécutable d’OpenVPN ailleurs et laissé une enveloppe shell à l’emplacement d’origine. Des mois plus tard, une mise à jour arrive, et l’annulation du contournement devient un jeu de devinettes sur le fichier qui est réellement le client. Le nom de la commande, l’exécutable configuré dans le service et l’inventaire de fichiers du paquet peuvent tous désigner des objets différents, et réparer l’un sans les autres produit un hôte qui semble réparé et se comporte plus mal.

Commencez par le chemin que lance le service

Un terminal et une unité systemd ne résolvent pas les exécutables de la même manière. Le shell parcourt un PATH ; l’unité nomme un chemin, et les surcharges drop-in peuvent le remplacer sans toucher au fichier que vous lisez. Cette différence explique l’essentiel de la confusion dans cette tâche. Elle détermine aussi quel fichier votre réparation doit cibler.

Demandez à l’unité ce qu’elle exécute, y compris les surcharges drop-in qui la modifient, et lisez la ligne ExecStart obtenue plutôt que le fragment que vous supposez faire autorité. Suivez ensuite ce chemin à travers tout lien symbolique jusqu’au fichier final. Une enveloppe qui se termine par exec vers un répertoire caché est un montage courant de ces anciens correctifs.

Notez le chemin résolu avant de modifier quoi que ce soit.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Comparez le nom de la commande et le chemin du service

Les deux réponses diffèrent souvent, et cette différence n’est pas automatiquement un défaut. Un greffon NetworkManager peut lancer son propre chemin, et un conteneur peut en monter un autre.

L’important est de savoir quel propriétaire lance le processus qui sert le trafic. Si l’unité exécute /usr/local/sbin/openvpn-wrapper alors que votre shell résout /usr/sbin/openvpn, réparer le second fichier ne change rien au service.

Demandez quel paquet possède chaque candidat, puis décidez si le fichier est géré par le paquet ou placé localement. Un fichier sans paquet propriétaire est un fichier que quelqu’un a mis là volontairement, et il mérite un nom, un propriétaire et une raison avant d’être supprimé. L’erreur inverse est aussi courante : écraser un fichier de paquet avec un ancien binaire sauvegardé parce qu’un message de forum utilisait le même répertoire.

Laissez la base de données des paquets parler des fichiers de paquet

Quand le logiciel provient d’un paquet Debian, la base de données des paquets peut vous dire si ses fichiers correspondent encore à ce qui a été installé. C’est une question étroite d’intégrité, pas un verdict de sécurité, et la différence compte quand vous décidez quoi réparer. Une divergence signifie que le fichier a changé après l’installation, ce qui peut être votre ancien contournement ou une modification locale légitime. La sortie ne tranche pas, alors lisez-la comme un indice et non comme une conclusion.

Lancez la vérification et lisez la sortie au lieu de traiter un résultat vide comme une preuve de quoi que ce soit.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

Le manuel de dpkg documente que la vérification compare les fichiers installés aux métadonnées enregistrées localement, en utilisant les sommes de contrôle stockées lorsqu’elles existent. Elle remarque un fichier de paquet modifié, et elle ne peut pas vous dire si un autre binaire est lancé à la place.

Enregistrez l’état avant de réparer

Rassemblez le chemin de lancement résolu, la relation du fichier au paquet, l’emplacement de l’enveloppe et l’enregistrement de changement qui l’a introduite. Copiez l’enveloppe dans un endroit protégé si elle contient un travail d’intégration qui sera nécessaire plus tard.

Ne collez pas le contenu de l’enveloppe dans un fil de support avant de l’avoir lu, car ces scripts portent parfois des identifiants ou des détails de passerelle.

Notez quels profils le service utilise et qui est connecté pendant que vous travaillez, car redémarrer le tunnel peut interrompre la session avec laquelle vous administrez l’hôte.

Validez le lancement, puis retirez l’enveloppe

Après la réparation, démarrez le service et confirmez que le processus exécute le chemin voulu. Une requête de version faite à la main prouve que le fichier fonctionne ; elle ne prouve pas que l’unité l’utilise.

Reconnectez ensuite un client et vérifiez que le profil s’authentifie toujours, car un remplacement de binaire qui ignore les options d’origine échouera d’une manière qui ressemble à un problème de certificat.

Retirez l’enveloppe déplacée via le même enregistrement de changement qui l’a introduite. La réparation terminée indique quel exécutable s’exécute, pourquoi et quel fichier a été supprimé ; restaurer un nom de fichier et espérer n’est pas la même chose.