Où une règle de pare-feu Android doit vivre quand un VPN est actif

Vous avez une phrase de politique : cette application peut atteindre le service de travail, et rien d’autre. La question suivante ressemble à un choix de produit, mais c’est une question d’emplacement, car chaque point d’application possible voit une partie différente du trafic du téléphone. La passerelle ne voit que ce qui entre dans le tunnel. Le filtre côté téléphone ne voit que ce qu’il est autorisé à observer. Faire passer une seule requête par les deux rend la réponse évidente.

Partez de la phrase, pas du produit

Développez l’exigence avant de choisir quoi que ce soit. Cela veut dire le paquet et le profil dans lequel il tourne, car une application du profil professionnel est un autre utilisateur que la même application dans le profil personnel. Cela veut dire la destination : hôte, port et protocole, pas un nom de service. Cela veut dire le chemin DNS qui résout ce nom, et cela veut dire ce qui doit se passer quand le tunnel n’est pas disponible.

Écrite, la politique de l’exemple tient en quatre lignes : l’application de travail peut atteindre le service de travail ; elle ne peut rien atteindre d’autre ; les autres applications restent inchangées ; sans tunnel, l’application de travail est refusée au lieu de basculer sur une voie directe. Chaque ligne a un propriétaire, et ce n’est pas toujours le même.

Étape 1 : ce que le téléphone lui-même peut appliquer

Un pare-feu Android sans root est un VpnService qui capture le trafic localement, même quand aucun tunnel distant ne se trouve derrière. Android autorise un seul service VPN actif par profil utilisateur, donc une seconde application de pare-feu ne se chaîne pas derrière la première. Elle la remplace, et l’interface que la première filtrait disparaît.

C’est pourquoi installer un pare-feu à côté d’un client VPN produit rarement la combinaison attendue. Si le pare-feu démarre et que le VPN se déconnecte, rien n’a été combiné ; les deux ont échangé leur place. Remplacer une interface n’est pas coopérer, et le symptôme est un tunnel qui tombe sans cesse chaque fois que l’autre application s’ouvre.

Des dispositions prises en charge existent : filtrage intégré au client VPN que vous utilisez déjà, contrôles de plateforme gérés via un contrôleur de stratégie d’appareil ou un profil professionnel, ou une architecture que le fournisseur documente. Tout le reste est une expérience à revérifier après chaque mise à jour d’application.

Étape 2 : ce que la passerelle peut appliquer

Une fois le trafic déchiffré à l’extrémité distante, la passerelle peut restreindre les paquets transmis à des adresses, services ou identités VPN authentifiées approuvées. C’est une application réelle pour tout ce qui en sort, et c’est le bon endroit pour limiter l’accès aux sous-réseaux privés.

Ce qu’elle ne reçoit pas, c’est l’identité de l’application du téléphone attachée à chaque paquet IP ordinaire. Plusieurs applications partageant une adresse de tunnel ne font qu’un sujet pour la passerelle, sauf si la conception leur donne des adresses distinctes ou des identités authentifiées distinctes. Une règle par utilisateur sur la passerelle n’est donc pas une règle par application sur le téléphone, quoi qu’en dise la console d’administration.

Étape 3 : listez ce qui n’arrive jamais

Une application exclue du VPN qui contacte un appareil proche n’atteint jamais la passerelle, donc un pare-feu de sortie ne peut pas refuser un paquet qu’il ne reçoit jamais. Il en va de même pour une voie directe involontaire pendant une panne et pour une exposition entrante sur le réseau d’accès local. Ce sont des limites locales par définition.

L’inverse est vrai aussi : une règle locale qui autorise une connexion ne donne pas accès via l’ACL du réseau privé de la passerelle. Une requête peut relever des deux limites, et en satisfaire une ne dit rien de l’autre.

Étape 4 : affectez chaque règle à un chemin

Mettez la décision dans un tableau avant de configurer quoi que ce soit, car les cellules vides sont l’endroit où les conceptions échouent.

La forme qui fonctionne est deux limites avec deux tâches. Une limite locale consciente des applications gouverne le comportement du téléphone, y compris le basculement direct, et une limite de passerelle gouverne les ressources distantes. Le côté passerelle peut autoriser le service de travail et refuser tout autre sous-réseau privé, tandis que la politique côté téléphone décide elle-même d’une voie directe que l’application pourrait prendre autrement.

Étape 5 : gardez le transport vivant, puis vérifiez

Quelle que soit la politique locale retenue, elle doit autoriser le transport qui établit et maintient le VPN. Bloquer ce transport laisse le téléphone sans tunnel et sans politique, ce qui n’applique rien de cohérent et se diagnostique mal, car l’application n’a tout simplement pas de réseau.

Vérifiez ensuite chaque ligne de la phrase d’origine plutôt que l’impression générale : l’application de travail atteint le service de travail, la même application est refusée sur une autre destination, une application qui n’est pas de travail se comporte comme avant, et tunnel arrêté, l’application de travail ne retombe pas sur une connexion directe. Vérifiez le chemin DNS séparément, car un DNS privé ou un résolveur chiffré peut contourner un filtre qui n’inspecte que les adresses.

Si l’une de ces étapes ne peut pas être satisfaite sur le téléphone, l’exigence est une question d’architecture et non un réglage de pare-feu. Répartir la politique entre un appareil que vous contrôlez et une passerelle que vous contrôlez est généralement la réponse honnête, et la documentation Android sur la connectivité VPN est l’endroit où confirmer ce que la plateforme autorisera ou non à un seul service.