Dove va il DNS quando combini Tor e una VPN

Sono in esecuzione due strumenti per la privacy, una pagina non si carica e un test del resolver dice che qualcosa fuori dal browser ha ricevuto un nome. Prima che diventi un rapporto di fuga, dai un nome allo scambio da cui proviene. Una configurazione Tor più VPN contiene almeno tre diverse ricerche di nomi con tre diversi proprietari, e percorrerle nell’ordine in cui avvengono è il modo più rapido per vedere quale si comporta male.

Dai un nome a ogni scambio prima di parlare di fuga

Il primo scambio risolve l’endpoint della VPN stesso, e avviene prima che esista qualsiasi protezione. Il secondo risolve una destinazione per il browser Tor, che può consegnare il nome al proxy invece di risolverlo localmente. Il terzo copre tutto il resto sulla macchina, comprese le verifiche degli aggiornamenti, i client di posta e le richieste di servizio del sistema operativo stesso. Solo il primo può avvenire senza che gli altri due siano coinvolti.

Ognuno può seguire un percorso diverso, e un singolo test nel browser osserva solo la propria richiesta. Prendere un risultato come stato di tutti e tre è dove inizia la maggior parte della confusione.

Annota quali nomi appartengono a quale livello prima di cambiare qualcosa. I nomi organizzativi privati, una destinazione pubblica e l’endpoint del tunnel stesso non hanno lo stesso requisito, e una politica che li tratta come un’unica categoria romperà qualcosa.

La richiesta di avvio avviene prima del tunnel

Un client configurato con un nome host deve risolvere quel nome per aprire il tunnel, e in quel momento non esiste alcun tunnel che porti la richiesta. Risponde qualunque resolver il sistema operativo offra sulla rete attuale, che può essere un portale captive, un resolver d’albergo o uno pubblico. Non è una fuga nel tunnel, perché non c’è ancora un tunnel.

Cambiare l’impostazione DNS sicuro del browser non tocca nemmeno questa richiesta, dato che appartiene a un servizio che gira fuori dal browser e parte prima che si apra qualsiasi pagina. Se il nome dell’endpoint non si risolve, nessuna politica dentro il tunnel aiuterà, perché il guasto avviene una fase prima di tutto ciò che la configurazione descrive.

Questo è l’unico punto in cui usare un indirizzo letterale per l’endpoint, se il provider lo supporta, rimuove una dipendenza invece di aggiungerne una. Rimuove anche la capacità di seguire un provider che ruota gli indirizzi, quindi lo scambio è reale e va deciso anziché scoperto.

Il browser e il resto della macchina differiscono

L’interfaccia SOCKS di Tor consente di passare un nome host di destinazione al proxy, il che significa che è l’estremità remota a eseguire la risoluzione e la macchina locale non chiede mai. Un’applicazione generica che supporta un proxy può risolvere il nome localmente prima e poi connettersi all’indirizzo ottenuto, il che produce una richiesta locale per una destinazione che l’utente credeva proxata. Le due applicazioni possono quindi filtrare in punti diversi pur condividendo un’unica impostazione del proxy. Nulla in un indirizzo proxy condiviso ti dice quale dei due comportamenti è in uso.

I browser aggiungono un altro livello quando il DNS sicuro è attivo, perché il browser può scegliere il proprio provider e aggirare del tutto il resolver di sistema. Il client del tunnel, nel frattempo, può spingere un resolver attraverso il tunnel per l’intera macchina. Queste due impostazioni possono essere entrambe corrette e descrivere comunque comportamenti diversi per programmi diversi.

Controlla il programma che ha fatto la richiesta invece di estrapolare da una pagina di test. La distinzione tra una richiesta trasportata dentro il tunnel e una che non ha mai raggiunto Tor è esattamente la distinzione che un solo indirizzo di resolver non può mostrare.

Controlla ogni programma, poi confronta con l’intenzione

Esegui le osservazioni separatamente: cosa userebbe il sistema, per cosa è configurato il browser e se la connessione SOCKS porta un nome o un indirizzo. Quest’ultimo è la differenza tra risoluzione remota e locale, e specifica delle estensioni SOCKS descrive come un nome host viene passato invece di essere risolto prima.

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

Poi confronta ciò che hai osservato con ciò che intendevi. Un nome pubblico risolto attraverso il tunnel da un resolver che hai scelto non è la stessa constatazione di un nome privato consegnato a un resolver pubblico durante un ripiego, e di solito solo il secondo richiede un intervento. Il primo è una configurazione che funziona come progettato, anche se in un rapporto sembra insolita.

Registra le eccezioni che accetti, compresa la richiesta di avvio che non può essere protetta. Un’eccezione scritta è una decisione di progettazione, mentre la stessa eccezione scoperta più tardi sembra un difetto. Chi la troverà la tratterà come tale, e passerai la riunione a spiegare perché non lo è.