El lloc només et bloqueja amb la VPN activada? Això és el que veu

La botiga es carrega bé a casa i mostra una paret de «trànsit inusual» en el moment que el túnel s'aixeca. Un fòrum et refusa l'entrada, i una pàgina d'streaming insisteix que ets en un país que no has visitat mai. Res d'això no requereix programari espia. Un lloc veu l'adreça d'on arriben els teus paquets, i amb una VPN aquesta adreça pertany a un centre de dades i no a una línia domèstica. La major part del que s'anomena detecció de VPN comença i acaba en aquest únic fet, i la resta és inferència amb una taxa d'error previsible.

El bloqueig comença per on sembla que venen els teus paquets

Cada sol·licitud porta una adreça d'origen, i el servidor que la rep la pot consultar en dades públiques: quina xarxa l'anuncia, si aquesta xarxa és un proveïdor d'allotjament, si ha aparegut en llistes d'abús i quin país li assigna el registre. Res d'això no t'identifica, i tot plegat n'hi ha prou per encasellar-te.

Mira el teu propi trànsit com ho faria un desconegut. Dues ordres cobreixen la major part de la superfície, i la segona és la que la gent oblida:

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

La primera retorna l'adreça de sortida, la seva organització i el seu país. La segona retorna l'adreça del resolutor que ha arribat al servidor de noms de Google, que sovint és una xarxa diferent de la teva sortida i és l'adreça que veu un lloc si registra dades del costat del resolutor. Quan aquestes dues pertanyen a països diferents, alguns llocs tracten la discrepància com a sospitosa encara que la teva configuració no tingui res de dolent.

Quan el refús comença només després que el túnel s'aixequi, sospita de l'adreça de sortida abans que res. Canvia de servidor i torna-ho a provar abans de tocar el navegador. Un bloqueig que et segueix per tres sortides del mateix proveïdor té a veure amb els rangs del proveïdor; un bloqueig que desapareix en un altre servidor té a veure amb aquella única adreça.

La zona horària, la llengua i el rellotge no concorden amb l'adreça

El codi de la pàgina pot llegir la teva zona horària, les teves preferències de llengua i la configuració de pantalla sense cap petició de permís. Un navegador que informa de l'hora d'Europa Central mentre la connexió arriba d'un centre de dades de Singapur és un senyal més fort que l'adreça sola, i és el tipus de discrepància que la puntuació de frau està feta per notar.

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

Aquestes tres línies a la consola del desenvolupador et diuen què ofereix voluntàriament el teu navegador. Un client VPN pot canviar la teva ruta i res més, així que el perfil que portes es queda domèstic mentre que la teva sortida no ho és. La coherència és el que importa aquí: un portàtil configurat a la mateixa regió que la sortida sembla normal, i un portàtil que es contradiu a si mateix no.

També és per això que la fallada és intermitent. Molts llocs no hi fan cas, uns quants ho puntuen, i un lloc de subscripció decideix que ets un estafador. El client funciona correctament en els tres casos, i per això la resposta habitual del suport, «deu ser el teu navegador», és alhora molesta i en part certa.

Què sap realment el codi de la pàgina sobre la teva màquina

JavaScript no té cap API que enumeri interfícies de xarxa. Una pàgina no pot preguntar quines adreces té el teu portàtil, així que l'antiga afirmació que un script llegeix la teva adreça LAN és sobretot un record de l'època dels connectors, quan els controls ActiveX, els applets Java i altre codi natiu podien fer exactament això.

WebRTC és l'excepció honesta a «cap fuita d'adreces locals». La seva recollida de candidats exposava abans adreces locals a qualsevol pàgina que ho demanés, i la solució va ser substituir els candidats d'amfitrió per noms mDNS aleatoris. Aquest valor per defecte es manté en els navegadors actuals, però és una decisió del navegador i no una garantia del protocol, així que una versió antiquada o una configuració endurida que torni a habilitar els candidats locals encara pot filtrar. Actualitzar el navegador t'ajuda aquí més que qualsevol extensió.

El teu proveïdor veu els noms, no els continguts

HTTPS protegeix el contingut d'una pàgina d'extrem a extrem, i l'operador del túnel que reenvia aquests bytes no els pot llegir. L'operador encara pot veure a quina adreça has contactat, i en la majoria de desplegaments el nom del servidor a l'handshake, perquè el nom ha de ser llegible perquè la connexió es dirigeixi al lloc correcte. Encrypted Client Hello existeix precisament per amagar aquest camp, i només ajuda quan tant el client com el lloc el suporten.

La resolució de noms és l'altra meitat. Si el teu proveïdor també forneix el resolutor, veu cada nom que consultes abans que existeixi cap connexió. Si el teu dispositiu fa servir un resolutor públic per HTTPS, el proveïdor veu una connexió a aquest resolutor i res més, mentre que el resolutor mateix veu la llista.

Una sol·licitud HTTP sense xifrar és llegible per a l'operador pel mateix motiu pel qual és llegible per a la xarxa de l'hotel: res del seu interior no està xifrat. El túnel mai no ha afirmat el contrari, i no arregla l'elecció de l'aplicació.

Separa «això és una VPN» de «això sóc jo»

La detecció és barata, probabilística i sovint errònia. Les adreces de sortida compartides es marquen perquè algú altre n'ha abusat, els rangs corporatius es classifiquen com a allotjament, i els operadors mòbils produeixen resultats geogràfics que sorprenen tothom. La identificació és un problema diferent: necessita un vincle persistent com un compte amb què has iniciat sessió, una galeta, una dada de pagament o dos observadors que comparin notes.

Decideix contra quin dels dos lluita realment. Si l'objectiu és llegir una pàgina, HTTPS ja fa aquesta feina i el túnel canvia poc. Si l'objectiu és evitar que el lloc sàpiga en quina ciutat ets, la sortida i el resolutor són el que importa. Si l'objectiu és trencar el vincle amb la teva identitat real, el compte és el punt feble, i canviar de servidor no fa res per l'inici de sessió que acabes d'usar.

Una sortida nova no et desconnecta de res, i no pot esborrar el que un lloc ja ha desat sobre el compte que vas fer servir. La seqüència pràctica és, doncs, poc espectacular: tria una sortida la xarxa de la qual sembli normal, mantingues el perfil del navegador coherent amb ella, actualitza el navegador perquè les funcions propenses a fuites usin els seus valors moderns per defecte, i accepta que un petit nombre de llocs encara s'equivocaran sobre tu.