Piloter un profil Tunnelblick nommé depuis le terminal

Les scripts qui ont besoin du VPN actif avant une sauvegarde lancent souvent openvpn directement. Cela abandonne le profil, le DNS et la gestion des routes que Tunnelblick gère déjà. La voie prise en charge est l’interface AppleScript propre à Tunnelblick, qui accepte les demandes connect, state et disconnect pour une configuration nommée. Utilisez-la et laissez l’application aux commandes.

Parlez à l’application, pas à openvpn

Tunnelblick possède le profil OpenVPN, le choix du moteur, les scripts ainsi que l’intégration DNS et des routes. Un binaire openvpn séparé est un autre mode de lancement, pas un raccourci vers la même connexion.

Appeler l’interface de script de l’application préserve cette propriété et rend chaque demande vérifiable.

Les exemples ici supposent que Tunnelblick se trouve dans Applications, qu’une configuration fonctionnelle s’appelle HQ et que les commandes s’exécutent dans la session de l’utilisateur Mac connecté. Remplacez le nom par la configuration exacte que vous avez.

Démarrez exactement un profil nommé

Une demande connect nomme la configuration. Ce n’est pas une demande de connexion à ce qui a été sélectionné en dernier.

Exécutez-la dans la session utilisateur qui possède la configuration :

osascript -e 'tell application "/Applications/Tunnelblick.app" to connect "HQ"'

Passez les invites de connexion habituelles. macOS peut demander si l’application appelante est autorisée à contrôler Tunnelblick ; vérifiez quelle application et quelle cible avant d’approuver. Une automatisation qui clique à travers cette boîte de dialogue en annule l’intérêt.

Une demande connect revient avant que le tunnel soit monté

Le guide de script de Tunnelblick est explicite : connect revient avant que la connexion soit terminée. Un code de sortie nul signifie que la demande a été acceptée, pas que le trafic circule.

Lisez l’état séparément :

osascript -e 'tell application "/Applications/Tunnelblick.app" to get state of first configuration where name = "HQ"'

CONNECTED est un résultat d’état de connexion. Il ne prouve pas encore que la ressource privée dont votre tâche a besoin est joignable ; vérifiez-le séparément avant de lancer un travail dépendant.

D’autres contrôles de l’interface de script couvrent des actions plus larges et ne sont pas nécessaires quand un seul profil change.

Attendez avec une échéance, puis échouez

Interroger sans fin est la façon dont un script reste bloqué toute la nuit et bloque l’exécution suivante. Donnez à l’attente une échéance, un intervalle court et une issue d’échec explicite. Traitez tout état autre que CONNECTED comme non prêt, y compris les états transitoires. Journalisez le dernier état observé pour que l’échec s’explique de lui-même.

Une boucle bornée ressemble à ceci :

for i in $(seq 1 30); do
  state=$(osascript -e 'tell application "/Applications/Tunnelblick.app" to get state of first configuration where name = "HQ"')
  if [ "$state" = "CONNECTED" ]; then exit 0; fi
  sleep 1
done
echo "tunnel did not reach CONNECTED" >&2
exit 1

Trente secondes sont un exemple, pas un délai universel. Choisissez une échéance à partir du chemin d’authentification que le profil utilise réellement, et conservez-la dans le registre du flux de travail.

Vérifiez l’état et déconnectez par nom

Pour arrêter le même profil, appelez disconnect avec le même nom. Cela garde la demande étroite et laisse les autres configurations tranquilles.

osascript -e 'tell application "/Applications/Tunnelblick.app" to disconnect "HQ"'

Gardez le nom du profil et le contrôleur ensemble dans le registre du flux de travail, avec les contrôles d’authentification et d’achèvement attendus. C’est ce registre qui rend la commande vérifiable six mois plus tard.

Le comportement au démarrage avec l’ordinateur est un autre mode. Utilisez l’option de démarrage documentée de Tunnelblick et la configuration d’identifiants qu’elle attend. Une commande exécutée dans une session de bureau ouverte et un service qui démarre avec la machine ne partagent pas de contexte. Ne supposez pas qu’un script qui fonctionne pendant votre session s’exécutera au démarrage. Testez le chemin de démarrage séparément, avec la même échéance et la même journalisation.