Fuga DNS con VPN su Windows: perché la metrica batte la route

Una query esce dalla macchina e raggiunge il router di casa mentre ogni pacchetto viene incapsulato nel tunnel. La conclusione naturale è una route mancante, e la route di solito è a posto. Windows può scegliere quale resolver d’interfaccia interrogare in base alla metrica, e un adattatore di tunnel perde spesso questo confronto con quello wireless.

Due spiegazioni per una fuga

La spiegazione per route dice che una parte del traffico esce dal tunnel, quindi la route predefinita o l’elenco del tunnel diviso devono essere sbagliati. Quella spiegazione si verifica con un solo comando, e quando la route predefinita punta dentro il tunnel la questione è chiusa. Verificatela per prima perché costa poco, poi mettetela da parte quando torna pulita.

La spiegazione per classifica dice che il traffico è tutto nel tunnel e la query viene comunque inviata a un altro resolver. Windows tratta la scelta del resolver come una proprietà per interfaccia con un ordine, quindi un adattatore fisico con metrica migliore può fornire DNS per un nome anche se i pacchetti dell’indirizzo risolto passano dal tunnel. Entrambe le spiegazioni producono lo stesso sintomo su una pagina di test delle fughe, per questo il test non è la diagnosi. Solo una delle due si ripara modificando le route.

Confrontate metriche e resolver insieme

Annotate le interfacce, le loro metriche e i server configurati mentre il tunnel è attivo. Leggetele come una tabella e non come due elenchi separati, perché la domanda è quale resolver viene prima, non quali resolver esistono.

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

Se l’adattatore di tunnel porta un numero più alto di quello fisico, il suo resolver non è preferito, e un nome interno andrà a ciò che offre il lato fisico. Quel router può rispondere dalla cache, inoltrare la query o rifiutarla, e nessuno di questi esiti è il progetto che intendevate. La classifica è una preferenza, quindi perde in silenzio invece di sollevare un errore.

Un adattatore di tunnel senza alcun resolver configurato è una variante altrettanto comune. Il client alza l’interfaccia senza spingere il DNS, quindi la questione della classifica non si pone nemmeno.

Portate il tunnel in cima e ricontrollate

Date all’interfaccia del tunnel la metrica più bassa, oppure alzate il valore dell’adattatore fisico, in una shell elevata. Entrambe sono impostazioni per interfaccia ed entrambe sono reversibili, cosa che conta quando cambiate una macchina davanti alla quale forse non siete seduti.

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

La modifica è visibile subito, e il client DNS e gli altri consumatori mettono in cache la scelta già fatta. Riconnettete il tunnel, o riavviate, prima di leggere qualcosa in un risultato di query. Un test eseguito troppo presto riprodurrà il vecchio comportamento e sembrerà una correzione fallita.

Poi interrogate un nome interno e uno pubblico e verificate quale server ha risposto. Il riferimento sulle metriche automatiche di Microsoft spiega perché il valore più basso è preferito e come viene derivata l’assegnazione automatica.

Fatelo sopravvivere a una riconnessione

Una metrica manuale su un adattatore ricreato a ogni connessione è un’impostazione che scompare. Se il client ricostruisce l’interfaccia, la sostituzione richiede uno script dopo la connessione, un criterio o una configurazione client che possieda il DNS durante la connessione.

I server configurati staticamente sull’adattatore fisico hanno lo stesso problema di durabilità al contrario. Continuano a rispondere per quell’interfaccia finché non vengono rimossi, e il DHCP li ripopolerà con il lease successivo, quindi rimuoverli è una misura e non un progetto. Il progetto durevole è un criterio di risoluzione dei nomi per lo spazio dei nomi interno, o un client che prende possesso del DNS per la durata della connessione. In ogni caso, annotate l’elenco dei resolver prima e dopo una riconnessione, ripristinate la metrica originale quando avete finito di testare e confermate che il comportamento precedente è tornato.