Pourquoi votre app iOS ne peut pas activer ni désactiver le VPN du système

Un chef de produit demande un bouton qui allume le VPN de l’entreprise, et la demande paraît anodine. Sur iOS, ce n’est pas une petite fonctionnalité ; elle sort du contrat public, et chaque contournement échoue à la revue ou casse à la version suivante. Faites passer la demande par ce que la plateforme autorise réellement, et le design s’écrit en grande partie tout seul. Une app peut posséder une configuration VPN et la démarrer. Une app ne peut pas atteindre l’interrupteur du système, ne peut pas lire l’état d’un profil qu’elle n’a pas créé et ne peut pas maintenir un utilisateur connecté contre sa volonté.

Partez des trois choses que l’utilisateur veut dire

Séparez les sens avant de séparer les API. Parfois l’utilisateur veut le tunnel de votre app connecté, parfois il veut basculer l’interrupteur de Réglages pour un profil installé par quelqu’un d’autre, et parfois il veut que le téléphone ne puisse pas naviguer sans le tunnel. Cela correspond à trois mécanismes différents, et seul le premier est ouvert à une app ordinaire.

Le deuxième sens est celui qui fait naître les questions Stack Overflow, et il n’a pas de réponse prise en charge. L’interrupteur de Réglages appartient à l’utilisateur et, sur les appareils gérés, au profil. Aucune API publique n’énumère les configurations VPN, n’indique si le tunnel système est actif ni ne le bascule.

Ce qu’une app peut réellement créer

NetworkExtension donne à une app une configuration qui lui est propre via NEVPNManager. Avec le droit Personal VPN et le consentement de l’utilisateur, l’app enregistre une configuration qui apparaît dans Réglages sous son propre nom, et elle peut démarrer ou arrêter cette seule connexion. C’est une capacité réelle et vérifiable, et c’est aussi toute la portée : le gestionnaire ne lit et n’écrit que ce qu’il a créé.

Le droit n’est pas automatique. Vous le demandez à Apple et justifiez pourquoi l’app a besoin d’un tunnel, et un client dont le seul but est d’allumer le profil d’un autre n’a pas de bonne réponse. Les fournisseurs de tunnels par paquets suivent la même règle avec une autre classe : NETunnelProviderManager possède les configurations basées sur un fournisseur que l’app elle-même a installées. Aucun des deux chemins n’atteint un profil livré par MDM.

Le consentement s’applique aussi au moment d’enregistrer. Écrire une configuration demande l’accord de l’utilisateur, et cette demande n’est pas quelque chose qu’une app peut supprimer par confort.

Lire l’état se heurte au même mur

L’état semble plus aimable que le contrôle et il est tout aussi fermé. NEVPNStatus signale invalide, déconnecté, connexion, connecté, réaffirmation ou déconnexion pour la configuration propre à l’app, et une notification part à chaque changement. Il ne dit rien d’un tunnel installé par un profil de gestion, qui est justement l’état qu’un service d’assistance veut voir.

La surveillance du chemin réseau et les changements d’interface sont proposés comme substituts en revue de design. Ils décrivent le chemin que prend le trafic de l’app, qui change pour des raisons sans rapport avec l’état du VPN, et les utiliser comme indicateur VPN donne une interface qui ment dans les deux sens.

On Demand et Always On sont les vrais leviers

Les leviers pris en charge vivent dans le profil plutôt que dans l’app. Les règles On Demand indiquent au système quand se connecter : une liste ordonnée de conditions avec des actions, évaluée par le système d’exploitation, pas par votre code. Une règle qui se connecte sur n’importe quelle interface crée une sensation de connexion permanente sans donner aucun contrôle à l’app.

Always On VPN est le mécanisme d’application, et il est lié à la supervision. Sur un appareil supervisé, le MDM installe un profil qui maintient le tunnel actif ; sur un téléphone personnel non supervisé, les mêmes clés ne produisent pas le même comportement. Cette asymétrie est délibérée, et aucune combinaison de clés de charge utile ne l’élimine. Quand l’exigence est vraiment que le VPN soit activé, l’exigence est en fait que l’appareil soit géré.

Entre les deux se tient le cousin plus faible : une règle qui reconnecte après que l’utilisateur s’est déconnecté. Elle reconnecte à la prochaine évaluation de la règle, ce qui n’est pas la même chose qu’immédiatement, et un utilisateur qui s’est déconnecté exprès remarquera la différence. Concevez l’interface autour de cet écart au lieu de promettre un verrou.

Livrez le chemin pris en charge

Quatre questions fixent le mécanisme avant qu’il existe du code : qui possède l’appareil, s’il est supervisé, quel client termine le tunnel et d’où vient le profil. Si l’une de ces réponses manque, la demande de fonctionnalité n’est pas prête à être estimée.

Une API privée qui tripote le VPN du système passera une démo et échouera à la revue, et si elle est livrée autrement elle casse à la version suivante d’iOS. Il n’existe aucune version de cet échange qui vaille la peine pour un interrupteur.

La télémétrie de gestion est un canal à part : elle indique qu’un profil est installé et si l’appareil est conforme, ce qui est du reporting et non une surface de contrôle par app. Testez le parcours sur un appareil réel après chaque mise à jour, car le comportement pris en charge vit dans le système et le système bouge.