Relay di uscita Tor contro server di uscita VPN: cosa sa ciascuno

Entrambi i progetti nascondono il tuo indirizzo dietro un unico IP pubblico, e un sito che stampa l'indirizzo che vede non può distinguerli. La differenza sta in chi apprende cosa lungo il percorso, in quanta parte del traffico è coperta e in quali porte possono funzionare. Un relay di uscita Tor è l'ultimo salto di un circuito di tre relay; un server di uscita VPN termina il tuo tunnel e apre da sé la connessione in uscita. Ecco come decido quale serve a un compito, e cosa verifico prima di supporre che uno si comporti come l'altro.

Due percorsi che finiscono su un indirizzo

Tor costruisce un circuito attraverso una guardia, un relay intermedio e un'uscita, e cifra il carico a strati così che ogni relay ne stacchi solo il proprio. L'uscita stabilisce la normale connessione TCP verso la destinazione, ed è per questo che la destinazione vede l'indirizzo di uscita. Il tuo client non parla mai direttamente con la destinazione, e nemmeno la guardia la vede.

Una VPN è un tunnel verso un solo punto finale. Il server dell'operatore rimuove il tunnel e apre la connessione in uscita, così anche la destinazione vede un solo indirizzo, questa volta quello dell'operatore. Il risultato osservabile è lo stesso; la conoscenza no. Un test che stampa un IP risponde su quale sistema sei e non dice nulla sulla ripartizione di fiducia che in realtà differisce.

Chi finisce per sapere cosa

Il punto finale VPN vede l'indirizzo di origine, la destinazione, il momento e il volume in un solo posto. Quella concentrazione è il progetto: un operatore, una superficie di log, un luogo da citare o da configurare male. Tutto ciò che guadagni viene dalla fiducia in quella parte e dalla politica di uscita del punto finale.

Tor divide quella conoscenza. La guardia conosce il tuo indirizzo ma non la destinazione; l'uscita conosce la destinazione ma non il tuo indirizzo. Un relay non dovrebbe apprendere entrambe. È una proprietà strutturale, non una promessa contro un osservatore globale, un relay che correla i tempi o un punto finale compromesso, quindi trattala come una diversa distribuzione dello stesso rischio e non come un anonimato che non può fallire.

La copertura è una decisione del browser o della rotta

Il browser Tor instrada il proprio traffico e aggiunge protezioni che un client VPN generico non riproduce: resistenza alle impronte, isolamento di prima parte, una dimensione fissa della finestra e un'azione Nuova identità che scarta lo stato della sessione. Le altre applicazioni non usano quel circuito se non sono configurate per farlo, e un'installazione di Tor a livello di sistema è un progetto separato dall'installazione del browser.

Una VPN ha la forma opposta. La copertura segue la tabella di routing, così un profilo WireGuard con AllowedIPs = 0.0.0.0/0 cattura tutto e un elenco di tunnel diviso cattura solo i prefissi che nomina. È proprio in quel meccanismo che vivono anche le fughe: le query DNS, IPv6 e WebRTC possono ciascuna prendere un percorso che la politica di routing non includeva. Verifica dall'interno dell'applicazione che ha fallito, non da una scheda del browser che magari usa un'altra interfaccia.

Politica delle porte, destinazioni bloccate e HTTPS

Un relay di uscita è libero di rifiutare porte in uscita, e la politica predefinita respinge un elenco di porte soggette ad abusi, tra cui la porta SMTP 25. Per questo un client di posta configurato tramite Tor fallisce all'uscita, cosa che sembra un guasto di rete e non lo è. Gli operatori che gestiscono un relay lo impostano esplicitamente:

# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25

Anche le destinazioni bloccano, e bloccano i due sistemi in modo diverso. Gli indirizzi di uscita Tor sono pubblicati, quindi un sito può rifiutare l'intero elenco; i punti finali VPN stanno in intervalli di data center rifiutati con la stessa disinvoltura. Quando una pagina fallisce, separa i tre candidati prima di cambiare qualcosa: politica di uscita o di egresso, una destinazione che rifiuta l'origine o un portale captive che dirotta la prima richiesta.

Nessuno dei due sistemi sostituisce la cifratura del trasporto. Il semplice HTTP è leggibile sia al relay di uscita sia al punto finale VPN, quindi lascia HTTPS attivo e leggi l'avviso sul certificato invece di scartarlo. Due controlli risolvono subito la questione del routing: curl -s https://check.torproject.org/api/ip restituisce IsTor quando la richiesta è passata per un circuito, e curl -s https://ifconfig.me mostra l'indirizzo di uscita che una VPN presenterebbe. Eseguire entrambi ti dice quale percorso usa davvero la shell.

Non usare l'uno come l'altro

L'indirizzo di un relay di uscita non è un profilo VPN. Puntare un client OpenVPN o WireGuard a un relay sulla porta 443 non crea alcun tunnel, perché lì non c'è alcun servizio VPN in ascolto; il relay è un salto nel circuito di qualcun altro. Nell'altra direzione, un punto finale VPN non è un punto d'ingresso per Tor, e le impostazioni dei bridge del browser Tor non sono un posto dove incollare un nome host di una VPN commerciale. Se esegui Tor sopra una VPN, la guardia vede l'indirizzo della VPN invece del tuo, il che cambia la ripartizione senza fondere i due ruoli.

Prima di scegliere, rispondi a quattro domande in ordine: chi gestisce il punto finale e cosa conserva, cosa copre lo strumento su questo dispositivo, quali porte e destinazioni consente la politica di uscita e cosa aggiunge l'applicazione oltre al percorso di rete. Un compito che richiede accesso di rete ordinario per molti programmi vuole una VPN. Un compito che richiede le protezioni a livello di browser e il modello a circuito vuole il browser Tor, tenuto aggiornato. Se la risposta è «entrambi», eseguili in un ordine deliberato e annota quale indirizzo vede ciascuna parte.