Application exclue toujours en ligne ? Les règles par application et de route diffèrent

Exclure un paquet est une instruction de routage, non un blocage, donc les pages qui se chargent après la connexion du VPN sont attendues et non la preuve d'une panne. L'exclusion retire l'application du tunnel au lieu de la bloquer, et le réseau ordinaire transporte son trafic. Deux politiques distinctes se rencontrent ici : l'une choisit les processus, l'autre choisit les destinations. Les lire dans cet ordre explique pourquoi une icône connectée et une application qui fonctionne ne sont pas une contradiction.

Pourquoi une exclusion laisse le réseau ouvert

VpnService.Builder accepte soit une liste d'autorisation, soit une liste d'interdiction, jamais les deux. Seuls les paquets d'une liste d'autorisation sont routés par le tunnel. Une liste d'interdiction inverse cela : chaque paquet sauf ceux qui y figurent utilise le tunnel, et ceux qui y figurent gardent le chemin physique. Un paquet non listé sous une liste d'autorisation est aussi hors du tunnel, donc l'exclusion est l'état normal pour la plupart des applications dans ce mode.

Cela fait d'une entrée d'interdiction locale une décision de routage, non une règle de pare-feu. Si l'exigence est d'empêcher une application d'atteindre un hôte, le tunnel doit la couvrir et le serveur ou une politique locale doit refuser le trafic. Retirer une application du tunnel ne change que l'interface qui transporte ses paquets.

Le cas du Play Store est l'exemple délibéré habituel. Exclure le paquet de la boutique permet aux téléchargements d'utiliser la connexion sous-jacente lorsque la sortie du VPN gêne les transferts, et montre que l'exclusion signifie contournement et non blocage.

Un profil, une liste

Le constructeur lève une exception si les deux appels sont utilisés, donc le profil devant vous est soit une liste d'autorisation, soit une liste d'interdiction. Ce seul fait détermine comment lire chaque observation ultérieure. Vérifiez le code ou la configuration gérée avant la table de routage, car la liste décide de ce que signifie le reste de la sortie. Un profil hybride n'est pas un état que l'on peut observer.

La distinction prédit aussi ce que fera une application fraîchement installée. Sous une liste d'autorisation, elle reste dehors jusqu'à ce que quelqu'un l'ajoute, tandis que sous une liste d'interdiction, elle rejoint le tunnel par défaut.

Les configurations gérées exposent le même choix sous des noms de clés différents, et certaines consoles le décrivent comme un mode VPN par application plutôt que comme une liste. Le comportement se réduit toujours à ces deux appels, donc remontez le réglage jusqu'à la liste de paquets au lieu de faire confiance à l'étiquette. Si l'étiquette et la liste ne concordent pas, la liste l'emporte.

Suivez la règle d'UID jusqu'à la table du tunnel

Android donne à chaque application son propre identifiant d'utilisateur Linux, et le service VPN installe des règles de politique qui correspondent à des plages d'UID. Le trafic correspondant est envoyé vers une table de routage dont la route par défaut pointe vers le périphérique tun. Le numéro de table est attribué par instance de VPN, il change donc après une reconnexion ou après la création d'un second profil VPN.

La sortie des règles est la carte. Chaque ligne nomme une table de consultation, et cette table contient la route par défaut qui décide si les paquets correspondants entrent dans le tunnel.

adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>

Exécutez d'abord la troisième commande pour obtenir l'UID, puis trouvez la règle dont la plage le contient. Cette règle pointe vers un numéro de table, et ip route show table <n> avec ce numéro montre si une route par défaut existe via le périphérique tun. Si la table n'a pas de route par défaut, l'application est sélectionnée mais n'a pas de chemin, ce qui est une autre panne.

Ces commandes nécessitent une compilation débogable ou un appareil où adb shell peut lire l'état du réseau. Sur un téléphone de production, le gestionnaire de paquets répond encore, mais l'inspection du routage peut être refusée, donc capturez ce que vous pouvez et traitez le reste comme non vérifié.

Une route revendique un préfixe, pas une application

Builder.addRoute revendique des préfixes de destination pour le tunnel. Un profil qui n'ajoute que 10.0.0.0/8 envoie ce préfixe par le tunnel et laisse chaque autre destination sur le chemin physique. C'est de la tunnelisation divisée ordinaire, et c'est indépendant des applications que les règles ont sélectionnées.

La configuration poussée par le serveur reflète le même modèle. Les poussées de route individuelles ajoutent des préfixes, tandis qu'une directive redirect-gateway remplace la route par défaut et capture tout pour les applications que le tunnel couvre. Retirer cette directive peut réduire un tunnel fonctionnel à un seul sous-réseau sans aucun changement sur l'appareil.

Une route poussée avec une passerelle ou un qualificatif métrique inhabituel peut aussi échouer à s'installer. Préférez la forme simple de préfixe et laissez le serveur gérer le transfert et le NAT.

Lisez l'intersection avant de changer un réglage

Le tunnel transporte l'intersection des processus couverts et des destinations revendiquées. Une application couverte qui demande une adresse hors des préfixes publiés sort par le réseau physique. Un paquet interdit reste dehors même lorsqu'il demande une adresse à l'intérieur de ces préfixes. Aucun des deux cas n'est un bogue ; les deux sont les deux politiques qui font leur travail.

Un VPN par application peut aussi laisser une application associée sans connectivité. Quand on-demand est désactivé et que le tunnel est arrêté, l'application reste liée au VPN par application et n'a pas de repli, ce qui ressemble à une application cassée plutôt qu'à un état de politique. Activer on-demand, ou retirer l'association via la gestion, change cela.

Diagnostiquez un axe à la fois. Confirmez autorisation ou interdiction d'abord, lisez ensuite les règles d'UID et les tables installées, et testez enfin une seconde application vers la même destination. La seconde application sépare la sélection de processus de la sélection de destination en une seule requête.

Notez le résultat sous forme d'application, de destination et de numéro de table. C'est ce triplet que le prochain changement doit préserver.