Un profil VPN refuse de s’importer sur macOS : lisez d’abord la charge utile

Quand un profil s’installe proprement sur un Mac et se voit refusé sur un autre, le réseau n’a pas encore été atteint, donc les certificats, les passerelles et les mots de passe ne méritent aucun blâme. L’installateur s’est arrêté sur une charge utile qu’il ne voulait pas accepter, et il consigne normalement laquelle. Il ne reste donc que le fichier du profil et tout ce qui l’a généré comme lieux de travail raisonnables, et effacer les réglages sur le client devient un moyen de détruire des preuves plutôt qu’une réparation.

Lisez le profil au lieu de réinitialiser le Mac

Exportez le .mobileconfig et regardez ce qu’il contient réellement avant de toucher au client :

plutil -p profile.mobileconfig | head -60

Un profil VPN, ce sont en réalité deux charges utiles aux tâches différentes : com.apple.vpn.managed porte la connexion, et com.apple.dnsSettings.managed porte la configuration du résolveur. L’installation s’arrête à la première charge utile que l’installateur refuse, et le refus arrive dans le journal système avec le nom de cette charge utile, donc c’est le journal qui vous dit quelle section ouvrir. Gardez une copie du dernier profil qui s’est bien importé, car ce fichier est la base à laquelle votre différence est comparée.

Ce que le générateur a ajouté sans le dire

Apple Configurator 2.15, version 7A23, a émis le bloc suivant à l’intérieur de sa charge utile DNS :

<key>DNS</key>
<dict>
  <key>SupplementalMatchDomainsNoSearch</key>
  <integer>0</integer>
</dict>

Sur macOS 12.1, les profils écrits par cette version étaient refusés à l’import. Une connexion créée avec Configurator 2.11.1 est passée sans broncher, car cette version n’écrivait jamais la clé. Supprimez tout le dictionnaire DNS ou seulement la clé fautive, enregistrez à nouveau, puis réessayez sur la même machine avant de changer quoi que ce soit d’autre. Cette seule modification suffit généralement à toute la réparation.

L’outil a un piège qu’il vaut la peine de connaître avant de lui faire confiance. Une fois la clé supprimée, enregistrer la même connexion ne l’a pas remise, et elle n’est réapparue que lorsqu’une connexion a été créée de zéro. Traitez chaque profil fraîchement généré comme suspect et inspectez-le, surtout lorsqu’une série entière de connexions a été créée d’un seul coup.

La voie MDM échoue ailleurs

Un service de gestion qui pousse le même profil peut échouer à un autre endroit : le client se plaint qu’aucun service VPN n’a été créé du tout. Dans le cas signalé, une charge utile configurée pour l’authentification par certificat exigeait malgré tout un champ de mot de passe ; le remplir avec une valeur fictive a permis d’appliquer le profil, et rien n’a jamais utilisé cette valeur pour s’authentifier.

Si vous prenez cette voie, stockez une chaîne factice et jamais un identifiant réel, et gardez le vrai secret hors du corps du profil. Un profil qui porte un mot de passe fonctionnel devient un fichier à protéger comme une clé, ce qui est un problème bien plus considérable que l’import raté avec lequel vous avez commencé. Décidez à qui appartient cette valeur fictive avant que le profil soit distribué, pour que personne ne la prenne plus tard pour une valeur qui mérite d’être renouvelée. Documenter pourquoi elle existe prend une ligne et épargne une dispute dans six mois.

Vérifiez que le profil a réellement atterri

Un import réussi n’est pas un service qui fonctionne, alors vérifiez dans cet ordre :

profiles show -type configuration
scutil --nc list
scutil --nc start "Your VPN Service"
scutil --nc status "Your VPN Service"
scutil --dns | head -20

La première commande liste les charges utiles installées ; la seconde dit si un service VPN existe tout court. La dernière, lancée après connexion, montre le résolveur que le système utilisera vraiment. Lisez-les dans cet ordre et arrêtez-vous là où la chaîne casse, car un service manquant rend toute question sur le résolveur sans objet. Un profil peut être listé comme installé et ne rien posséder d’utilisable, et c’est exactement l’état que cette séquence est conçue pour exposer.

Si le tunnel monte alors qu’une entrée de service n’a toujours pas de nom utilisable, le champ du nom affiché s’est perdu à l’export, et le remède est un profil régénéré plutôt qu’un renommage sur le client. Si le résolveur continue de pointer vers le local, la charge utile DNS a été retirée plus à fond que vous ne le vouliez.

Déployez par étapes, un Mac à la fois

Installez sur un Mac géré qui exécute la même version du système, puis vérifiez trois choses séparément : le service apparaît, le résolveur change et une vraie requête interne réussit. C’est seulement après les trois que la portée doit s’élargir.

Ce sont trois résultats différents qui échouent de trois façons différentes, et c’est ce qui rend une machine de test digne de ces dix minutes. Un profil qui s’importe n’est pas un profil qui fonctionne, et la machine de la première étape attrape les deux types de défaillance avant que le reste du parc en voie un seul.