Tor passa per la VPN? Cosa cambia il tunnel diviso
Un'icona VPN connessa e un processo Tor in esecuzione non dimostrano che la connessione in ingresso di Tor abbia usato il tunnel. Controlla la regola di divisione, poi il percorso di guasto.
Ecco la convinzione che vale la pena mettere alla prova: un badge connesso significa che il traffico di Tor è passato prima per la VPN. L'inferenza fallisce più spesso di quanto dovrebbe, e fallisce in silenzio. Un selettore di tunnel diviso può lasciare il processo Tor fuori dal tunnel mentre il dispositivo resta connesso, e le due osservazioni sono vere contemporaneamente. L'icona segnala un'interfaccia; il percorso seguito dai tuoi pacchetti è una questione separata. Rispondi con l'instradamento e il selettore, non con il badge.
Cosa dimostra un badge connesso, e cosa no
Una VPN connessa significa che un'interfaccia è attiva e che esiste un tunnel verso il peer. La connessione in ingresso di Tor è un altro flusso, creato da un altro processo, e se entra in quel tunnel dipende dal selettore e dalla tabella di instradamento applicati. Escludi il processo e la VPN si connette comunque, Tor costruisce comunque un circuito, e l'ordine che volevi non si è verificato. Le due osservazioni rispondono a domande diverse, perciò nessuna delle due da sola risolve l'ordine.
Quel divario non è un difetto di nessuno dei due strumenti. È esattamente lo scopo di una regola di esclusione, e la regola è stata probabilmente scritta per un motivo che qualcuno ricorda ancora.
Quale selettore applica il client a una connessione
A decidere il percorso è il selettore che il client applica a ogni connessione: un nome di processo, un prefisso di destinazione o una voce di route, a seconda del client. Una scorciatoia sul desktop non corrisponde a nessuno di essi, perché è un lanciatore, non un'unità di policy. Leggi l'insieme di regole del client e nomina l'unità che verifica davvero prima di ragionare su Tor. Se il client seleziona per destinazione, la domanda diventa quali prefissi stanno dentro il tunnel, non quale programma è in esecuzione.
Una regola basata sulla destinazione che porta solo prefissi di ufficio privato è una forma comune, e lascia le connessioni in ingresso ordinarie di Tor dirette per progetto. È la politica che funziona come configurata, e non è l'ordine VPN-prima-di-Tor, per quanto sano sembri il badge. Scrivi il selettore e i prefissi esclusi sulla stessa riga dei tuoi appunti, perché quella coppia è la regola.
Cosa succede a Tor quando il tunnel cade
Ora togli il tunnel e guarda cosa fa Tor, perché una politica che regge solo finché la rete è sana non è quella che hai descritto. Il client può rifiutare il traffico diretto mentre è giù, permetterlo in silenzio, oppure riconnettersi e riapplicare la regola un attimo dopo. Una disconnessione manuale e un crash sono eventi diversi, e il crash è quello che nessuno ha provato. Testa con traffico innocuo e annota quale dei tre esiti hai effettivamente osservato.
Leggi anche il comportamento documentato del client, ma tratta la documentazione come un'ipotesi finché il tuo test non le dà ragione. I fornitori descrivono il valore predefinito; il tuo profilo decide l'eccezione.
Perché l'indirizzo di uscita non può rispondere alla domanda di ingresso
Un sito raggiunto tramite Tor riporta l'indirizzo del relè di uscita, il che ti dice da dove è emerso il circuito e nulla su come il primo salto ha lasciato il tuo dispositivo. Le persone citano quell'indirizzo come prova dell'ordine VPN-prima, e non può reggere quel peso. La domanda di ingresso è locale: quale interfaccia ha portato la connessione al primo relè e quale indirizzo sorgente il peer VPN avrebbe visto. Rispondi con una ricerca di route o una cattura di pacchetti sul dispositivo, non con un sito web.
Due percorsi diversi possono produrre lo stesso paese di uscita, quindi un risultato corrispondente dimostra ancora meno di quanto sembri. Confronta le interfacce, non la geografia.
Applicazioni che non hanno mai ereditato le impostazioni del browser
Un visualizzatore di documenti, un client di sincronizzazione e un gestore di pacchetti creano ciascuno le proprie connessioni, e nessuno eredita le impostazioni proxy del browser. Ognuno segue il selettore del client, la propria configurazione o il proxy di sistema, e la combinazione è raramente messa per iscritto. È così che cresce un elenco di eccezioni: un'applicazione alla volta, ogni aggiunta ragionevole, finché nessuno sa più dire cosa copre l'elenco. Tieni invece uno schema breve per applicazione, che nomini il selettore, il percorso e il comportamento in caso di guasto.
Se lo strato VPN aggiuntivo non serve a nessuno scopo che tu possa enunciare, rimuovere lo strato è più facile da verificare che mantenere un lungo elenco di eccezioni. Nel frattempo, la nota del Progetto Tor sulle VPN affronta la stessa questione di ordine dall'altro lato. Meno parti mobili significa meno ipotesi da ritestare dopo il prossimo aggiornamento del client.