Votre serveur voit la sortie du VPN, pas le visiteur

Un visiteur se connecte via un VPN commercial et votre application enregistre l’adresse de sortie. Ce n’est pas une identité cachée : c’est la seule adresse source dont dispose la connexion TCP. Tout le reste, ce que les gens appellent la détection, est une déduction posée sur ce seul fait.

Ce qu’une requête transporte réellement

L’application voit l’adresse et le port source de la connexion, la poignée de main qu’elle a terminée et les octets que le client a choisi d’envoyer. Avec un tunnel complet, cette source est la sortie, partagée par tous ceux qui l’utilisent. Avec un tunnel scindé, les requêtes peuvent arriver du tunnel ou de la connexion locale selon la destination. Si le client et le serveur sont tous deux à l’intérieur du même VPN, la source est l’adresse interne du tunnel du client, qui désigne un point d’extrémité plutôt qu’un lieu.

Aucun champ d’une requête ordinaire ne porte l’adresse que le client avait avant le tunnel. Un en-tête de transfert est une affirmation du client ou d’un proxy, et il peut être omis ou falsifié.

La détection est une classification, et une classification est une supposition

Les méthodes pratiques sont des listes de plages connues de VPN et d’hébergement, une latence qui ne concorde pas avec une région déclarée, des formes de traceroute et le comportement du compte. Chacune produit une probabilité. Un VPN d’entreprise peut se trouver sur des adresses qui semblent résidentielles, un proxy résidentiel peut ressembler à une ligne domestique, et le NAT d’un opérateur peut ressembler à une plage d’hébergement.

Bloquer une sortie partagée bloque chaque utilisateur sans rapport derrière elle, ce qui transforme une décision de détection en panne collatérale. Un score de confiance n’est pas une identité et ne devrait jamais être la seule entrée d’une décision de bannissement ou de remboursement.

Si le VPN vous appartient, vous disposez d’un signal fiable qui n’a rien à voir avec la détection : attribuez un pool dédié et comparez-y la source observée. Cela fonctionne parce que vous contrôlez les deux extrémités et pouvez documenter le pool. Mais cela ne se généralise pas aux visiteurs que vous ne gérez pas, et cela cesse d’être fiable dès que le pool est partagé avec d’autres services.

Preuves locales contre preuve côté serveur

Sur la machine elle-même, un tunnel est visible : un adaptateur virtuel, une route par défaut qui pointe vers un périphérique de tunnel, un résolveur qui a changé. Un code qui s’y exécute peut énumérer les interfaces et chercher PPP, TAP ou un pilote de fournisseur.

Une page web ne peut rien lire de tout cela. Le contournement courant charge une ressource servie uniquement depuis le réseau interne et considère la réussite comme une preuve d’usage du tunnel. Il teste en réalité l’accessibilité : un tunnel scindé, un fichier en cache obsolète ou un proxy d’interception donnent le même résultat dans les deux états. Les preuves locales restent locales.

Choisissez des contrôles d’accès qui survivent à l’ambiguïté

Fondez le contrôle d’accès sur une identité vérifiée, la santé de l’appareil et l’autorisation par ressource. Ces prédicats décrivent qui demande et à quoi il peut accéder, et ils restent pertinents qu’un tunnel soit en jeu ou non. La question de savoir si une requête est arrivée via un VPN est un signal faible qui produit à la fois de fausses acceptations et des blocages collatéraux. Gardez la preuve et la décision dans des champs séparés, afin qu’un blocage contesté ait de quoi être examiné.

La géolocalisation par IP est une entrée parmi plusieurs, et les services de localisation du navigateur peuvent utiliser le Wi-Fi ou le GPS qui ne suivent jamais le tunnel. Une carte qui montre encore la ville du visiteur est une preuve sur les services de localisation, pas la preuve que le tunnel a échoué.

Notez quel signal a guidé chaque décision. Lorsqu’un client conteste un blocage, cet enregistrement fait la différence entre un examen et une dispute.