Une application professionnelle exige un VPN ? Vérifiez d’abord ces trois couches

Le message dit que l’application a besoin d’un VPN, mais l’application signale généralement un symptôme plutôt que de nommer ce qui l’a bloquée. Trois responsables distincts peuvent produire cette phrase : le service privé auquel l’application parle, le code de politique de l’application et la couche de gestion de l’appareil qui contrôle le profil professionnel. Lequel pose la question change ce que vous devez faire, et un seul des trois se règle en connectant un tunnel. Trouver d’abord le responsable vous évite de réinstaller un client qui n’a jamais été le problème.

Ce que l’application peut vérifier elle-même

Avant de supposer une règle de plateforme cachée, rappelez-vous ceci : une application normale peut voir si un transport VPN est actif. ConnectivityManager signale les réseaux portant TRANSPORT_VPN, et l’absence de NET_CAPABILITY_NOT_VPN indique à tout appelant que le chemin actuel est tunnelisé. Un développeur qui veut refuser de fonctionner hors d’un tunnel peut le faire avec des API publiques et sans aucun outil d’entreprise.

Ce que l’application ne peut pas voir ainsi, c’est à qui appartient le VPN. Un indicateur de transport dit qu’un tunnel existe, pas qu’il se termine là où votre organisation l’attend.

Le chemin du service : noms et adresses privés

La version honnête la plus courante du message n’est pas du tout une vérification de politique. L’application résout un nom d’hôte interne, comme un wiki ou un point de terminaison d’API qui n’existe que dans la vue DNS de l’entreprise, et la résolution échoue avant l’exécution du moindre code de politique. Le tunnel peut être actif et faire passer le trafic internet général pendant que le DNS scindé envoie ce nom à un résolveur qui n’en a jamais entendu parler.

Les symptômes sont ici étroits. Un hôte échoue, le reste des appels réseau de l’application fonctionne, et la panne apparaît lors d’une résolution de nom plutôt qu’au lancement. Les certificats internes ajoutent un second mode de panne, car une application épinglée à l’AC de l’organisation rejette un certificat public même lorsque les paquets circulent.

Connecter un VPN commercial quelconque ne corrige rien de tout cela. Cela change votre adresse de sortie et laisse le nom interne tout aussi irrésoluble.

La couche de politique de l’application

Une application peut aussi porter sa propre porte. Les configurations gérées permettent à l’organisation de pousser des paires clé-valeur que l’application déclare, et l’application les lit via RestrictionManager. Une clé comme un nom de profil obligatoire ou une liste de réseaux autorisés relève entièrement de la conception du développeur, appliquée dans le code de l’application avec le texte d’erreur que ce code choisit.

C’est à cette couche que la formulation trahit généralement la cause. Si le message apparaît immédiatement au lancement, avant tout appel réseau, et mentionne une politique, un profil ou un administrateur, vous regardez probablement la logique de l’application plutôt qu’un paquet perdu.

Lire la même restriction sur un appareil personnel est une impasse. Les appareils non gérés n’ont aucune restriction à lire, donc l’application retombe sur la valeur par défaut avec laquelle elle a été construite.

La couche de la plateforme : toujours actif et verrouillage

La gestion de l’appareil ajoute une contrainte que l’application ne peut pas contourner. Un contrôleur de politique d’appareil peut appeler setAlwaysOnVpnPackage pour le profil professionnel, éventuellement avec le verrouillage activé, et une fois le verrouillage activé, la plateforme refuse le trafic qui ne passe pas par ce paquet. Le blocage est visible comme une condition système plutôt que comme une erreur d’application : les autres applications du profil cessent aussi d’atteindre le réseau.

La portée compte. Le VPN toujours actif est configuré par utilisateur, donc un paquet de profil professionnel ne couvre pas votre profil personnel, et un VPN personnel ne satisfait pas le paquet du profil professionnel. Deux profils, deux politiques réseau indépendantes, un appareil.

C’est aussi la seule couche où un VPN sans rapport ne peut pas aider, car la politique nomme un paquet précis.

Distinguer les trois

Parcourez les signatures dans l’ordre et arrêtez-vous à la première qui correspond. Un nom d’hôte qui échoue alors que tout le reste résout indique le chemin du service. Un refus immédiat au lancement avec une formulation de politique indique la logique de l’application. Un profil entier qui perd la connectivité chaque fois que le client approuvé se déconnecte indique le verrouillage. Et une application qui accepte n’importe quel tunnel vérifie l’indicateur de transport, pas l’identité de votre organisation.

Éléments utiles : le texte exact et son moment, si d’autres applications du même profil ont encore de la connectivité, si le nom privé se résout à l’intérieur du tunnel approuvé et si l’appareil affiche un badge professionnel pour l’application ouverte.

Que mettre dans la demande d’assistance

Une demande qui nomme la couche est orientée correctement du premier coup. Quelque chose comme : l’application du profil professionnel s’ouvre, la liste des ressources échoue après la connexion du VPN approuvé, la résolution du nom privé échoue dans le diagnostic autorisé, et les autres applications du profil continuent de fonctionner. Cela se lit comme un problème de route ou de résolveur et évite la boucle de réinitialisation du compte.

Si le VPN approuvé manque entièrement, la voie prise en charge est l’enrôlement ou le réapprovisionnement via votre administrateur. Supprimer le profil de gestion, installer un client sans rapport ou falsifier l’état du réseau modifie le dispositif de sécurité au lieu de le rétablir.

Commencez par la couche, pas par le client. Les trois signatures ci-dessus règlent généralement la question en une seule séance.