Le service OpenVPN échoue sur un profil que l’interface graphique ouvre : cinq vérifications

Deux lanceurs ouvrent le même profil sur une machine, et seul l’interface graphique se connecte. Le fichier est intact et l’installateur est probablement correct ; ce qui diffère, c’est le contexte que chaque lanceur donne à openvpn.exe. Le répertoire de travail, l’identité du compte et les attributs du fichier voyagent tous avec ce contexte. Vérifiez-les dans cet ordre et arrêtez-vous au premier qui explique l’erreur.

Confirmez quel lanceur échoue

Commencez par prouver la séparation. Si l’interface graphique se connecte et le service non, avec le même chemin de profil, le fichier est lisible par quelqu’un et la question devient qui le lit et depuis où. Si les deux échouent, le profil est cassé et rien de tout cela ne s’applique. Notez le nom du service et le profil exact qu’il devait charger.

Un service pointé vers son propre répertoire de démarrage automatique peut ne pas charger le fichier que vous avez ouvert dans un éditeur. Comparez le chemin de la configuration du service avec le chemin dans l’interface graphique, caractère par caractère, car un nom de dossier en fin de chemin ou une lettre de lecteur différente suffit à vous envoyer sur la mauvaise branche.

Où les chemins relatifs sont résolus

Un profil qui référence ca.crt ou un script auxiliaire par simple nom demande une recherche relative à l’endroit où se trouve le processus. L’interface graphique démarre dans le dossier de configuration, donc ces noms se résolvent. Un service démarré par le gestionnaire de services n’a pas un tel point de départ, et la recherche échoue avant qu’un certificat soit lu. C’est pourquoi le même profil fonctionne dans un lanceur et pas dans l’autre.

Donnez à l’enveloppe un répertoire de démarrage, ou rendez chaque référence absolue. Reproduire le contexte de l’interface graphique en ligne de commande ressemble à ceci :

openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"

Augmenter la verbosité de cette commande montre le chemin exact qui a été tenté. Faites-le avant de changer les permissions, car un fichier manquant et une lecture refusée demandent des corrections différentes. Le journal par défaut ne les distingue pas. Un indicateur supplémentaire épargne une heure de suppositions.

Quand l’identité du service ne peut pas lire

Un service s’exécute sous une identité système, pas sous la vôtre. Une ACL qui accorde le contrôle total à votre utilisateur et à personne d’autre échoue là-bas tout en fonctionnant parfaitement dans votre session. Un profil conservé sur un lecteur mappé ou sur un partage authentifié échoue pour la même raison. Confirmez les permissions du fichier avant de regarder quoi que ce soit d’autre.

La vérification est une lecture des permissions effectives plus une lecture tentée sous l’identité du service. Exécutez la première partie depuis une invite élevée :

icacls "C:\VPN\profiles\office\office.ovpn"

Tentez ensuite la même lecture sous l’identité du service, par exemple avec psexec -s -i de Sysinternals, et observez si le fichier s’ouvre. Si ce n’est pas le cas, aucune correction de chemin n’aidera. Corrigez l’ACL ou déplacez le profil vers un emplacement que l’identité du service peut lire.

Le chiffrement au niveau du fichier est le second cas, plus rare. Un profil marqué de l’attribut Encrypting File System est déchiffré de façon transparente pour l’utilisateur qui l’a chiffré et reste illisible pour un compte de service. C’est pourquoi le même fichier s’ouvre dans votre éditeur et pas sous le service.

L’attribut est visible depuis une invite élevée, et le vérifier n’ouvre pas le profil. Exécutez les deux commandes et lisez la sortie :

cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"

Effacer l’attribut rend le fichier lisible, et cela retire aussi la protection qu’il portait. Si le profil doit rester protégé, placez le matériel secret là où l’identité du service dispose d’une autorisation explicite au lieu de compter sur un chiffrement par utilisateur. Une telle disposition survit à un changement de mot de passe, et elle rend l’accès vérifiable par quelqu’un d’autre que la personne qui a chiffré le fichier.

Décider qui possède le tunnel

L’interface graphique peut demander un mot de passe et lire un certificat dans votre magasin utilisateur. Le service ne peut ni l’un ni l’autre, donc un profil qui dépend d’un secret interactif ne démarrera jamais sans surveillance, quels que soient les chemins corrigés. Cette limite est une décision de conception, pas un défaut à contourner. Choisissez un seul propriétaire avant de changer quoi que ce soit d’autre.

Si le tunnel doit être actif avant l’ouverture de session, donnez au service une source d’identifiants sans surveillance et sa propre copie du profil. S’il ne doit exister que pendant que vous êtes au bureau, gardez-le dans l’interface graphique et retirez la copie du service. Les deux à la fois, c’est la configuration qui produit des conflits d’adaptateur et des routes en double.

Ce conflit est généralement diagnostiqué comme une erreur de configuration plutôt que comme deux propriétaires se disputant un adaptateur. Le journal des événements montrera un processus qui n’arrive pas à ouvrir le périphérique TAP, ce qui ressemble à un problème de permissions et n’en est pas un. Comptez d’abord les propriétaires.

Ce que l’enveloppe du service lance réellement

Le point d’entrée du service est une petite enveloppe qui lit ses propres paramètres stockés puis lance openvpn.exe. Quand la ligne de commande du journal des événements ne correspond pas à votre attente, ce sont ces valeurs qu’il faut inspecter. Réinstaller les remet aux valeurs par défaut et détruit les preuves. Lisez-les d’abord.

Les valeurs vivent dans le registre sous la clé propre du service, et sc qc montre le chemin du binaire que le gestionnaire de services lancera. Comparez ce chemin avec la configuration stockée de l’enveloppe avant d’éditer l’un ou l’autre.

Remplacer l’enveloppe par un script que vous contrôlez est plus invasif, mais cela replie la ligne de commande effective dans un seul fichier lisible. Terminez par un redémarrage, puis lisez le journal par profil jusqu’à ce que la première ligne de démarrage réussie apparaisse. Un état de service « en cours d’exécution » signifie seulement que l’enveloppe n’est pas sortie, ce qui est aussi vrai quand son enfant est mort immédiatement.