Il DNS della tua VPN viene davvero usato? Cattura la porta 53 e guarda

Chiedi alla maggior parte delle persone cosa fa un client VPN con il DNS e diranno che imposta il resolver, così le query viaggiano nel tunnel. La spinta è reale; l’ipotesi che diventi una query no. Tra un’opzione spinta e un pacchetto sul filo stanno tre fasi, e ciascuna fallisce in modo indipendente in maniere che sembrano tutte un server DNS guasto. Per questo una pagina di test delle perdite e un browser funzionante possono non essere d’accordo sulla stessa macchina nello stesso momento.

Un’opzione spinta non è una query

La prima fase è che il server offra impostazioni, per esempio un’opzione DNS spinta che nomina un resolver dentro il tunnel. La seconda fase è che il client applichi quelle impostazioni a un’interfaccia. La terza fase è che un’applicazione invii davvero una query a quell’indirizzo. Un guasto alla seconda fase lascia l’opzione visibile nel registro di connessione mentre l’elenco dei resolver resta invariato, e un guasto alla terza fase lascia un elenco di resolver perfettamente corretto inutilizzato.

La maggior parte della diagnostica fonde quelle tre in una e incolpa il server VPN, che di solito è l’unica parte in grado di dimostrare di aver fatto la sua. Leggi invece lo stato reale del resolver del client, poi osserva una query uscire. Quelle due osservazioni separano la configurazione dall’instradamento e dalla politica, e costano circa cinque minuti. Conserva le catture, perché l’ingegnere successivo vuole il prima e il dopo, non una descrizione.

Controlla cosa tiene davvero l’interfaccia

Su Linux il resolver di sistema può essere il semplice file, NetworkManager o systemd-resolved, e quale di essi lo possiede decide dove atterra un server spinto. Un processo OpenVPN da riga di comando non aggiorna il resolver di sistema da solo, quindi l’integrazione documentata è uno script up/down o un gestore di connessioni che sa già applicare le impostazioni. Eseguire entrambi è un modo efficiente di creare una corsa.

resolvectl status
cat /etc/resolv.conf

Su Windows l’elenco è per scheda, quindi la scheda del tunnel può tenere i server interni mentre la scheda fisica conserva quelli locali e vince per alcuni nomi. Confronta entrambe le schede invece di quella che supponi attiva.

Segui una query fuori dalla macchina

Cattura entrambe le interfacce contemporaneamente, poi risolvi un nome che dovrebbe usare il resolver interno. Quella coppia di catture risponde a ciò che nessun output di configurazione può.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Una query che compare sull’interfaccia fisica e mai nel tunnel significa che il client ha scelto il resolver sbagliato. Una query su nessuna delle due significa che l’applicazione ha risposto dalla cache, ha interrogato uno stub in ascolto su loopback o ha usato un resolver cifrato il cui traffico non appare mai come porta 53. Cattura anche le risposte, non solo le query, perché una query che esce dal tunnel con una risposta da un indirizzo pubblico è un guasto diverso da nessuna risposta in arrivo.

Il firewall che accetta solo il proprio DNS

I client commerciali a volte installano le proprie catene di filtraggio. Uno schema documentato consente DNS verso il resolver proprio del client e scarta tutto il restante traffico UDP sulla porta 53 che tenta di uscire da un’interfaccia non loopback, incluso il traffico che l’utente ha instradato di proposito altrove. Le query del demone svaniscono senza traccia, il che si legge come un guasto del resolver invece che come un filtro.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Se una regola di scarto viene valutata prima della tua eccezione, una regola aggiunta in coda non viene mai raggiunta, quindi inseriscila in prima posizione e limita la destinazione al resolver che intendi davvero.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Quell’eccezione è diagnostica e non politica. Se la regola del fornitore è deliberata, la riparazione supportata è configurare il client per consentire quel resolver e registrare la decisione, perché una regola inserita non sopravvivrà al prossimo aggiornamento del client.

Perché una pagina di perdite dimostra meno di quanto sembri

Ciò che una pagina di test delle perdite mostra è il resolver che ha parlato con l’operatore del test, non quello che la tua macchina ha consultato. Un inoltro locale che ricorre verso l’esterno mette il proprio indirizzo di uscita su quella pagina, e le query cifrate possono lasciare la pagina del tutto vuota. Entrambi i risultati vengono letti male, uno come perdita e l’altro come garanzia, e nessuna delle due letture deriva dall’osservazione.

La prova difendibile è la cattura: interfaccia, indirizzo di destinazione, risposta e marca temporale. Prendine una prima che il tunnel salga e una dopo, e confrontale la prossima volta che un nome fallisce. Quella coppia dice anche alla persona successiva se il guasto era di risoluzione, di instradamento o di politica di accesso del resolver stesso.