Pourquoi le trafic de débogage sans fil ne prouve pas une fuite VPN

Vous avez activé le débogage sans fil, connecté un ordinateur portable, et la session a continué de fonctionner alors que le VPN était actif. Cela ressemble à quelque chose qui aurait glissé hors du tunnel. Presque certainement pas. Une session de débogage et la requête d'une application vers un site web sont des relations réseau différentes, et une seule d'entre elles est censée traverser le tunnel.

J'ai rencontré cette mauvaise lecture deux fois : une fois avec le téléphone et l'ordinateur portable sur le même Wi-Fi, et une fois après un redémarrage où l'appairage avait survécu. Dans les deux cas, le VPN faisait exactement ce pour quoi il était configuré.

Nommez l'observation avant de nommer le bug

Trois événements peuvent précéder une affirmation de fuite, et ils ne sont pas interchangeables. Un outil peut découvrir un service, l'appareil peut approuver une station de travail, ou une session autorisée peut réellement transporter des commandes et des octets. Notez lequel vous avez vu, car chacun prouve moins qu'on ne le suppose.

La découverte est généralement mDNS ou un scan de ports. L'appairage est une décision d'enrôlement prise sur le téléphone, confirmée par un code que l'utilisateur saisit. Une session active signifie que du trafic a circulé entre deux points de terminaison appairés. Rien de tout cela ne décrit où va la requête HTTPS d'une application.

Gardez la destination, l'interface, la famille d'adresses, l'horodatage et le profil utilisateur attachés à l'événement. Sans ces détails, l'observation ne peut être comparée à la politique de réseau local prévue, ni à la version du VPN qui tournait alors.

Pourquoi les deux chemins ne se rencontrent jamais

Le débogage sans fil est une connexion entrante vers l'appareil. adbd écoute sur un port lié à l'interface Wi-Fi, et la station de travail s'y connecte après l'appairage. Le sens compte : votre ordinateur portable atteint le téléphone, pas l'inverse. C'est l'opposé d'une fuite de sortie.

Le trafic internet d'une application sort par l'interface tunnel que VpnService installe, appariée par UID et règles de routage. adbd est un démon système exécuté sous l'utilisateur shell, pas une application dans cet ensemble de routage. Il reste sur la liaison Wi-Fi sous-jacente même lorsque chaque application est épinglée au tunnel.

Le mode verrouillage impose le tunnel aux applications couvertes. Il ne transforme pas une socket en écoute en chemin de sortie.

C'est pourquoi une session ADB fonctionnelle et un coupe-circuit fonctionnel coexistent sans contradiction. Pour prouver une fuite, il faut observer la direction censée être bloquée.

À quoi ressemble réellement un test de sortie

Testez l'application couverte, pas le canal de débogage. Mettez délibérément en place la condition d'échec, puis faites une nouvelle requête et notez ce qui s'est passé.

1. Confirmez que le VPN est le seul chemin : activez le VPN toujours actif avec le blocage des connexions sans VPN.
2. Arrêtez le VPN de la manière prise en charge et confirmez que l'application signale l'absence de connectivité.
3. Émettez une requête inoffensive depuis cette application et notez si elle échoue ou réussit.
4. Répétez avec le débogage sans fil activé, puis désactivé, afin d'isoler la variable.

Une requête bloquée dans ces conditions est une preuve. Une session ADB réussie ne l'est pas, et un seul ping depuis une application de terminal non plus.

Si la requête réussit alors que le verrouillage est actif, capturez l'UID de l'application et son autorisation VPN, le réseau actif et la version du client. Cette combinaison est une véritable découverte.

L'appairage survit à la session

L'appairage est un état persistant, pas une poignée de main que l'on oublie après le test par câble. La documentation de débogage d'Android décrit le flux de travail sans fil et note que la relation dure jusqu'à ce qu'elle soit explicitement oubliée ou que les autorisations soient révoquées.

Vérifiez ce qui est encore autorisé avant de blâmer le tunnel. Ouvrez Débogage sans fil, regardez les Appareils associés et oubliez tout ce que vous ne reconnaissez plus. Exécutez adb devices depuis la station de travail pour voir quelles entrées répondent encore, et adb disconnect pour en supprimer une obsolète. Désactiver le débogage sans fil ferme complètement le port d'écoute.

Sur un réseau partagé ou non fiable, laissez-le désactivé. Une autorisation persistante sur un réseau que vous ne contrôlez pas est un problème plus grave qu'un contournement TUN hypothétique.

Avant de signaler ce bug

Un rapport utile nomme la frontière exacte qui a échoué. Indiquez le modèle de l'appareil et la version d'Android, le client VPN et sa version, si le verrouillage était activé, le paquet de l'application et l'UID, ainsi que le réseau sur lequel était le téléphone. Ajoutez la commande ou la requête qui a produit l'observation, ainsi que l'heure à laquelle elle s'est produite. Sans cela, personne ne peut reproduire la frontière que vous dites cassée.

Ne désactivez pas l'application des règles et n'exposez pas le débogage sur un réseau non fiable pour rendre le test plus spectaculaire. Cela modifie le système que vous mesurez et laisse des preuves que personne ne peut reproduire.

Si votre seule preuve est que l'ADB s'est connecté alors que le VPN était actif, vous avez mesuré le mauvais chemin. Relancez d'abord le test au niveau de l'application ; la réponse arrive généralement là.