Pourquoi une application ne peut pas activer un profil VPN enregistré sur Android ou iOS

Deux tâches très différentes sont rangées sous le nom de VPN programmatique, et une seule est accessible à une application ordinaire sur l’une ou l’autre des deux plateformes mobiles. La première consiste à activer un profil que l’utilisateur a déjà enregistré ; la seconde à construire un tunnel dans votre propre processus. Android vous donne la seconde via VpnService et iOS vous donne la seconde via l’autorisation Network Extension, tandis que la première reste au système, à un propriétaire d’appareil ou à un serveur MDM. Déterminer laquelle vous avez réellement besoin rend généralement le projet plus petit.

Deux tâches qui partagent un nom

Activer un profil enregistré signifie dire à un tunnel existant de monter : un hôte, un identifiant, un protocole, tout déjà configuré quelque part que l’utilisateur peut voir. Construire un tunnel signifie que votre code possède l’interface, la boucle de paquets et le protocole. Ils se ressemblent dans un backlog produit et ne partagent presque aucune implémentation.

Aucune des deux plateformes mobiles n’expose la première à une application SDK. Une connexion qui apparaît sans que l’utilisateur fasse quoi que ce soit est indiscernable d’un logiciel malveillant, c’est pourquoi les deux systèmes placent une porte de consentement devant toute application qui transporte du trafic.

Android : une porte de consentement et aucune API de profils

VpnService existe depuis Android 4.0 et permet à une application de créer une interface tun, puis de lire et d’écrire des paquets. Le service doit être déclaré avec BIND_VPN_SERVICE, et VpnService.prepare() produit la boîte de dialogue système qui demande à l’utilisateur de l’autoriser. L’exemple de la plateforme, ToyVpn, est l’énoncé le plus clair de la forme visée : votre code possède l’interface et tout ce qui la traverse.

Ce qu’elle ne fait pas, c’est ajouter une entrée à l’écran des réglages VPN du système. Il n’existe aucune API publique pour cela, et l’application Réglages garde ses profils dans un magasin qu’une application ordinaire ne peut pas atteindre. Les appels aux classes cachées depuis une application normale produisent des profils que le système ne liste jamais, c’est pourquoi du code qui semblait fonctionner sur une version cesse silencieusement de fonctionner sur la suivante.

La voie gérée est distincte. Un propriétaire d’appareil ou de profil peut désigner un paquet VPN toujours actif via les API de stratégie de l’appareil, et un outil d’entreprise peut pousser un profil que l’utilisateur approuve ensuite. C’est une autorité de gestion d’appareil, pas une permission qu’une application demande à l’installation. Si votre client est une organisation, c’est la voie à planifier ; si votre client est une personne qui installe depuis une boutique, elle n’est pas disponible du tout.

iOS : l’autorisation est la frontière

iOS répartit le même travail différemment. Un client VPN implémente un fournisseur de tunnel de paquets ou un proxy d’application dans le cadre Network Extension, et l’autorisation correspondante doit être accordée au compte développeur. Une configuration VPN personnelle via NEVPNManager existe pour le cas le plus simple, et elle s’exécute toujours dans le même modèle de permissions. Apple documente toute la surface dans la référence Network Extension, qu’il vaut la peine de lire avant de cadrer le travail.

Il n’existe aucun moyen pris en charge d’ouvrir l’écran des réglages VPN, de lire les configurations enregistrées de l’utilisateur ou d’en démarrer une. Ce qu’un client peut faire, c’est fournir un profil de configuration que l’utilisateur installe, puis utiliser le tunnel résultant via des appels réseau ordinaires. Le tunnel par application est attribué par un serveur MDM via une règle à la demande, pas choisi par l’application à l’exécution.

Un client VPN d’un grand fournisseur n’est pas la preuve que votre compte peut fournir la même chose. Ces autorisations sont demandées par compte développeur et examinées, le risque de calendrier repose donc sur Apple, pas sur votre plan de sprint.

Le bureau va plus loin, mais la propriété est inchangée

Windows est le cas permissif. Add-VpnConnection crée une entrée de carnet d’adresses depuis une session PowerShell élevée, et rasdial la connecte ou la déconnecte depuis un script. Une application peut aussi piloter un client fournisseur via sa ligne de commande documentée. Créer le profil reste une action administrative, car l’entrée vit dans un magasin à l’échelle de la machine.

macOS se comporte de la même façon avec d’autres outils. scutil --nc start et stop agissent sur des services qui existent déjà, tandis que créer l’un d’eux est une tâche d’administration système. Posséder le processus sur un portable ne fait pas de vous le propriétaire de la configuration.

Quoi construire à la place

Si l’exigence réelle est que votre application atteigne une API interne, le tunnel que l’utilisateur exécute déjà suffit. Faites des requêtes HTTPS normales, laissez le système choisir le chemin, et cessez d’essayer de contrôler le tunnel. Si l’exigence est que seul le trafic de votre application utilise le tunnel, demandez un VPN par application via le canal de gestion, ou terminez TLS dans l’application contre un service joignable sans lui.

Les API cachées ne sont pas un raccourci qui vaut la peine. Elles changent entre les versions, elles échouent à la revue d’application, et les pannes qu’elles produisent ressemblent, pour qui hérite du code, à des pannes réseau ordinaires. La comparaison n’est pas Android contre iOS ; c’est posséder un tunnel contre demander à la plateforme d’acheminer le trafic, et seule la première est à construire de votre côté.