Déconnectez un seul profil OpenVPN GUI, pas tous les tunnels

Un script de déconnexion échoue généralement pour une raison : il s’adresse au mauvais propriétaire. Un tunnel géré par l’interface OpenVPN de la communauté appartient à la session de cette interface, un tunnel lancé par un service Windows appartient au service, et OpenVPN Connect n’appartient à aucun des deux. Passez ces vérifications dans l’ordre et arrêtez-vous lorsque le propriétaire n’est pas clair. Envoyer une commande kill parce que le propriétaire était ambigu, c’est exactement ainsi qu’une déconnexion de profil se transforme en panne de tout le site.

Pour une connexion gérée par l’interface, la commande utile est un message à l’interface, et non un signal à openvpn.exe.

D’abord, identifiez le propriétaire

Regardez quel programme affiche réellement l’état connecté avant d’écrire quoi que ce soit. Une icône dans la zone de notification signifie que la session de l’interface le possède. Une entrée de service signifie que le service le possède. Une fenêtre d’application séparée avec sa propre liste de profils ne signifie ni l’un ni l’autre, et c’est sa propre interface, spécifique à la version, qui s’applique.

Vérifiez aussi le compte et la session de bureau. Une tâche planifiée qui s’exécute sous un autre utilisateur, ou dans une session non interactive, ne doit pas être supposée contrôler l’interface qu’une personne connectée voit. Ce décalage produit une commande qui se termine proprement et ne change rien, ce qui est le type de panne le plus coûteux à diagnostiquer à partir d’un journal.

Ensuite, envoyez la déconnexion propre au propriétaire

Avec l’interface installée au chemin de l’exemple et un profil nommé office, la commande complète tient sur une ligne :

"C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --command disconnect office

Remplacez-la par votre chemin d’installation réel et le nom exact de la configuration, y compris la casse telle que l’interface l’affiche. La documentation des commandes du projet liste les contrôles d’interface pris en charge, et cet exemple n’appartient qu’à OpenVPN GUI — ce n’est pas une commande pour toute application portant OpenVPN dans son nom.

Pour un tunnel possédé par un service, le bon contrôle est le service, pas le binaire de l’interface. Inspectez le service installé et les profils qu’il gère avant d’arrêter quoi que ce soit, car un arrêt peut faire tomber plusieurs tunnels à la fois et vous n’obtiendrez pas de résultat par profil.

Vérifiez que rien d’autre ne tombe

L’interface documente aussi une commande disconnect_all, et sa portée est précisément la raison pour laquelle c’est le mauvais outil pour un script censé n’arrêter que office. Si la simplicité vous tente, demandez-vous ce qui d’autre est connecté sur cette machine et comment l’utilisateur s’en apercevra.

taskkill /F /IM openvpn.exe est pire à deux égards. Il sélectionne les processus par nom d’exécutable et impose la terminaison, donc il n’exprime ni un nom de profil ni la séquence de déconnexion normale du propriétaire. Appeler cela un arrêt propre cache les deux problèmes derrière un seul code de sortie.

Quelle que soit la voie choisie, vérifiez l’ampleur de l’impact avant le changement : listez les profils connectés, notez ceux qui doivent survivre et vérifiez-les à nouveau ensuite.

Confirmez l’état, pas le code de sortie

Après avoir demandé la déconnexion, lisez l’état de la connexion nommée via son propriétaire plutôt que de vous fier à la valeur de retour de la commande. Si l’étape suivante a besoin du réseau après le démontage, attendez ce changement d’état avec un délai d’expiration explicite au lieu de supposer que le nettoyage est terminé au retour du processus. Un script qui court après le démontage échouera par intermittence et le VPN en sera blâmé.

Si l’état ne change jamais, le propriétaire n’est probablement pas celui auquel vous vous êtes adressé. Revérifiez la session et le compte avant de passer à une commande plus forte.

Ce qu’il faut mettre dans le journal

Consignez le nom du profil, le propriétaire auquel vous vous êtes adressé et le contexte de lancement, ainsi que l’état obtenu. Ne déversez pas la configuration complète ni les identifiants dans le journal de la tâche, et ne consignez pas la ligne de commande si elle contient un chemin vers un fichier contenant des secrets.

Un message d’erreur qui nomme le profil et le contexte suffit pour que la personne suivante reproduise le problème. Un journal qui ne note qu’un code de sortie générique les renvoie au début, et c’est précisément là que les suppositions recommencent.