Il sito ti blocca solo con la VPN attiva? Ecco cosa vede

Il negozio si carica bene a casa e mostra un muro di «traffico insolito» nel momento in cui il tunnel si alza. Un forum rifiuta di farti accedere, e una pagina di streaming insiste che sei in un paese che non hai mai visitato. Niente di tutto ciò richiede software spia. Un sito vede l'indirizzo da cui arrivano i tuoi pacchetti, e con una VPN quell'indirizzo appartiene a un data centre invece che a una linea domestica. La maggior parte di ciò che viene chiamato rilevamento VPN inizia e finisce con quel singolo fatto, e il resto è inferenza con un tasso di errore prevedibile.

Il blocco inizia da dove sembra che arrivino i tuoi pacchetti

Ogni richiesta porta un indirizzo di origine, e il server che la riceve può cercarlo in dati pubblici: quale rete lo annuncia, se quella rete è un provider di hosting, se è comparso in liste di abuso e quale paese gli assegna il registro. Niente di tutto ciò ti identifica, e tutto insieme basta a incasellarti.

Guarda il tuo traffico come farebbe un estraneo. Due comandi coprono gran parte della superficie, e il secondo è quello che la gente dimentica:

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

Il primo restituisce l'indirizzo di uscita, la sua organizzazione e il suo paese. Il secondo restituisce l'indirizzo del resolver che ha raggiunto il server dei nomi di Google, spesso su una rete diversa dalla tua uscita, ed è l'indirizzo che un sito vede se registra dati lato resolver. Quando questi due appartengono a paesi diversi, alcuni siti considerano la discrepanza sospetta anche se non c'è nulla di sbagliato nella tua configurazione.

Quando il rifiuto inizia solo dopo che il tunnel è attivo, sospetta prima di tutto l'indirizzo di uscita. Cambia server e riprova prima di toccare il browser. Un blocco che ti segue su tre uscite dello stesso provider riguarda gli intervalli del provider; un blocco che sparisce su un altro server riguarda quel singolo indirizzo.

Fuso orario, lingua e orologio non concordano con l'indirizzo

Il codice della pagina può leggere il tuo fuso orario, le tue preferenze linguistiche e le impostazioni dello schermo senza alcuna richiesta di permesso. Un browser che dichiara l'ora dell'Europa centrale mentre la connessione arriva da un data centre a Singapore è un segnale più forte del solo indirizzo, ed è proprio il tipo di discrepanza che il punteggio antifrode è costruito per notare.

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

Quelle tre righe nella console per sviluppatori ti dicono cosa offre volontariamente il tuo browser. Un client VPN può cambiare la tua rotta e nient'altro, quindi il profilo che porti resta nazionale mentre la tua uscita non lo è. La coerenza è ciò che conta qui: un portatile impostato sulla stessa regione dell'uscita sembra normale, e uno che contraddice se stesso no.

È anche per questo che il fallimento è intermittente. Molti siti non se ne curano, alcuni lo valutano, e un sito a iscrizione decide che sei un truffatore. Il client funziona correttamente in tutti e tre i casi, ed è per questo che la solita risposta dell'assistenza, «dev'essere il tuo browser», è insieme fastidiosa e in parte vera.

Cosa sa davvero il codice della pagina della tua macchina

JavaScript non ha alcuna API che elenchi le interfacce di rete. Una pagina non può chiedere quali indirizzi abbia il tuo portatile, quindi la vecchia affermazione che uno script legga il tuo indirizzo LAN è soprattutto un ricordo dell'era dei plugin, quando i controlli ActiveX, le applet Java e altro codice nativo potevano fare esattamente questo.

WebRTC è l'eccezione onesta a «nessuna fuga di indirizzi locali». La raccolta dei suoi candidati un tempo esponeva indirizzi locali a ogni pagina che lo chiedeva, e la correzione è stata sostituire i candidati host con nomi mDNS casuali. Quel valore predefinito vale nei browser attuali, ma è una decisione del browser e non una garanzia del protocollo, quindi una versione obsoleta o una configurazione irrigidita che riattiva i candidati locali può ancora perdere dati. Aggiornare il browser ti aiuta qui più di qualsiasi estensione.

Il tuo provider vede i nomi, non i contenuti

HTTPS protegge il contenuto di una pagina da un capo all'altro, e l'operatore del tunnel che inoltra quei byte non può leggerli. L'operatore può comunque vedere a quale indirizzo hai contattato, e nella maggior parte delle distribuzioni il nome del server nello handshake, perché il nome deve essere leggibile perché la connessione sia instradata al sito giusto. Encrypted Client Hello esiste proprio per nascondere quel campo, e aiuta solo quando sia il client sia il sito lo supportano.

La risoluzione dei nomi è l'altra metà. Se il tuo provider fornisce anche il resolver, vede ogni nome che cerchi prima che esista una connessione. Se il tuo dispositivo usa un resolver pubblico tramite HTTPS, il provider vede una connessione a quel resolver e nient'altro, mentre il resolver stesso vede la lista.

Una richiesta HTTP non cifrata è leggibile dall'operatore per lo stesso motivo per cui è leggibile dalla rete dell'hotel: nulla al suo interno è cifrato. Un tunnel non ha mai affermato il contrario, e non ripara la scelta dell'applicazione.

Separa «questa è una VPN» da «questo sono io»

Il rilevamento è economico, probabilistico e spesso sbagliato. Gli indirizzi di uscita condivisi vengono segnalati perché qualcun altro ne ha abusato, gli intervalli aziendali vengono classificati come hosting, e gli operatori mobili producono risultati geografici che sorprendono tutti. L'identificazione è un altro problema: richiede un legame persistente come un account a cui hai fatto accesso, un cookie, un dettaglio di pagamento o due osservatori che confrontano appunti.

Decidi contro quale dei due stai davvero combattendo. Se l'obiettivo è leggere una pagina, HTTPS fa già quel lavoro e il tunnel cambia poco. Se l'obiettivo è impedire al sito di sapere in quale città sei, contano l'uscita e il resolver. Se l'obiettivo è spezzare il legame con la tua identità reale, il punto debole è l'account, e cambiare server non fa nulla per l'accesso che hai appena usato.

Una nuova uscita non ti disconnette da nulla, e non può cancellare ciò che un sito ha già memorizzato sull'account che hai usato. La sequenza pratica è quindi poco appariscente: scegli un'uscita la cui rete sembri normale, mantieni il profilo del browser coerente con essa, aggiorna il browser affinché le funzioni soggette a fughe usino i loro valori predefiniti moderni, e accetta che un piccolo numero di siti farà comunque supposizioni sbagliate su di te.