Statut du VPN sur Mac : vérifier le profil, la ressource ou le flux

Quelqu'un demande si le VPN est actif, et trois personnes différentes entendent trois choses différentes. Un opérateur entend que le profil Office a terminé son authentification. Un planificateur entend que l'API privée répondra. Une revue de sécurité entend que cette requête précise est sortie par le chemin protégé. Un script qui parcourt la table de routage avec grep pour y trouver un nom d'interface ne répond de façon fiable à aucune de ces questions.

La liste de vérification commence donc avant l'exécution de la moindre commande : nommez le sujet du contrôle. Tout ce qui suit consiste à choisir l'interface capable de le rapporter réellement.

Nommer le sujet avant la commande

Écrivez la question sous forme de prédicat avec un sujet. « Le profil Office est connecté » est vérifiable et a un propriétaire qui peut y répondre. « Cette tâche peut joindre l'API interne » est un deuxième prédicat, avec un autre mode d'échec. « Cette requête emprunte le chemin protégé » est un troisième, et c'est le seul qui parle d'un flux unique et non de la machine entière.

Les mélanger produit une automatisation qui ment avec assurance. Une tâche qui vérifie l'état du profil puis suppose que l'API est prête alertera quelqu'un à la mauvaise couche, et une tâche qui pingue l'API et présente cela comme la preuve d'un tunnel ne distingue pas un VPN qui fonctionne d'un portable qui se trouve sur le réseau du bureau.

Un profil : interroger l'objet qui le détient

Pour un service Mac natif, les contrôles de connexion réseau de scutil rapportent exactement cela. Ils lisent l'état d'une configuration nommée au lieu de déduire quoi que ce soit d'une interface.

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

Le nom du profil dans cette commande doit être le vrai, celui de la sortie de la liste, pas une supposition. C'est un chemin en lecture seule pour les services natifs, et ce n'est pas une garantie qu'un client tiers y apparaisse ; un fournisseur qui gère son propre tunnel a besoin de sa propre interface d'état prise en charge. Vérifiez la liste avant d'écrire l'appel d'état, pour qu'un nom absent échoue visiblement au lieu de ne correspondre silencieusement à rien.

Dans une app Network Extension, lisez l'état à partir des objets gestionnaire et connexion plutôt qu'auprès du système. Attention à la portée : le chargement des configurations enregistrées ne renvoie que celles créées par l'app appelante, donc un résultat vide signifie « aucune des miennes », et non « aucun VPN sur ce Mac ». Distinguez une requête échouée d'un état déconnecté confirmé, et traitez les états transitoires comme des résultats à part entière au lieu de réessayer une connexion déjà en cours d'établissement.

Une tâche : l'aptitude est un prédicat distinct

Si la question est de savoir si une tâche peut avancer, testez sa dépendance réelle après que le propriétaire de la connexion a rapporté l'état attendu. Un contrôle d'aptitude borné vis-à-vis de la ressource privée est la bonne forme : il prouve ce dont la tâche a besoin, et rien de plus.

Il ne peut toujours pas prouver que chaque requête de la machine emprunte le tunnel, et il ne faut pas le présenter comme s'il le pouvait. De même, une ressource qui répond sur le réseau ordinaire n'est pas une preuve de VPN, et c'est pourquoi les deux contrôles restent séparés même lorsqu'ils réussissent tous les deux.

Lorsque la tâche exige vraiment un chemin protégé, cette exigence a besoin du dispositif d'application propre au déploiement : routage, exclusions de tunnel divisé, règle de pare-feu ou exigence au niveau de l'application. La disponibilité d'un point de terminaison est un fait sur un serveur. L'application est un fait sur la configuration du client, et l'un ne démontre pas l'autre.

Un flux : inspecter la route choisie

Pour un flux unique, examinez la destination, la famille d'adresses et le contexte source avec le diagnostic de routage qui rapporte le chemin retenu pour cette destination précise. Cette sortie nomme l'interface et l'adresse source réellement utilisées, ce qui est une affirmation bien plus forte qu'une entrée de route par défaut.

Les vérifications larges dans le navigateur répondent à une tout autre question. Un résultat d'IP publique décrit ce à quoi ressemblait une requête du point de vue d'un serveur, et il ne dit rien du DNS privé, des applications exclues ni d'un second contexte réseau qu'utilise un autre processus.

Renvoyer un résultat exploitable par l'appelant

Choisissez une forme de retour adaptée au prédicat : un état de profil nommé, un verdict d'aptitude de la ressource ou un inconnu explicite avec les éléments qui l'ont produit. Conservez l'identité de la configuration et la raison de l'échec à côté du verdict.

Cette dernière habitude fait toute la différence entre une automatisation qui aide et une automatisation qui masque les problèmes. « Office VPN : déconnecté, dernière tentative échouée à l'authentification » indique à un opérateur où regarder. « Le VPN est tombé » invite à une réinstallation, et « interface trouvée » invite à un faux tout va bien.

La référence Network Extension sur le chargement des configurations de tunnel enregistrées est l'endroit où confirmer la portée de l'app appelante avant de construire quoi que ce soit dessus.