Votre script démarre le VPN ; il ne le provisionne pas

Vous écrivez un script qui exécute scutil --nc start avec le nom de la connexion, il fonctionne sur votre Mac, et il échoue sur chaque machine fraîchement installée du bureau. Le script n'est pas cassé. On lui demande quelque chose qu'il n'a jamais pu faire : démarrer une connexion existante n'est pas la même opération que d'en créer une.

Le provisionnement et le contrôle de session sont deux tâches avec deux responsables, et un flux de travail qui suppose le contraire passera tous les tests sur la machine où il a été écrit.

À quoi la commande de démarrage parle réellement

Une commande de contrôle de session s'adresse à une configuration qui existe déjà et qui est déjà approuvée. Elle demande au système de monter cette connexion nommée, en utilisant les réglages du serveur, les références d'identité et la politique enregistrés auparavant. Si ceux-ci n'ont jamais été installés, il n'y a rien à démarrer.

C'est pourquoi la panne apparaît sur du matériel neuf et non sur l'ordinateur portable de l'administrateur. Le portable a été provisionné il y a des mois par une personne qui l'a depuis oublié. Voyez la commande de démarrage comme une sonnette que quelqu'un a câblée le trimestre dernier. Appuyer dessus n'est pas la même chose que poser le câblage.

Trois responsables d'une configuration VPN

Un profil géré par l'organisation vient de la gestion des appareils. Le profil porte les adresses du serveur, la disposition d'authentification et la politique que l'organisation exige, et l'administrateur VPN est la personne qui les fournit. Un script ne devrait pas reconstruire ces réglages à partir d'un nom affiché qu'il a trouvé dans une liste.

Une configuration VPN personnelle native est créée via l'API Network Extension d'Apple, qui couvre les protocoles IPsec et IKEv2 intégrés. C'est une interface d'application avec une étape d'enregistrement et une approbation de l'utilisateur, pas une commande shell qui crée silencieusement n'importe quel type de tunnel qu'un fournisseur livre.

Un client tiers est un troisième cas, avec son propre format d'importation, son propre outil de gestion et souvent son propre assistant privilégié. Sa session appartient au processus de ce fournisseur. Trouver un service système au nom similaire n'est pas la preuve qu'une commande système contrôle le tunnel, et le supposer produit des scripts qui semblent fonctionner jusqu'à ce que le fournisseur mette à jour le client.

Le provisionnement natif comporte un enregistrement et une approbation

Le modèle d'Apple est charger, modifier, enregistrer. Une application charge les préférences existantes avant son premier enregistrement après le lancement, modifie la configuration, puis l'enregistre. L'enregistrement signale une erreur lorsqu'il ne peut pas persister, et ignorer ce résultat transforme un échec de provisionnement en échec de connexion trois étapes plus loin.

Le premier enregistrement exige aussi que l'utilisateur approuve l'application. C'est une frontière de sécurité délibérée, et cela signifie que la première exécution sur un Mac neuf est interactive même lorsque chaque connexion et déconnexion ultérieure peut être automatisée. Planifiez la première exécution comme une tâche humaine avec un humain présent. Automatisez la deuxième exécution et les suivantes, et dites-le dans le runbook pour que personne ne promette l'impossible. Un plan de déploiement qui promet une première exécution entièrement sans surveillance promet quelque chose que la plateforme n'offre pas.

Apple recommande aussi de valider la compatibilité du serveur avec un profil de configuration avant de s'appuyer sur l'API. Faire cette vérification d'abord sépare « le serveur n'acceptera pas ce client » de « le client n'a jamais enregistré les réglages », qui sont des tickets différents pour des équipes différentes.

Ce qu'une commande de démarrage répétable peut supposer

Après le provisionnement, un script peut sans risque cibler la connexion existante via l'interface de son propriétaire. Donnez-lui l'identité stable de la connexion plus l'action voulue, et rien d'autre. Il ne devrait pas lire un chemin de préférences deviné, ni supposer que le nom affiché dans le menu est unique sur tout le système.

Pour les connexions natives, une demande de session nommée comme scutil --nc start est une opération de contrôle. Elle n'installe pas les réglages du serveur, n'importe pas d'identifiants et n'effectue pas l'autorisation du premier enregistrement. Traitez-la comme la dernière étape d'une chaîne, jamais comme la chaîne entière.

Gardez les secrets hors des arguments de ligne de commande et hors de la sortie de diagnostic ordinaire. Quel que soit le mécanisme d'identité choisi par le déploiement, c'est celui sur lequel la commande de démarrage doit s'appuyer, et un mot de passe collé dans l'historique du shell est une constatation dans toute revue.

Deux vérifications d'acceptation

La première vérification est le provisionnement : prenez un Mac fraîchement installé et prouvez que la configuration est présente, qu'elle appartient au bon gestionnaire et qu'elle est pleinement approuvée. Faites-le avant de tester la connectivité, car un test de connexion sur une machine non provisionnée ne prouve rien sur le script.

La deuxième vérification est la session : connectez, atteignez la ressource autorisée et déconnectez proprement. Chaque échec a désormais un responsable, et c'est le bénéfice pratique de la séparation des deux tâches. Un profil manquant est un problème de livraison, une erreur d'enregistrement est un problème d'approbation, une connexion refusée est un problème d'authentification, et un délai d'attente après un démarrage réussi relève de la couche session. Aucun d'eux n'est « le script est cassé ».