Le mode SOCKS de NetGuard couvre TCP, pas tous les protocoles

NetGuard occupe l'interface VPN d'Android pour filtrer le trafic, et il peut remettre les connexions prises en charge à un point de terminaison SOCKS. Ces deux faits sont souvent lus comme « le téléphone est sur un VPN », une conclusion que le mécanisme n'étaye pas. Le filtre voit les paquets ; le proxy ne voit que les connexions qui lui ont réellement été remises. Entre ces deux affirmations se trouve toute la question de la couverture.

La FAQ du projet amont documente à la fois la limitation à un seul service et l'option SOCKS. L'existence de l'option ne prouve pas que chaque paquet autorisé l'utilise, et c'est de cet écart que naissent les questions de couverture.

Deux chemins de transfert dans une seule application

Le côté TCP de l'implémentation contient la gestion des connexions SOCKS, si bien qu'une connexion TCP autorisée peut être négociée avec le proxy et transportée à travers lui. Le côté UDP dispose d'un chemin de socket distinct, et sa gestion d'envoi et de réception ne dépend pas de cette négociation TCP. Un datagramme que le filtre autorise peut donc atteindre le réseau ordinaire sans jamais passer par le proxy. Rien de tout cela n'est un défaut de l'application ; c'est simplement ce que les deux chemins implémentent.

Cette distinction a une conséquence que les gens présentent mal dans les deux sens. Qualifier chaque paquet UDP de fuite ignore les règles de blocage, car un datagramme refusé ne sort jamais. Qualifier tout l'ensemble de VPN ignore le chemin direct autorisé, car une partie du trafic sort bien sans proxy. Ce que vous avez, c'est un appareil filtré avec un proxy partiel, et la description honnête est une matrice, pas une étiquette.

Annoncer UDP n'est pas l'implémenter

Un serveur SOCKS qui revendique la prise en charge d'UDP n'ajoute pas la gestion côté client correspondante à l'application de votre téléphone. Les caractéristiques théoriques du protocole et le comportement de la version installée sont des sujets différents, et seule la seconde décrit votre trafic.

Vérifiez la version et la configuration que vous exécutez réellement, puis testez un flux de datagrammes inoffensif et observez s'il apparaît au proxy. Tout le reste est une inférence tirée d'une liste de fonctionnalités, et les listes de fonctionnalités décrivent des intentions, pas des chemins de code.

DNS est un troisième chemin, pas un détail

La résolution de noms ajoute sa propre branche à la matrice. Un redirecteur DNS local, une requête UDP ordinaire, un nom d'hôte de destination résolu par le proxy lui-même et un résolveur chiffré dans le navigateur sont quatre dispositions distinctes. Elles diffèrent par qui voit la requête et par le chemin réseau qui la transporte, et les mélanger produit un test qui ne prouve rien sur les autres.

Décidez délibérément laquelle vous voulez. Si l'exigence est que les noms se résolvent à travers le tunnel, un simple réglage du navigateur n'y suffira pas, et un proxy qui résout lui-même les noms d'hôtes ne change la réponse que pour les connexions qu'il traite réellement.

Le transport par le proxy n'est pas privé automatiquement

SOCKS simple n'est pas un lien chiffré entre le téléphone et le proxy. Si le point de terminaison est atteint par un autre chemin protégé, nommez ce chemin et sa politique de défaillance, car un repli vers le réseau ouvert transforme une disposition privée en disposition publique sans avertissement. L'authentification du proxy compte aussi : un écouteur ouvert sur un appareil partagé est un service dont personne ne rend compte.

Les dispositions entre profils méritent le même examen. Un VPN de profil professionnel ne protège que le trafic qui emprunte son chemin, et la coexistence d'un pare-feu de profil personnel avec un tunnel professionnel ne prouve pas que la connexion ultérieure du pare-feu atteint ce tunnel. Vérifiez l'accessibilité et l'authentification plutôt que de supposer que les deux profils coopèrent.

Auditez la couverture avec une matrice, pas avec un chargement de page

Pour une évaluation autorisée, choisissez des exemples inoffensifs représentant chaque classe qui vous importe : TCP requis, UDP autorisé et DNS dans les deux familles d'adresses. Pour chacun, notez s'il a été proxifié, bloqué ou envoyé directement. Ce tableau unique est le livrable, et il est bien plus utile qu'une capture d'écran d'une page chargée.

Si l'exigence est que tout le trafic applicatif sélectionné traverse un tunnel distant, choisissez une implémentation qui prend explicitement en charge le filtrage et le tunnellisation combinés. Une composition proxy TCP uniquement reste utile pour des tâches plus étroites, à condition que l'autre trafic soit traité volontairement plutôt qu'oublié.