Marqueur VPN sur l’appareil ou adresse de sortie : lequel prouve quoi ?

L’application du téléphone et le serveur distant partent de faits différents, et aucun ne peut emprunter ceux de l’autre. L’application peut interroger le système d’exploitation sur le réseau qu’elle utilise, tandis que le serveur ne sait que ce qui arrive par la connexion. Faire tourner votre propre point de sortie réécrit le second et laisse le premier intact. Lequel des deux répond à votre question dépend de la question elle-même.

Deux points d’observation, deux types de preuve

La preuve locale décrit l’appareil. Elle couvre l’interface qui porte le trafic, le transport que la plateforme signale et ce que l’application appelante est autorisée à interroger. La preuve distante décrit la connexion : adresse source, protocole, chronologie et tout ce que l’application choisit d’envoyer. Aucun point d’observation n’est un sur-ensemble de l’autre.

Mélanger les deux produit des affirmations qui sonnent exactes et ne peuvent pas être vérifiées. Un marqueur prouve quelque chose sur un objet réseau de l’appareil, pas sur la façon dont un service distant classe la requête.

Avant de discuter de la détection, notez à quel point la question se rapporte. S’agit-il de savoir si une application donnée peut constater qu’un tunnel est actif, ou si un service peut déduire d’où vient la requête ? Ce sont des enquêtes distinctes, et la réponse à l’une ne dit rien de l’autre.

Ce qu’une interface locale de plateforme peut signaler

Android propose un marqueur précis. L’objet NetworkCapabilities peut signaler TRANSPORT_VPN, et hasTransport vérifie si ce transport est présent sur l’objet. L’application obtient l’objet auprès du service de connectivité et le lit, sous réserve de l’autorisation d’état du réseau.

Le résultat est une information locale de la plateforme, non une recherche dans les plages d’adresses d’un fournisseur. Il décrit le réseau que l’application appelante utilise.

Deux limites comptent. Une règle de tunnel divisé qui exclut une application peut donner sur le même téléphone une réponse différente de celle que voit un collègue, car l’application peut être liée ailleurs. Le marqueur existe aussi parce que le système d’exploitation modélise des interfaces VPN, non parce qu’une application particulière le collecte. Qu’une application lise le champ, le transmette ou l’ignore est une propriété de cette application. Son manifeste et sa documentation sont les seules sources fiables pour cette question.

adb shell dumpsys connectivity | grep -i -m5 vpn

Ce qu’un service distant peut voir

Un serveur voit l’adresse source de la connexion, le transport et la chronologie, et il peut enrichir l’adresse avec des données de registre ou de routage. Il peut aussi recevoir tout ce que l’application envoie, y compris la localisation lorsque l’application la demande et que l’utilisateur accepte. Ces canaux sont séparés, et un seul ressemble à une recherche d’adresse.

Une adresse enregistrée chez un hébergeur suggère un tunnel, tandis qu’une adresse enregistrée sur un réseau résidentiel suggère une connexion domestique. Les deux sont des indices statistiques, pas des faits sur l’appareil.

Une adresse résidentielle ne place pas la personne à cette adresse, et une adresse d’hébergement ne nomme ni l’opérateur ni le pays. Un service qui traite l’inférence comme une certitude se trompera parfois sans pouvoir le détecter. Si l’exigence est la fiabilité plutôt qu’une heuristique, les données d’adresse ne peuvent pas la fournir, et une conception qui le dit est plus honnête qu’une qui cache la conjecture.

Pourquoi une sortie auto-hébergée ne change qu’un côté

Faire tourner votre propre point de sortie change l’adresse source qu’observe un service distant, ce qui peut la déplacer hors des plages que ce service associe aux fournisseurs commerciaux. Cela ne change rien au modèle de réseau local, car le tunnel reste un tunnel et le système d’exploitation le signale toujours.

Un côté de la preuve bouge ; l’autre reste fixe. L’écart entre les deux est l’endroit où les attentes se brisent.

Un navigateur est un troisième cas avec ses propres interfaces et restrictions. Le contenu web ne peut pas lire un objet natif de capacités, et traiter une fonction du système d’exploitation mobile comme disponible pour une page web est une erreur de catégorie. Si la question concerne un site web, étudiez ce qu’un site peut réellement obtenir au lieu de translittérer une API de plateforme.

Décidez avec la question que vous posez

Si la question est de savoir si une application donnée peut observer l’état du tunnel, l’interface de plateforme est le bon endroit à examiner, et la réponse se trouve dans le code et les autorisations de cette application. Si la question est ce qu’un service peut déduire, les métadonnées de connexion sont la preuve. Une question juridique ou contractuelle n’est tranchée par ni l’une ni l’autre.

Nommez la question en une phrase avant de collecter quoi que ce soit. Cette phrase décide quel point d’observation compte et empêche l’enquête de dériver vers un autre débat.

Étiquetez chaque observation selon sa source lorsque vous la rapportez, car une affirmation non étiquetée ne peut pas être revue. Un marqueur local et une inférence d’adresse sont tous deux utiles et aucun n’est concluant, c’est pourquoi les fusionner en un seul verdict est une erreur.

Lorsqu’un service rejette une connexion autorisée, utilisez sa voie de réexamen prise en charge au lieu de modifier un réglage local pour masquer un signal. Retirer une observation ne prouve jamais que les autres ont disparu.