Le site ne vous bloque qu'avec le VPN activé ? Voici ce qu'il voit

La boutique se charge bien à la maison et affiche un mur de « trafic inhabituel » dès que le tunnel est établi. Un forum refuse de vous connecter, et une page de streaming affirme que vous êtes dans un pays que vous n'avez jamais visité. Rien de tout cela n'exige un logiciel espion. Un site voit l'adresse d'où arrivent vos paquets, et avec un VPN cette adresse appartient à un centre de données plutôt qu'à une ligne domestique. L'essentiel de ce qu'on appelle la détection de VPN commence et finit par ce seul fait, et le reste est une inférence au taux d'erreur prévisible.

Le blocage commence par l'endroit d'où vos paquets semblent venir

Chaque requête porte une adresse source, et le serveur qui la reçoit peut la consulter dans des données publiques : quel réseau l'annonce, si ce réseau est un hébergeur, s'il est apparu dans des listes d'abus et quel pays le registre lui attribue. Rien de tout cela ne vous identifie, et tout cela suffit à vous ranger dans une case.

Regardez votre propre trafic comme le ferait un inconnu. Deux commandes couvrent l'essentiel de la surface, et c'est la seconde que les gens oublient :

curl -sS https://ipinfo.io/json
dig +short TXT o-o.myaddr.l.google.com @ns1.google.com

La première renvoie l'adresse de sortie, son organisation et son pays. La seconde renvoie l'adresse du résolveur qui a atteint le serveur de noms de Google, souvent sur un autre réseau que votre sortie, et c'est l'adresse qu'un site voit s'il journalise les données côté résolveur. Quand ces deux adresses appartiennent à des pays différents, certains sites jugent l'écart suspect, même si rien ne cloche dans votre configuration.

Quand le refus ne commence qu'après l'établissement du tunnel, soupçonnez d'abord l'adresse de sortie. Changez de serveur et réessayez avant de toucher au navigateur. Un blocage qui vous suit sur trois sorties d'un même fournisseur concerne les plages de ce fournisseur ; un blocage qui disparaît sur un autre serveur concerne cette seule adresse.

Le fuseau horaire, la langue et l'horloge ne concordent pas avec l'adresse

Le code de la page peut lire votre fuseau horaire, vos préférences de langue et vos réglages d'écran sans aucune demande d'autorisation. Un navigateur qui annonce l'heure d'Europe centrale alors que la connexion arrive d'un centre de données à Singapour est un signal plus fort que l'adresse seule, et c'est exactement le type d'écart que le scoring antifraude est fait pour remarquer.

Intl.DateTimeFormat().resolvedOptions().timeZone
navigator.language
Intl.DateTimeFormat().resolvedOptions().locale

Ces trois lignes dans la console de développement vous disent ce que votre navigateur livre volontairement. Un client VPN peut changer votre route et rien d'autre, donc le profil que vous portez reste national alors que votre sortie ne l'est pas. La cohérence est ce qui compte ici : un portable réglé sur la même région que la sortie paraît ordinaire, et un portable qui se contredit ne l'est pas.

C'est aussi pourquoi l'échec est intermittent. Beaucoup de sites s'en moquent, quelques-uns le notent, et un site d'adhésion décide que vous êtes un fraudeur. Le client fonctionne correctement dans les trois cas, et c'est pourquoi la réponse habituelle du support, « cela doit venir de votre navigateur », est à la fois agaçante et en partie vraie.

Ce que le code de la page sait vraiment de votre machine

JavaScript n'a aucune API qui énumère les interfaces réseau. Une page ne peut pas demander quelles adresses votre portable possède, donc l'ancienne affirmation selon laquelle un script lit votre adresse LAN est surtout un souvenir de l'époque des plugins, quand les contrôles ActiveX, les applets Java et d'autres codes natifs pouvaient faire exactement cela.

WebRTC est l'exception honnête à « aucune fuite d'adresse locale ». Sa collecte de candidats exposait autrefois les adresses locales à toute page qui le demandait, et le correctif a consisté à remplacer les candidats hôte par des noms mDNS aléatoires. Ce comportement par défaut tient dans les navigateurs actuels, mais c'est une décision du navigateur et non une garantie du protocole, donc une version ancienne ou une configuration durcie qui réactive les candidats locaux peut encore fuir. Mettre à jour le navigateur vous aide ici plus que n'importe quelle extension.

Votre fournisseur voit les noms, pas les contenus

HTTPS protège le contenu d'une page de bout en bout, et l'opérateur du tunnel qui achemine ces octets ne peut pas les lire. L'opérateur peut toujours voir l'adresse que vous avez contactée, et dans la plupart des déploiements le nom du serveur dans la poignée de main, car le nom doit être lisible pour que la connexion soit routée vers le bon site. Encrypted Client Hello existe précisément pour masquer ce champ, et il n'aide que lorsque le client et le site le prennent tous deux en charge.

La résolution de noms est l'autre moitié. Si votre fournisseur fournit aussi le résolveur, il voit chaque nom que vous consultez avant qu'une connexion existe. Si votre appareil utilise un résolveur public via HTTPS, le fournisseur voit une connexion à ce résolveur et rien de plus, tandis que le résolveur lui-même voit la liste.

Une requête HTTP non chiffrée est lisible par l'opérateur pour la même raison qu'elle est lisible par le réseau de l'hôtel : rien en elle n'est chiffré. Un tunnel n'a jamais prétendu le contraire, et il ne répare pas le choix de l'application.

Séparez « c'est un VPN » de « c'est moi »

La détection est bon marché, probabiliste et souvent fausse. Les adresses de sortie partagées sont signalées parce que quelqu'un d'autre en a abusé, les plages d'entreprise sont classées comme hébergement, et les opérateurs mobiles produisent des résultats géographiques qui surprennent tout le monde. L'identification est un autre problème : elle exige un lien persistant, comme un compte auquel vous vous êtes connecté, un cookie, un détail de paiement ou deux observateurs comparant leurs notes.

Décidez contre lequel des deux vous vous battez réellement. Si le but est de lire une page, HTTPS fait déjà ce travail et le tunnel change peu de chose. Si le but est d'empêcher le site de savoir dans quelle ville vous êtes, la sortie et le résolveur sont ce qui compte. Si le but est de rompre le lien avec votre identité réelle, le compte est le point faible, et changer de serveur ne fait rien pour la connexion que vous venez d'utiliser.

Une nouvelle sortie ne vous déconnecte de rien, et elle ne peut pas effacer ce qu'un site a déjà stocké sur le compte que vous avez utilisé. La séquence pratique est donc sans éclat : choisissez une sortie dont le réseau paraît ordinaire, gardez le profil du navigateur cohérent avec elle, mettez le navigateur à jour pour que les fonctions sujettes aux fuites utilisent leurs valeurs par défaut modernes, et acceptez qu'un petit nombre de sites se trompera encore à votre sujet.