Pourquoi OpenVPN démarre-t-il à l'ouverture de session et non au démarrage de Windows ?

Les tunnels qui n'apparaissent qu'après l'ouverture de session d'une personne sont généralement lancés par la session de cette personne, et non par le service automatique. Le coupable habituel est un raccourci de démarrage qui lance openvpn-gui.exe, et il ne s'agit pas d'une installation cassée. Le raccourci lance une application de bureau à l'intérieur d'une session utilisateur, avec le profil de cet utilisateur, ses magasins de certificats et sa capacité à répondre à une invite. Rien de tout cela ne rend la connexion indépendante d'un humain connecté, et c'est précisément ce qu'exige un tunnel avant ouverture de session.

Le symptôme a généralement trois causes

Trois schémas se ressemblent de l'extérieur et ont des correctifs différents. Le premier est un propriétaire d'exécution qui est une session utilisateur plutôt que le service, ce qui est le cas du raccourci de démarrage. Le second est un profil qui se trouve là où le service ne regarde pas, si bien que le service démarre, ne trouve rien et se termine proprement. Le troisième est un profil que le service trouve et démarre, mais dont les identifiants exigent une interaction qu'aucun service ne peut fournir.

Déterminer lequel s'applique demande deux lectures : ce que le service est configuré pour exécuter, et quels fichiers il peut voir. Les deux tiennent en une commande chacune, et aucune ne perturbe une connexion active.

Ce que le service automatique lit réellement

Le service automatique de Community est un enrobage qui parcourt son répertoire de démarrage automatique configuré, normalement config-auto sous l'installation, et lance un processus OpenVPN pour chaque profil correspondant qu'il trouve. Un profil visible dans le menu GUI d'un utilisateur réside plutôt sous le profil itinérant de cet utilisateur, dans un répertoire que le compte de service ne lit pas. Le guide du service Windows décrit cette découverte, et il vaut la peine de le lire avant de copier quoi que ce soit, car le répertoire cible est une propriété de l'installation et non une convention fixe. Copier un fichier dans le dossier du GUI ne change donc rien pour le service, et le copier dans chaque dossier nommé config crée des doublons plutôt qu'un correctif.

Get-Service OpenVPNService | Select-Object Status, StartType
Get-CimInstance Win32_Service | Where-Object Name -eq 'OpenVPNService' | Select-Object PathName, StartName
gci 'C:\Program Files\OpenVPN\config-auto'

La dernière commande liste ce que l'enrobage verra réellement, ce qui est le moyen le plus rapide de confirmer qu'un profil est au mauvais endroit. La deuxième ligne montre aussi le compte sous lequel le service s'exécute, et ce compte décide quels chemins de fichiers et magasins de certificats sont accessibles.

Pourquoi une ouverture de session de bureau fonctionne et un démarrage non

Un succès sur le bureau peut longtemps masquer une dépendance à une saisie. Un GUI peut recueillir une phrase secrète de clé, un mot de passe de compte ou un second facteur dans une boîte de dialogue, parce qu'il s'exécute dans une session interactive avec un bureau visible. Un service s'exécute dans une session sans bureau, une demande de saisie n'a donc nulle part où apparaître, et la connexion échoue après un délai d'attente qui ne ressemble en rien à un problème d'identifiants.

L'accès aux fichiers suit la même règle. Une clé privée stockée sous le profil de l'utilisateur, ou un certificat dans le magasin personnel de l'utilisateur, n'est pas disponible pour un service qui s'exécute en tant que la machine. Comparez les chemins absolus, les autorisations et le choix de certificat de chaque côté au lieu de supposer que le même fichier de profil implique le même environnement.

Une tâche planifiée configurée pour s'exécuter qu'un utilisateur soit connecté ou non hérite d'une contrainte similaire. Elle peut démarrer l'exécutable du GUI avec succès et produire malgré tout un processus qui n'obtient jamais d'identifiants, si bien que la présence d'un processus dans le gestionnaire des tâches n'est pas la preuve d'un tunnel fonctionnel.

Choisissez un seul propriétaire et testez le cycle de vie réel

Pour une connexion qui appartient à une personne connectée, utilisez le démarrage automatique pris en charge du GUI et laissez le service en dehors. Pour un tunnel qui doit exister avant que quiconque se connecte, configurez le service, placez le profil là où l'enrobage le lit, et utilisez un mécanisme d'identifiants non assisté pris en charge, comme une clé sans phrase secrète interactive ou un fichier d'identifiants documenté.

Get-Content 'C:\Program Files\OpenVPN\log\openvpn.log' -Tail 40
Get-WinEvent -LogName Application -MaxEvents 20 | Where-Object ProviderName -like '*OpenVPN*'

Testez le cycle de vie qui compte : un redémarrage sans que personne ne se connecte, puis une reconnexion après un changement de réseau. Gardez un seul propriétaire pour la connexion, car deux mécanismes de démarrage concurrents produisent généralement deux instances qui se disputent les mêmes routes et la même session serveur, ce qui est plus difficile à diagnostiquer que l'un ou l'autre mécanisme seul.