Pourquoi un VPN par application rate la copie professionnelle d’une application Android

Une même application apparaît deux fois sur un téléphone doté d’un profil professionnel, et les deux copies ne relèvent pas du même sujet. Un VPN par application configuré dans un contexte donné régit l’instance de ce contexte, ce qui explique qu’une règle nommant le paquet puisse laisser l’autre copie intacte. Ce n’est pas un défaut à contourner, c’est la frontière du profil qui fait exactement ce pour quoi elle a été conçue. La question à laquelle il vaut la peine de répondre est de savoir quel contexte possède le VPN et lequel possède l’application que vous cherchez à protéger.

Une icône, deux installations, deux propriétaires de la stratégie

Android donne au profil professionnel son propre contexte administré, avec des applications, des comptes et une stratégie distincts, si bien que le lanceur peut afficher deux entrées qui partagent un nom et un badge. Un service VPN démarré dans un contexte fonctionne pour les utilisateurs de ce contexte, et c’est le mécanisme qui explique tout le problème. L’icône indique l’application sur laquelle vous avez appuyé, pas le profil auquel appartient le trafic qui en résulte. C’est pourquoi le propriétaire doit être lu dans le profil et non dans l’image.

Une organisation peut aussi imposer un comportement toujours actif ou bloquant sans VPN pour la partie administrée, ce qui change ce qui se passe lorsque le tunnel est coupé. La partie personnelle n’offre aucune garantie de ce genre, sauf si vous en avez construit une vous-même.

Ce que signifie réellement une liste d’applications autorisées

La prise en charge du VPN par application dans Android repose sur des listes, documentées dans le guide sur les utilisateurs de VPN et les profils professionnels et les deux types de listes ont des valeurs par défaut opposées. Une liste d’applications autorisées signifie que seuls les paquets nommés utilisent le tunnel et que tout le reste est exclu, tandis qu’une liste d’applications non autorisées signifie que tout est inclus sauf les paquets nommés. Inversez cela et vous avez construit l’opposé de la stratégie voulue, alors que l’écran des réglages semble toujours plausible. La liste est évaluée dans le contexte où le VPN s’exécute, donc un nom de paquet présent dans les deux profils ne correspond qu’à la copie de ce contexte. Un paquet non listé dans l’autre profil ne regarde simplement pas ce VPN.

Écrivez le comportement pour les deux ou trois applications qui comptent, car la différence entre tout-sauf et seulement-celles-ci décide si une application personnelle fuit autour du tunnel ou échoue en mode fermé. Un petit tableau vaut mieux qu’un paragraphe ici : une ligne par profil, avec le type de liste et la valeur par défaut pour tout le reste.

Quel côté fait tourner le tunnel, et sous quelle stratégie

Un VPN grand public ne retire pas les contrôles de l’organisation du profil administré, et un VPN de profil professionnel n’est pas un tunnel général pour les applications personnelles. Si l’organisation exige son propre client pour les applications administrées, le client personnel est un arrangement distinct avec sa propre stratégie et ses propres modes de défaillance. Décidez quel mécanisme doit porter quel trafic avant de comparer les résultats, sinon vous mesurez deux systèmes et appelez la différence un défaut. À l’intérieur de son propre contexte, la partie administrée l’emporte généralement, et c’est le comportement voulu.

Le cas délicat est une application administrée qui a besoin d’une route que la stratégie administrée ne fournit pas. C’est une demande d’exception à l’organisation, pas une raison de désactiver le profil professionnel.

Tester l’instance que vous visiez réellement

Lancez la copie qui vous intéresse et inspectez la requête depuis l’intérieur, car une vérification de l’adresse publique dans le navigateur personnel ne dit rien de l’application professionnelle. Vérifiez séparément le compte connecté et la résolution de noms interne, puisqu’un nom interne peut dépendre de la route administrée tandis que la navigation publique reste ailleurs. Notez quelle copie a produit quel résultat au moment du test, et mettez le profil dans l’étiquette ; une capture d’écran avec deux icônes identiques n’est pas une preuve. Répétez la vérification après une reconnexion et après la recréation du profil, car la stratégie peut s’appliquer de nouveau entre-temps.

Si vous ne pouvez pas dire quelle copie a répondu, corrigez l’étiquetage avant de tirer la moindre conclusion. Un résultat ambigu est pire qu’aucun résultat, parce qu’il sera cité plus tard comme s’il avait tranché la question.

Documenter la couverture pour que le prochain test survive

Consignez trois faits ensemble pour chaque contexte : l’instance de l’application, le propriétaire de la stratégie et la couverture attendue. Cela suffit à la personne suivante pour reproduire votre test sans deviner quelle icône elle a lancée. Ajoutez le type de liste et la valeur par défaut pour les paquets non listés, car c’est la partie que les gens lisent le plus souvent de travers.

Vérifiez ensuite un nom interne et une adresse externe de chaque côté, et notez ce qui doit se passer lorsque la partie administrée bloque le VPN personnel. Un téléphone où aucun des deux côtés n’est couvert alors que les deux semblent connectés est la défaillance contre laquelle il faut concevoir. Lorsque les deux profils ont réellement besoin d’un tunnel, prévoyez deux arrangements plutôt qu’une règle astucieuse.