Perché WSL perde il nome host di lavoro quando la VPN si connette?

Windows risolve l’host interno senza alcun problema, e lo stesso nome fallisce dentro WSL nel momento in cui il tunnel si alza. La riparazione abituale consiste nello scrivere un resolver pubblico nella distribuzione, il che ripristina la navigazione normale e rende il nome host di lavoro impossibile da risolvere. Questo scambia un guasto con un altro e nasconde lo strato che si è realmente rotto. Prima di aggiungere o rimuovere qualsiasi riga di resolver, determinate quale dei tre strati sta fallendo.

Escludete prima un guasto di routing

Interrogate lo stesso nome completamente qualificato su entrambi i lati, non due nomi che si somigliano. Un successo in Windows e un guasto in WSL per la stessa stringa è la firma di due percorsi di risoluzione, e poche altre cose producono quel modello con tanta pulizia. Se WSL non riesce a raggiungere il servizio nemmeno al suo indirizzo numerico noto, è presente anche un problema di routing o di filtraggio. In quel caso il lavoro sul DNS non lo rivelerà, e il pomeriggio va allo strato sbagliato.

Tre sintomi coprono la maggior parte di questi casi, e ciascuno punta altrove. Leggete la riga corrispondente prima di aprire un file di configurazione:

La riga centrale è quella che le persone leggono male, perché la modifica che l’ha rotta è stata fatta settimane prima e allora sembrava riuscita. La terza riga è quella che le persone diagnosticano male, perché un nome che si risolve sembra la prova che la rete è sana. Entrambe le righe vi mandano a una sezione diversa più sotto.

Il tunneling DNS ha un limite minimo di versione

Microsoft documenta una modalità di rete di WSL che incanala le richieste DNS verso il resolver di Windows attraverso un canale di virtualizzazione. Nelle build di Windows 11 supportate è attiva per impostazione predefinita, ed è per questo che due macchine sulla stessa rete aziendale si comportano diversamente. La variabile è il numero di build, non la politica aziendale.

La guida di rete di WSL descrive quella modalità e le versioni che la supportano. La funzione conta perché la politica DNS aziendale di solito vive nel resolver di Windows, e una distribuzione che eredita il percorso di Windows eredita la politica con esso. Una distribuzione che interroga un resolver pubblico non ha alcuna rotta verso un nome privato, per quanto ordinata possa sembrare la sua configurazione. Quel meccanismo spiega l’intero sintomo e spiega perché la soluzione alternativa con resolver pubblico fallisce.

Leggete la build prima di modificare qualsiasi cosa. Un’impostazione copiata da un’installazione più recente non è la prova che una più vecchia la implementi. Annotate la build accanto alla modifica, perché la differenza tra due macchine è quasi sempre una versione e non una politica.

Le vecchie sovrascritture sopravvivono al problema che hanno risolto

Le ricette più vecchie disattivavano i file di resolver generati, codificavano un server dei nomi o bloccavano il file con un attributo immutabile. Quelle modifiche restano al loro posto molto dopo che il problema di connettività che le ha provocate è scomparso, e di solito sono il motivo per cui un’impostazione più recente sembra non fare nulla. Sopravvivono anche a una reinstallazione della distribuzione sotto forma di profilo di shell che riscrive il file a ogni accesso. L’ultimo è il più difficile da trovare, perché è invisibile dal file che tutti ispezionano.

Cercate un file di resolver scritto a mano, un attributo immutabile su di esso e uno script di avvio che lo riscrive. Controllate il flag immutabile prima di modificare, perché una scrittura su un file bloccato fallisce in un modo che si legge come un problema di permessi. Controllate poi il profilo di shell, perché uno script lì ripristina il vecchio contenuto in pochi secondi dopo la vostra correzione.

Rimuovere una sovrascrittura ha conseguenze, quindi annotate cosa avete rimosso e perché. Una distribuzione che ha davvero bisogno di un resolver statico per un altro scopo si romperà quando il file generato tornerà.

Due file, due ruoli diversi

I due file di configurazione vivono in luoghi diversi e controllano cose diverse, e confonderli produce modifiche applicate allo strato sbagliato. Il file lato Windows imposta proprietà della macchina virtuale, mentre il file lato distribuzione imposta come quella distribuzione costruisce la propria configurazione di resolver. Nessuno dei due sovrascrive l’altro, per questo entrambi devono concordare.

Per un’installazione che supporta la funzione, il frammento lato Windows è breve. È l’intera modifica su quel lato:

[wsl2]
dnsTunneling=true

Quel frammento va nel profilo utente di Windows e si applica alla macchina virtuale anziché a una singola distribuzione. Il tunneling richiede anche che la distribuzione non abbia disattivato la generazione del resolver, quindi il file lato distribuzione deve lasciare in pace quel comportamento. Cambiate uno senza l’altro e la modalità non fa nulla in silenzio, che è il modo più comune in cui questa riparazione viene segnalata come rotta. Controllate entrambi i file nella stessa sessione, perché due modifiche fatte a settimane di distanza sono due modifiche che nessuno può attribuire.

Riavviate, poi interrogate da entrambi i lati

Queste impostazioni vengono lette all’avvio dell’ambiente, quindi una nuova shell dentro una distribuzione in esecuzione non le ricaricherà. Spegnete l’ambiente invece di riavviare la shell, e salvate prima qualsiasi lavoro in corso perché ogni distribuzione si ferma con esso. Questa sola omissione spiega la maggior parte delle segnalazioni di una modifica senza effetto.

Poi ponete la stessa domanda da entrambi i lati. L’output mostra anche con quale resolver è finita davvero la distribuzione:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

Il primo comando termina l’ambiente, il secondo mostra quale resolver usa ora la distribuzione, e gli ultimi due pongono la stessa domanda a ciascun lato. Confrontate le risposte e non lo stato dell’impostazione. Una query che fallisce ancora dopo un riavvio pulito con entrambi i file corretti punta alla politica di resolver aziendale, e quella conversazione ha un altro proprietario.