Cosa vede ancora il tuo provider quando scarichi torrent tramite una VPN

Percorri le domande in ordine: cosa può osservare la rete di accesso, cosa esce dal tunnel senza di essa, cosa rivela la risoluzione dei nomi e cosa i peer e i tracker apprendono comunque. Ogni risposta è indipendente dalle altre, e una VPN ne affronta pienamente solo la prima. La quarta è dove la maggior parte delle aspettative fallisce in silenzio, perché nessun tunnel rimuove un nome di account.

Inizia decidendo quale osservatore ti preoccupa, perché la risposta cambia con l’osservatore.

Una connessione ne sostituisce molte

Quando il client è davvero dentro il tunnel, la rete di accesso vede un’unica connessione cifrata continua verso un solo indirizzo VPN. Volume, tempi e il fatto che sia in uso una VPN restano visibili; i nomi host dei tracker, gli indirizzi dei peer e i nomi dei file no. È un miglioramento reale, e più ristretto di quanto suggerisca il marketing. L’operatore del tunnel sta nel mezzo e vede più della rete di accesso.

Una dichiarazione di assenza di log descrive la politica di conservazione, non la visibilità tecnica. Sono affermazioni diverse, e solo la prima è qualcosa che un provider può promettere.

La fuga viene dal binding, non dal tunnel

BitTorrent crea un flusso di connessioni TCP e UDP di breve durata verso peer, tracker, nodi DHT e scoperta locale. Vincola il client all’adattatore fisico, oppure riavvialo quando il tunnel è caduto, e il traffico risultante è esattamente ciò che il tunnel esisteva per nascondere. Le regole del firewall sono un controllo più debole di quanto sembri: una regola che corrisponde solo alla rotta predefinita, solo a IPv4 o solo alle nuove connessioni lascia percorsi aperti. Vincolare il client all’interfaccia del tunnel e verificare quel binding è lo schema più solido.

Verifica fermando di proposito il tunnel e osservando se i trasferimenti si fermano. Se continuano, il client non era mai dentro. Ripeti dopo un riavvio del client e dopo il risveglio di un portatile, perché è allora che i binding di solito si perdono.

Il DNS nomina il sito senza toccare il trasferimento

Se le ricerche dei nomi passano ancora dal resolver locale, la query stessa annuncia il sito mentre il trasferimento resta cifrato. Spostare la risoluzione dentro il tunnel, o cifrarla, chiude quella lacuna. Nessuna delle due fa nulla per un client i cui pacchetti escono fuori dal tunnel. Controlla quale resolver è in uso e da quale interfaccia esce la query; i due controlli rispondono a domande diverse.

Un nome che si risolve attraverso il tunnel e un trasferimento che rispetta il binding sono proprietà separate, e ciascuna può fallire da sola.

Lo sciame e il tracker vedono cose diverse

Lo scambio di indirizzi fa parte del protocollo, quindi i peer registrano ciò che vedono. Collegarsi dall’uscita dà loro l’uscita; collegarsi direttamente dà l’indirizzo di casa. DHT e lo scambio di peer diffondono ulteriormente quell’osservazione, e una sessione successiva senza il tunnel può collegare la stessa porta client e versione. Il tracker può saperne ancora di più: una chiave di accesso nell’URL di annuncio identifica l’account indipendentemente da quale uscita siano arrivati i pacchetti.

La cifratura copre ancora un altro asse. HTTPS protegge una richiesta dall’uscita in poi; l’HTTP semplice espone la riga di richiesta a ogni rete lungo il percorso, ed è per questo che un protocollo può essere modellato e l’altro no.

Rispondi alle quattro domande con prove, non con un’icona. L’icona ti dice solo che esiste un tunnel.