VPN dentro Tor, Tor dentro VPN: perché la catena si spezza
Quando una VPN, Tor e un proxy vengono impilati, l'ordine decide cosa viene risolto e cosa viene trasportato. Trova il primo confine rotto prima di cambiare tutti e tre.
Impilare una VPN, Tor e un proxy applicativo sembra moltiplicare la privacy, e in realtà moltiplica il numero di punti in cui una connessione può morire. Il risultato abituale è un browser che gira mentre i tre strumenti si dichiarano sani. Cambiare tutte e tre le impostazioni insieme elimina allora l'unico indizio su quale stia mentendo.
Disegna prima il percorso previsto, in ordine, indicando quale programma apre ogni connessione e quale nome viene risolto a ogni passo.
I livelli non si sommano, interagiscono
Una VPN prima di Tor significa che la connessione in ingresso del client Tor viaggia dentro il tunnel. Una VPN trasportata attraverso Tor significa che l'endpoint del client VPN stesso deve essere raggiungibile via Tor, che è un requisito molto diverso. Il proxy del browser aggiunge un altro salto che il sistema operativo non conosce. Tre disposizioni, tre elenchi di dipendenze separati.
Ogni disposizione cambia ciò che può essere risolto, ciò che può essere trasportato e chi vede il primo pacchetto. Solo una di esse può essere la configurazione che intendevi.
Aggiungi anche il percorso diretto allo schema. Una rotta di riserva, un'eccezione per tunnel diviso o un aggiramento del proxy possono far caricare una pagina saltando in silenzio la catena che volevi provare, e quel successo inganna più del fallimento.
L'ordine decide cosa può essere trasportato
Tor trasporta flussi TCP attraverso la sua interfaccia SOCKS, e un client che chiede al proxy di risolvere il nome host mantiene la ricerca dentro il circuito. UDP non viaggia così nelle configurazioni ordinarie, per questo un tunnel WireGuard non può essere annidato dentro Tor senza un relè TCP aggiuntivo nel mezzo.
OpenVPN può essere forzato su TCP, quindi quella disposizione è almeno descrivibile. È anche più lenta e più fragile, e il modo in cui fallisce quando si rompe sembra identico a una porta bloccata. Aspettati di passare più tempo a distinguere i due casi che a riparare uno dei due.
La risoluzione è l'altra metà. Con --socks5-hostname il proxy risolve la destinazione, mentre il --socks5 semplice interroga prima il resolver locale e fa trapelare il nome fuori dal circuito. Proprio quel singolo flag decide se la ricerca del nome appartiene alla catena o al tuo fornitore di accesso.
| Order | What must resolve the endpoint | What usually breaks |
|---|---|---|
| VPN, then Tor | The tunnel's resolver | Entry guards blocked by the VPN provider's filters |
| Tor, then VPN | The SOCKS proxy, remotely | UDP transports, which Tor does not carry |
| App proxy on top | The application itself | Proxy bypass rules and cached connections |
Individuare il primo confine rotto
Prova le fasi nell'ordine in cui viaggiano i pacchetti, con richieste innocue, e fermati alla prima che fallisce. Annota quale comando è stato eseguito per primo, perché l'ordine fa parte della prova. Due comandi separano un circuito morto da un'uscita morta:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Il primo riporta se una richiesta si completa attraverso il proxy SOCKS, e il secondo mostra l'indirizzo che la rete presenta in questo momento. Se il primo fallisce e il secondo riesce, il problema è al client Tor o prima. Se entrambi riescono e il browser continua a fallire, l'applicazione usa un percorso diverso da quello della shell.
Anche una pagina di IP pubblico descrive solo l'ultima uscita visibile. Non può dirti quante battute l'hanno preceduta, quindi abbinala all'uscita di stato supportata di ogni strumento invece di trattare un singolo numero come uno schema.
Quando smettere di aggiungere livelli
Se non sai dire in una frase cosa aggiunge un livello, toglilo. Una catena il cui scopo non è chiaro è una catena che nessuno può diagnosticare alle tre di notte, e il guadagno di privacy di un salto non spiegato è di solito inferiore alla disponibilità che perdi.
Se un livello si merita davvero il suo posto, provalo da solo prima, poi aggiungi il successivo e conferma di nuovo il percorso con gli stessi due comandi. Ripristina la catena completa prima dell'uso ordinario e lascia attivi la convalida TLS e l'autenticazione; un avviso di certificato accettato per far caricare una pagina è un aggiramento del routing, non una riparazione. Annota l'ordine su cui ti sei stabilizzato finché è fresco.
Scrivi quell'ordine, incluso il resolver che risponde a ogni fase. Una catena funzionante che sai descrivere sopravvive al prossimo aggiornamento, mentre una catena funzionante messa insieme per tentativi scompare con esso. Aggiungi la data e le versioni, così un guasto successivo può essere confrontato con uno stato noto come buono invece di essere discusso a memoria. Dieci righe in un file di testo risparmiano una serata di supposizioni.