Moteur OpenVPN ou Tunnelblick : qui possède la session VPN du Mac ?

Homebrew installe un programme OpenVPN ; Tunnelblick installe un gestionnaire qui exécute un ou plusieurs moteurs. Ce sont des couches différentes, et la question utile n’est pas de savoir si vous aimez utiliser un terminal. C’est de savoir qui possède la configuration, les changements de DNS, la demande d’identifiants et le nettoyage à la fin de la session. Un seul propriétaire pour ces couches, voilà ce qui rend l’installation prévisible.

Passez les cinq vérifications ci-dessous dans l’ordre. La première qui a deux propriétaires est celle qui produit les étranges états à demi connectés que les gens attribuent à OpenVPN lui-même. Chaque vérification nomme la preuve qui la tranche.

Vérification une : quel binaire OpenVPN s’exécute réellement

Exécutez pgrep -fl openvpn pendant que vous êtes connecté et lisez la ligne de commande complète. Le premier chemin est le moteur qui tourne réellement. Sur Apple Silicon, une installation Homebrew vit généralement sous /opt/homebrew, tandis que les Mac Intel utilisent /usr/local, et Tunnelblick exécute un moteur depuis son propre paquet d’application.

Tunnelblick embarque des moteurs et laisse une configuration en choisir un. Mettre à jour la formule Homebrew change le binaire autonome, pas le moteur que lance un profil Tunnelblick. Si vous comparez des versions pour expliquer une différence de comportement, comparez le moteur de la liste des processus plutôt que celui du gestionnaire de paquets. La chaîne de version seule ne vous dira pas quel profil ce moteur a chargé.

Un profil copié peut aussi faire paraître deux moteurs identiques alors qu’ils lisent des fichiers différents. Le chemin du profil dans la ligne de commande vous dit quelle configuration le processus en cours a chargée ; un profil ouvert dans un éditeur n’est pas une preuve. Comparez ce chemin avant de comparer les comportements.

Vérification deux : qui modifie le DNS et les routes

Le moteur peut exécuter les directives up et down propres à OpenVPN, mais le gestionnaire peut posséder le même cycle de vie. Les réglages de serveur de noms de Tunnelblick contrôlent ses scripts standard de connexion et de déconnexion, et lorsque cette intégration est activée, les directives concurrentes du profil peuvent être ignorées.

Cela compte parce que le DNS est l’endroit où un tunnel qui fonctionne paraît le plus souvent cassé. Vérifiez scutil --dns pendant que vous êtes connecté, notez quel résolveur vient en premier et confirmez qu’il revient après la déconnexion. Si le profil compte définir le DNS lui-même alors que le gestionnaire le gère aussi, l’un des deux perdra.

Décidez quelle couche possède le DNS avant la première connexion, puis retirez la directive perdante au lieu de laisser les deux en place. Les changements de route suivent la même règle : un propriétaire, visible dans la configuration, avec un chemin de restauration documenté.

Vérification trois : d’où viennent les identifiants

Une invite interactive et un processus sans surveillance ont des exigences différentes. Un identifiant enregistré par une application n’est pas automatiquement disponible pour un autre processus, et un élément de trousseau limité au gestionnaire peut être invisible pour un moteur autonome lancé depuis un shell.

Énumérez la source des identifiants du profil : un certificat et une clé de client, une invite de nom d’utilisateur et de mot de passe, ou un jeton fourni par un assistant externe. Confirmez ensuite que le propriétaire choisi peut atteindre cette source sans personne si la connexion doit survivre à un redémarrage.

Vérification quatre : qui démarre, surveille et arrête le processus

Un déploiement autonome a besoin d’un superviseur s’il doit rester actif. Launchd peut démarrer le moteur à l’ouverture de session ou à la demande, le redémarrer après un plantage et l’arrêter proprement, mais quelqu’un doit écrire et posséder cette tâche. Exécuter la commande dans un terminal fonctionne pour un test et pas pour un utilisateur qui ferme la fenêtre.

Si Tunnelblick reste le propriétaire, utilisez ses contrôles pris en charge au lieu de démarrer un second moteur. Le binaire Homebrew, muni d’un profil copié, ouvre une connexion indépendante avec sa propre configuration et son propre contexte d’intégration au lieu de commander la session Tunnelblick existante.

Quel que soit le propriétaire choisi, définissez ce qui se passe en veille, lors d’un changement de réseau et à la déconnexion. Un gestionnaire traite normalement ces événements ; un processus nu ne le fait généralement pas, et la route ou le résolveur obsolète qui en résulte se lit facilement comme une panne du serveur.

Vérification cinq : comment le transfert est vérifié

Testez le nouveau propriétaire avec l’ancien désactivé, puis testez à nouveau l’ancien si vous comptez le garder. Une ressource privée qui répond dans un flux de travail et pas dans l’autre est une preuve de l’intégration manquante, pas du serveur.

Pour un transfert vers un moteur autonome, notez le chemin du profil, le chemin du binaire, le superviseur, le propriétaire du DNS et la source des identifiants. Vérifiez ensuite la ressource privée, le chemin vers l’internet public et une déconnexion propre dans cet ordre. Si le DNS ou les routes subsistent après la déconnexion, le nouveau propriétaire n’a pas terminé.

Pour un transfert vers Tunnelblick, sélectionnez le moteur de la configuration, activez l’intégration DNS voulue et retirez les directives du profil qui s’y opposent. Répétez ensuite les mêmes trois vérifications. Une connexion qui fonctionne mais laisse le résolveur modifié est un transfert raté, même si le tunnel s’est levé.

L’empaquetage ne tranche pas la compatibilité avec le serveur. Vérifiez les exigences propres au client du service et ne choisissez le moteur seul que si vous comptez fournir sa gestion.