Bloquer la configuration du VPN sur Android : liste de contrôle de déploiement

Quelqu'un vous demande d'empêcher les gens de configurer leur propre VPN sur des appareils Android gérés. La réponse tentante est une règle de pare-feu bloquant quelques ports familiers. Cette réponse ignore comment la plateforme fonctionne et comment les applications se connectent réellement.

Le contrôle pris en charge est une restriction de gestion sur l'appareil ou le profil que vous possédez, et elle a une portée explicite, un comportement propre à chaque version et une exception que vous devez configurer délibérément.

Passez les cinq vérifications ci-dessous dans l'ordre. Chacune peut invalider le plan, alors arrêtez-vous à la première qui ne tient pas.

Vérification 1 : décidez ce que signifie aucun VPN

Deux exigences se cachent derrière la même phrase. L'une est qu'aucun utilisateur ne puisse créer son propre VPN. L'autre est que seul le VPN approuvé de l'organisation puisse fonctionner. Les deux sont légitimes, et elles produisent des configurations différentes, des histoires de support différentes et des modes de défaillance différents.

Notez laquelle des deux vous achetez avant de toucher à une console de gestion. Si l'intention est un tunnel approuvé unique pour tous, vous mettez en œuvre un chemin approuvé avec une interdiction autour ; si l'intention est aucun tunnel du tout, vous devez aussi accepter que les chemins d'accès distant et de dépannage changent.

Trompez-vous et le déploiement semblera fonctionner tout en coupant discrètement le VPN dont dépend l'exploitation, ce que découvre généralement la personne d'astreinte à une heure peu commode.

Vérification 2 : confirmez l'autorité que vous détenez réellement

Android expose la restriction via UserManager.DISALLOW_CONFIG_VPN, documentée dans la référence UserManager. Elle empêche la configuration et le démarrage d'un VPN, et ce n'est pas un réglage qu'une application ordinaire peut s'appliquer à elle-même ou à d'autres applications.

Elle est appliquée par un administrateur autorisé : un propriétaire d'appareil pour l'appareil entier, ou un propriétaire de profil pour le profil géré, la même autorité étant disponible pour un propriétaire de profil à l'intérieur du profil géré. Si votre EMM ne peut pas agir comme l'un de ces rôles, vous n'avez pas ce contrôle, et aucune configuration de politique dans la console ne le créera.

La portée compte autant que l'autorité. Une restriction appliquée à un profil professionnel régit ce profil, pas la partie personnelle du même téléphone. La décrire comme un contrôle sur tout ce que fait l'utilisateur est inexact, et elle sera testée par la première personne qui installe un VPN dans le profil personnel et constate qu'il fonctionne.

Vérification 3 : connaissez le comportement par version

La restriction a changé au fil des versions, et les différences décident de ce que votre déploiement fera réellement sur les appareils du terrain.

La ligne API 31 est celle qui surprend les gens en plein déploiement : sur ces appareils, l'application n'est pas cosmétique, elle déconnecte un tunnel qui fonctionnait déjà. Planifiez cela comme un événement visible plutôt qu'un changement de réglages silencieux.

La ligne API 24 est celle qui vous sauve : un VPN en connexion permanente configuré par le propriétaire survit à la restriction, et c'est ainsi que le chemin approuvé reste disponible.

Vérification 4 : maintenez le chemin approuvé en vie

Configurez et testez le VPN en connexion permanente de l'organisation avant d'appliquer la restriction, pas après. Si vous appliquez d'abord, les appareils perdent le tunnel et les outils avec lesquels vous les diagnostiqueriez en même temps.

Vérifiez explicitement trois choses : que le VPN en connexion permanente est créé par le propriétaire et non par l'utilisateur, qu'il démarre sur ces appareils après l'application, et qu'il survit à un redémarrage. Un tunnel qui ne monte que manuellement n'est pas un chemin approuvé ; c'est une file de tickets de support.

Conservez une voie de récupération qui ne dépend pas du fait que le tunnel soit actif. Une console de gestion, un chemin d'administrateur local ou un canal hors bande fonctionnent tous. Ce qui ne fonctionne pas, c'est de supposer que vous pouvez réparer une politique cassée via la connexion que la politique vient de désactiver.

Vérification 5 : vérifiez, puis décrivez la limite honnêtement

Testez avec un appareil réel et un compte réel. Confirmez qu'un utilisateur ne peut ni ajouter ni démarrer un VPN, confirmez que le tunnel approuvé se connecte et transporte du trafic, et confirmez que le profil personnel se comporte toujours comme documenté. Ces trois résultats sont les critères d'acceptation.

Ensuite, faites attention à ce que vous affirmez. La restriction régit la capacité VPN d'Android. Elle ne transforme pas chaque connexion autorisée en protocole inspecté, et elle n'empêche pas une application d'acheminer ses propres requêtes via un proxy explicite. Bloquer UDP 500, UDP 4500 et un OpenVPN port n'est pas le même contrôle, car le trafic peut circuler sur de nombreux transports, y compris un HTTPS d'apparence ordinaire.

Si l'exigence est plus large que la capacité VPN, combinez-la avec la politique de distribution des applications, les contrôles de compte et les restrictions réseau adaptées à l'environnement. Et notez ce qui reste hors de portée, afin que personne ne répète une restriction partielle comme une restriction complète lors du prochain audit.