Les profils IKEv2 VPN d’Android sont par utilisateur, pas par appareil

L’expression VPN intégré recouvre sur Android deux choses sans rapport : une implémentation de protocole que la plateforme exécute pour vous, et la forme des réglages que le constructeur a choisi d’exposer. Ce ne sont pas le même objet, et ni l’une ni l’autre ne garantit que le tunnel appartient à l’utilisateur dont les applications en ont besoin. Le provisionnement a lieu dans un utilisateur donné avec un paquet appelant donné, et tout ce qui suit hérite de ce contexte. Lisez la chaîne de propriété avant l’écran des réglages.

Ce que la plateforme construit pour vous

Depuis Android 11, la plateforme expose le provisionnement VPN via VpnManager. Une application approuvée décrit un profil IKEv2, et la plateforme mène elle-même l’échange IPsec et IKE, si bien que l’application ne touche jamais aux paquets. C’est la différence de fond avec une application VPN maison, qui implémente VpnService et construit le tunnel dans son propre processus.

val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
    .setAuthUsernamePassword(user, secret, rootCa)
    .build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)

L’appel ci-dessus est une esquisse de la forme, pas un bloc à copier : le constructeur a plusieurs variantes d’authentification, elles diffèrent selon le niveau d’API, et le profil porte aussi le matériel de confiance du certificat serveur. Pour la question de la propriété, l’essentiel est plus étroit que la syntaxe.

Deux propriétés découlent de ce choix. Le profil est une donnée, donc un administrateur peut le provisionner au lieu de le saisir à la main. Et le tunnel est un réseau de la plateforme, donc les applications le voient comme un réseau à transport VPN et non comme la socket d’une autre application.

La propriété, c’est l’utilisateur, puis le paquet

Le multiusager d’Android est une séparation réelle, pas une étiquette. Un profil professionnel est un utilisateur distinct avec ses paquets installés, ses données d’applications, son magasin de clés et ses ancres de confiance. Le même produit installé aux deux endroits, ce sont deux instances avec des identifiants d’utilisateur différents, même si les icônes et les noms sont identiques.

Le provisionnement est enregistré pour le paquet appelant dans cet utilisateur. Une application de provisionnement lancée dans le profil personnel crée donc un tunnel personnel, et les applications professionnelles du profil professionnel n’en voient rien. L’inverse est vrai aussi, et c’est pourquoi un tunnel de profil professionnel est invisible aux applications personnelles sans une stratégie explicite qui dit le contraire.

Un contrôleur de stratégie d’appareil peut provisionner pour le compte d’un profil géré, ce qui explique l’entrée dont personne au bureau ne se souvient. Si vous auditez un téléphone, c’est le propriétaire probable d’un profil grisé, et ce n’est pas à vous de le supprimer par curiosité.

Trois portes avant qu’un paquet circule

La première porte est l’autorité : la gestion doit autoriser un VPN, et certains déploiements restreignent le type autant que l’existence. La deuxième est l’identité : le certificat client ou les identifiants doivent être disponibles dans l’utilisateur propriétaire du profil, car un certificat importé dans le magasin personnel n’est pas visible pour le profil professionnel.

La troisième est le consentement et la stratégie. L’utilisateur approuve en général la connexion au premier usage, et un administrateur peut en plus l’épingler comme toujours active, éventuellement avec verrouillage pour que le trafic ne sorte pas du tunnel. Ces réglages décident de ce qui se passe quand le tunnel tombe, et c’est la partie que les gens remarquent.

La portée est le lieu où les trois se rejoignent. Le profil fixe la passerelle et l’identité, tandis que la couche de stratégie décide quelles applications peuvent utiliser le tunnel et si le trafic y est forcé. Deux téléphones avec des adresses de passerelle identiques peuvent donc se comporter très différemment.

Pourquoi une connexion personnelle ne couvre pas les applications professionnelles

Le trafic d’une application professionnelle naît dans l’utilisateur professionnel, et la stratégie réseau applicable est celle de cet utilisateur. Un tunnel établi dans le profil personnel ne le transporte pas, quel que soit l’aspect sain de l’indicateur. Ce seul fait explique la plupart des rapports où l’utilisateur jure que le VPN est connecté alors qu’une application précise n’atteint toujours pas un service interne.

La résolution de noms suit la même frontière. Les suffixes DNS privés et les ancres de confiance sont par utilisateur, donc un nom d’hôte interne qui se résout dans le profil personnel peut échouer dans le profil professionnel même avec un tunnel d’apparence équivalente, car la stratégie du résolveur et le magasin de CA sont des objets différents.

Vérifiez sur une vraie inscription, pas sur un téléphone de laboratoire

Sur l’appareil, identifiez d’abord le propriétaire de l’entrée : quel utilisateur, quel paquet, et si le profil vient du provisionneur de la plateforme ou d’une application dotée de son propre service VPN. Confirmez ensuite que l’identité attendue par le profil est réellement présente dans le magasin de clés de cet utilisateur.

Testez le cycle de vie, pas seulement la connexion. Connectez-vous, déverrouillez le magasin d’identifiants, laissez le profil professionnel en pause pour la soirée, ramenez-le et vérifiez que le tunnel revient sans appui manuel. Un profil professionnel qui s’éteint après les heures emporte son tunnel, et c’est un comportement attendu et non une panne, à condition que l’état d’indisponibilité attendu soit écrit.

Enfin, testez l’application professionnelle elle-même contre un point de terminaison interne connu et comparez au résultat du profil personnel. Les deux peuvent différer ; ce qui ne doit pas différer, c’est le modèle de propriété. Si le tunnel appartient au mauvais utilisateur, aucune réémission de certificats n’y changera rien.

Ne forcez pas le sujet en lançant des activités de réglages cachées pour révéler un menu, et ne copiez pas de clés privées entre profils pour faire apparaître une connexion. La référence VpnManager documente ce qu’un appelant peut provisionner ; si le chemin approuvé ne couvre pas votre cas, c’est une décision de l’administrateur, pas un problème de réglages.