État du VPN sous macOS depuis le terminal : scutil, routes ou ping

Quelque part dans un script de déploiement, il y a une vérification de l’état du tunnel avant qu’une copie ne démarre. Trois réponses sont disponibles, et elles ne veulent pas dire la même chose : l’état du service que scutil rapporte, la route choisie par le noyau, et le fait que l’extrémité distante réponde vraiment. Les comparer, c’est la différence entre une vérification qui prédit la copie et une qui ne fait qu’embellir un journal.

Trois réponses à la question de savoir si le VPN est actif

L’état du service est un fait du plan de contrôle. macOS sait qu’une configuration est connectée parce que son processus client l’a dit. La route est un fait du plan de données : le noyau enverra cette destination par cette interface. L’accessibilité est un fait de bout en bout, et elle peut échouer pour des raisons qu’aucune des deux autres ne voit.

Une vérification utile combine les deux premières et se sert de la troisième pour confirmer que les deux autres ne mentaient pas. Chacune seule est une supposition avec un horodatage.

Lisez l’identifiant, pas le nom affiché

scutil --nc list
scutil --nc status "Office"

La liste imprime une ligne par service, et chaque ligne porte un état entre parenthèses suivi de l’identifiant du service, du type et du nom affiché. Écrivez le script sur l’identifiant, car le nom affiché est ce que quelqu’un a saisi dans les Réglages Système et il peut changer sans préavis. La commande d’état imprime un seul mot, suivi de statistiques pour certains types de service ; faites correspondre ce premier mot plutôt que de chercher le nom dans toute la sortie, qui apparaît aussi ailleurs.

Démarrer un service peut déclencher une demande d’autorisation ou être purement refusé lorsque le profil est géré. Ce refus n’est pas un défaut du tunnel ; c’est une déclaration de politique sur qui peut le monter.

Un client tiers se cache de la liste

Une liste vide ne signifie pas qu’il n’y a pas de VPN. Les configurations créées dans les réglages réseau du système lui-même apparaissent ici ; un client d’un fournisseur, un profil de gestion ou une application tierce peut maintenir un tunnel actif que cette commande ne voit jamais. Son propre outil fait autorité pour son propre service. Demander à scutil des nouvelles d’un client qui ne s’est jamais enregistré auprès de lui ne renvoie rien, et rien n’est pas la même réponse que déconnecté.

Quand la liste est vide mais que le trafic est manifestement chiffré, cherchez plutôt l’interface : un périphérique utun ou ppp avec une adresse dans la plage attendue est la preuve que quelque chose a établi un tunnel. C’est un signal plus faible qu’un état de service, alors associez-le à une vérification de route plutôt que de traiter l’interface comme une preuve d’identité. Plusieurs clients peuvent créer plusieurs interfaces de ce genre, et une seule d’entre elles appartient au tunnel que vous visiez.

L’état n’est pas le routage

Un service connecté dit que le tunnel existe. Il ne dit pas que votre destination l’utilise. Lisez les adresses, puis demandez directement au noyau :

ifconfig | grep -A4 utun
netstat -rn -f inet
route -n get 10.40.0.20

Un client de tunnel complet installe une route par défaut à travers le tunnel ; un client de tunnel divisé installe des préfixes privés précis. Les deux rapportent Connected, et un script qui ne vérifie que l’état passera joyeusement par le mauvais chemin. Arrêter un tunnel ne retire pas forcément des routes qu’un autre client a installées, et c’est une façon pour une machine de se retrouver à la fois avec un service connecté et une route périmée. Regardez la destination qui vous intéresse, pas la table de routage entière.

Le nommage est un problème à part

Les autres machines n’atteignent pas le Mac par son nom alors que son adresse fonctionne, et cela est signalé comme une panne de VPN. Le nom d’hôte local, le nom d’hôte et l’enregistrement DNS sont trois choses différentes. scutil --get LocalHostName affiche le nom Bonjour ; sudo scutil --set HostName mac-office définit le nom que le système rapporte.

Aucun des deux réglages ne crée d’enregistrement dans la zone du bureau. Si d’autres hôtes doivent résoudre le nom via DNS, le propriétaire de la zone doit l’ajouter, ou le script devrait utiliser l’adresse à la place. Fixer un nom stable rend les annonces cohérentes ; cela ne fait pas répondre le résolveur.

Inscrivez l’identifiant du service et la forme attendue de la route ensemble dans le script, et vérifiez les deux avant la copie. Un tunnel actif et mal routé échoue exactement comme pas de tunnel du tout, et la ligne de journal qui dit Connected enverra la personne suivante chercher au mauvais endroit.