Comment lire l'état VPN et proxy d'une application professionnelle gérée

Une application professionnelle échoue sur un téléphone géré, quelqu'un vérifie l'interrupteur VPN, le voit activé et déclare le chemin sain. C'est là que s'arrêtent la plupart de ces diagnostics, et c'est trop tôt : un transport VPN actif ne dit pas que les requêtes de cette application l'ont utilisé, et le proxy qui s'applique réellement peut être par application ou choisi par un fichier PAC plutôt qu'affiché dans les Paramètres. Partez de l'application et du profil précis que vous déboguez, puis lisez la vision que la plateforme a du chemin.

Partez de l'application et de son profil

Une application portant un badge professionnel s'exécute généralement dans un profil séparé avec sa propre politique réseau. Un navigateur personnel sur le même téléphone n'en est pas une preuve, et un résultat venant de l'appareil d'un collègue avec une autre gestion non plus. Notez à quel profil appartient l'application avant de lire quoi que ce soit.

Dans les Paramètres, listez les entrées VPN configurées et notez à qui chacune appartient. Sur les versions Samsung, les libellés de menu changent d'une version à l'autre, alors décrivez l'entrée plutôt que le chemin qui y mène. Une entrée grisée ou gérée appartient à qui administre l'appareil ; la désactiver par expérience modifie ce que vous cherchez à mesurer et peut aller à l'encontre de la politique.

Lisez l'état que la plateforme rapporte

Dans une activité existante de vos outils de support, à partir d'API 23, l'état du réseau peut être lu sans envoyer un octet. L'appel a besoin de la permission manifeste normale ACCESS_NETWORK_STATE pour la lecture des capacités.

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

Chaque valeur répond à une question étroite. Le réseau actif est le réseau par défaut du processus appelant à cet instant. La vérification des capacités vous dit si ce réseau par défaut est adossé à un VPN. L'appel au proxy rapporte le proxy HTTP par défaut effectif, et l'objet renvoyé peut décrire soit un proxy statique, soit un script PAC.

Si vous avez besoin de la vue par réseau plutôt que de celle par défaut, lisez les propriétés de lien du même réseau et comparez avec cm.getLinkProperties(network)?.httpProxy. Un proxy installé par la gestion de l'appareil apparaît dans l'appel au proxy par défaut et non dans les propriétés de lien, ce qui est un moyen rapide de distinguer un proxy fourni par la politique de celui qu'a donné le réseau.

Gardez la sortie dans votre canal de support plutôt que dans un rapport public. Les noms d'hôte du proxy, les URL PAC et les suffixes internes révèlent comment votre organisation achemine le trafic, et aucun d'eux n'est nécessaire pour décrire la panne.

Interprétez chaque champ de façon étroite

Un réseau nul ou un objet de capacités nul signifie que l'état réseau de l'appelant était indisponible ou a changé pendant la lecture. Cela ne veut pas dire qu'il n'y a pas de VPN. Traitez-le comme inconnu et relisez après que l'application est passée au premier plan, plutôt que comme un résultat négatif.

Un transport VPN est le plus faible des positifs. Toute application détenant un VpnService en produit un, y compris une application de filtrage locale qui n'envoie jamais votre trafic nulle part. Donc une valeur true dit qu'un réseau par défaut adossé à un VPN existe, pas que la sortie de votre organisation a été utilisée et certainement pas qu'une inspection a eu lieu.

Un proxy par défaut nul signifie que cette API ne rapporte aucun proxy HTTP par défaut pour la configuration effective. Cela exclut très peu : une application peut porter son propre réglage SOCKS, implémenter son propre client HTTP ou être pilotée par un proxy sur la passerelle dont l'appareil n'apprend jamais rien.

PAC est le cas qui défait une réponse à valeur unique. Un script peut router une destination via un proxy et en envoyer une autre en direct, si bien que deux requêtes de la même application en une seconde peuvent emprunter des chemins différents. Et une application qui lie ses sockets à un réseau choisi, ou appelle bindProcessToNetwork, n'est pas du tout tenue de suivre la valeur par défaut.

Ce que cet instantané ne peut pas vous dire

Ce n'est pas un historique. Rien ici n'enregistre quel chemin a pris la requête défaillante, et une lecture réussie après la panne n'est pas une preuve sur la panne. Ce n'est pas non plus un inventaire : vous obtenez le réseau par défaut du processus appelant, pas la liste des connexions privées de chaque application.

Il ne dit rien non plus de ce qui se passe au-dessus du socket. Une poignée de main TLS qui échoue sur un appareil géré peut être un problème de magasin de confiance, une divergence d'épinglage ou un nom que le proxy refuse, et aucun de ceux-là n'apparaît dans une lecture de connectivité.

C'est pourquoi les deux moitiés comptent ensemble : l'instantané resserre où regarder, et les diagnostics propres à l'application disent ce qui a réellement échoué.

Rapportez-le sous une forme qu'un administrateur peut utiliser

Donnez l'application touchée, le profil, l'horodatage et l'étape exacte qui a échoué : résolution de noms, connexion TCP, poignée de main TLS ou un statut HTTP. Ajoutez les valeurs de l'instantané telles qu'elles ont été lues, les nuls écrits comme nuls plutôt que comme aucun. Notez si d'autres applications du même profil échouent de la même façon, ce qui sépare un problème d'application d'un problème de chemin sur tout le profil.

Puis arrêtez-vous et laissez le propriétaire du chemin répondre. Ne traitez pas un certificat d'entreprise, une adresse de proxy ou une entrée VPN comme une autorisation de retirer la gestion ou de contourner la route approuvée ; cela transforme un cas de support en incident de politique.

Le contrat du proxy par défaut est court et vaut une lecture, parce qu'il définit exactement quel proxy l'appel rapporte, et toute lecture excessive de cet instantané commence par supposer qu'il en rapporte davantage.