Il DNS non risolve quando il kill switch della VPN blocca la porta 53
Un kill switch può bloccare il DNS di proposito. Confrontate la risoluzione solo nel tunnel con un'eccezione per un resolver locale, poi stabilite quale livello ha davvero fallito.
Quando il kill switch fa cadere il tunnel, porta con sé anche il percorso del DNS, e il resolver che resta è raramente quello che vi aspettate. Due progetti affrontano quel momento in modo molto diverso: bloccare ogni pacchetto DNS che non sia dentro il tunnel, oppurelasciare un resolver in piedi come eccezione. Entrambi sono difendibili. Da una scheda del browser i sintomi sembrano quasi identici, quindi il primo compito è capire quale progetto avete davvero distribuito.
Tengo presente questa distinzione perché la correzione è opposta in ciascun caso. Un progetto ha bisogno di un'eccezione più larga, l'altro di una più stretta. Indovinare costa o la privacy o un pomeriggio.
Due progetti DNS per lo stesso guasto
Il progetto A tratta il resolver come un servizio qualsiasi dietro il tunnel. Le regole del firewall consentono UDP e TCP 53 solo sull'interfaccia del tunnel, e l'indirizzo consegnato al client è un resolver dentro il tunnel. Quando il tunnel cade, le risoluzioni si fermano, e questo è il risultato voluto, non un guasto.
Il progetto B tiene un resolver raggiungibile sulla rete locale, di solito il router su 192.168.1.1 o lo stub del sistema operativo su 127.0.0.53, sul presupposto che la risoluzione dei nomi non debba morire con il tunnel. È comodo in una LAN domestica dove il router risolve per tutta la casa. Sul Wi-Fi di un hotel o di un aeroporto la stessa eccezione punta al server di qualcun altro, e ogni nome che digitate viene rivelato anche se il traffico web resta bloccato.
Il confine è chi possiede il resolver. Se vi fidate di quello locale, un'eccezione è un buco piccolo e onesto. Se non vi fidate, il progetto solo tunnel è l'unico che regge, e il prezzo è che un tunnel caduto si porta via tutti i nomi.
Perché la risoluzione del client VPN funziona ancora
Il client deve risolvere il nome host del gateway prima che esista un tunnel, quindi un blocco rigoroso non deve coprire il percorso di avvio del client. La maggior parte dei client mette in cache l'indirizzo dell'endpoint o fornisce un'eccezione di avvio documentata per quell'unico host. Se il vostro insieme di regole blocca quella risoluzione, il tunnel non torna mai e i log mostrano un client che non raggiunge il proprio server, il che è un difetto di politica e non di DNS.
Il DNS diviso è l'altro punto in cui questo emerge. Il client spinge una zona interna verso un resolver privato e lascia tutto il resto al resolver di sistema. Dopo una caduta, i nomi pubblici possono ancora risolversi mentre quelli interni vanno in timeout, perché la zona privata non ha più una rotta. Per l'utente è «la VPN ha rotto internet»; per il log del resolver è una query che non è mai arrivata.
Con systemd-resolved potete vedere la divisione direttamente.resolvectl statuselenca i server DNS per collegamento e i domini di instradamento, e dopo la caduta del tunnel il dominio interno continua a puntare a un server su un collegamento che non esiste più. Lo stub su 127.0.0.53 accetta ancora la query, poi attende un upstream che non risponderà, ed è per questo che il guasto richiede secondi invece di tornare subito.
Il DNS cifrato non aggira un filtro di pacchetti
DNS over HTTPS e DNS over TLS viaggiano su 443 e 853, quindi una regola che blocca la porta 53 non ha detto nulla su di loro. Bloccare «DNS» per porta è una politica su una porta, non sulla risoluzione dei nomi. Se il vostro kill switch blocca tutto il traffico fuori dal tunnel, DoH è coperto per caso. Se avete ricavato un permesso per un portale captive o un resolver pubblico, non lo è.
I controlli lato client sono la leva più economica. Firefox abbandona il proprio resolver DoH quando il nome canarinouse-application-dns.netnon si risolve, ed è per questo che le reti gestite pubblicano quel dominio come NXDOMAIN; anche una politica aziendale può fissarlo disattivato. Android Private DNS e il DNS sicuro di Chrome hanno i propri interruttori e i propri valori predefiniti. Disattivarli è più affidabile che inseguire indirizzi di resolver, perché la lista degli indirizzi cambia e il vostro insieme di regole no.
Esiste una versione di questo che non parla affatto di fughe. Un'applicazione con un resolver fissato ha comunque bisogno di un percorso di rete per raggiungerlo. La crittografia cambia chi può leggere la query, non se il pacchetto può lasciare la macchina, quindi un blocco per l'intero dispositivo sconfigge l'impostazione senza toccarla.
Abbinate il sintomo al livello
La maggior parte delle segnalazioni arriva come una frase, e quella frase di solito nomina già il livello. La tabella qui sotto è ciò che ripasso prima di toccare una regola; il punto è decidere se la query è stata bloccata, indirizzata male o mai inviata.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
Le prime due righe sono quelle che le persone diagnosticano male. Una caduta silenziosa e un rifiuto sembrano entrambi «il DNS è rotto» in un browser, ma solo uno dei due significa che il vostro kill switch sta facendo il suo lavoro. Un rifiuto significa che qualcosa ha risposto, quindi il blocco non è dove pensate.
Ripristinate la politica del resolver, poi dimostratela
Correggete il progetto, non il sintomo. Per la risoluzione solo tunnel, consentite 53 sull'interfaccia del tunnel, spingete il resolver interno con la configurazione del tunnel e lasciate il collegamento fisico senza alcun permesso DNS. Con wg-quick è la rigaDNS =a scrivere il resolver nella configurazione dell'interfaccia, quindi un tunnel che la omette lascia il vecchio resolver al suo posto e ogni query sul percorso sbagliato.Il manuale di wg-quickdocumenta questo comportamento per piattaforma.
Poi verificate in questo ordine. Su Linux,resolvectl statusmostra il collegamento attivo,dig +short example.comprova un nome pubblico,dig @10.8.0.1 internal.example.comprova quello privato, esudo tcpdump -ni any port 53mostra quale interfaccia usano i pacchetti mentre eseguite entrambi. Su Windows,Get-DnsClientServerAddress -AddressFamily IPv4eResolve-DnsName example.comdanno gli stessi due fatti: chi è configurato e chi risponde.
Chiudete con il test negativo. Scollegate il tunnel, confermate che un nome pubblico nuovo fallisce, confermate che il nome privato fallisce, econfermate che nessun pacchetto della porta 53 ha lasciato l'adattatore fisico. Un blocco che regge solo per risposte in cache non regge affatto.
Lista di controllo prima di chiudere il ticket:
- Il resolver usato durante il guasto è quello che la politica intende.
- La risoluzione dell'endpoint da parte del client è ancora consentita, tramite cache o eccezione.
- DoH e DoT sono coperti dal blocco oppure disattivati dalla politica.
- Le zone private falliscono chiuse, non aperte, una volta sparito il tunnel.