WSL2 ha perso il DNS dopo la connessione VPN? Due cause

Il ping per indirizzo funziona dentro la distribuzione, le installazioni dei pacchetti e i prelievi git no, e il guasto è comparso subito dopo l’attivazione del tunnel. Solo i nomi hanno smesso di risolversi, il che indica il DNS e non la connettività. Reinstallare i pacchetti è la prima mossa sbagliata più diffusa qui. WSL2 ha due modi indipendenti di produrre esattamente quel sintomo, e richiedono riparazioni diverse.

Perché la distribuzione tiene un resolver proprio

Il client DNS di Windows non viene usato dentro la distribuzione. WSL2 costruisce il proprio file resolver all’avvio, puntando a un indirizzo stub che Windows pubblica sullo switch virtuale per la macchina virtuale ausiliaria.

Questa disposizione è stabile nei normali cambi di rete perché viene scritta una volta e riutilizzata. La disposizione smette di essere corretta quando un client di tunnel riscrive l’elenco degli adattatori dell’host dopo che la macchina virtuale ausiliaria è già partita.

Niente dentro la distribuzione osserva il cambiamento, quindi il file continua a puntare a un indirizzo che forse non è più sul percorso. La ricerca successiva allora attende, va in timeout o riceve una risposta da un server che non ha mai sentito parlare della zona interna. Dall’interno il resolver semplicemente smette di rispondere, e tutti i nomi falliscono insieme.

Raccogliete prima le prove su entrambi i lati

Annotate ciò che vede la distribuzione, poi ciò che vede Windows, prima di cambiarne uno. Le due viste insieme sono ciò che distingue le modalità di guasto.

Dentro la distribuzione, stampate il file resolver, la tabella di routing e una ricerca interna e una pubblica:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

Su Windows, elencate i server DNS per adattatore e la tabella IPv4 con le metriche. Un client VPN di solito installa una rotta per la sottorete WSL2, e la sua metrica decide se quel traffico esce dal tunnel o resta locale.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Metrica di rotta o file obsoleto

Il primo guasto è il file obsoleto. Il resolver è stato scritto per lo stato dell’adattatore all’avvio, e il tunnel ha cambiato quello stato. Il suo indirizzo stub ora può essere irraggiungibile, oppure può nominare un server che non sa nulla della zona interna.

Il secondo è un problema di routing. Quando la VPN aggiunge una rotta che copre la sottorete WSL2 con una metrica inferiore alla rotta di collegamento dell’host, i pacchetti indirizzati alla macchina virtuale ausiliaria entrano nel tunnel. Allora va in timeout ogni servizio WSL2, non solo il DNS.

Il test che li distingue costa una riga. Se un indirizzo numerico come un resolver pubblico risponde ancora al ping mentre i nomi falliscono, il percorso è integro e il problema è il DNS. È il caso in cui un cambio di resolver è giustificato, e il caso in cui non lo è diventa evidente anch’esso. Se anche il test numerico fallisce, la macchina virtuale ausiliaria ha perso la sua rotta e nessun file resolver lo sistemerà.

Per il caso di routing, togliete la metrica automatica dall’adattatore del tunnel e datele un numero sopra la rotta di collegamento WSL2:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

Lo spegnimento conta. Cambiare la metrica non riscrive la macchina virtuale ausiliaria in esecuzione, quindi la distribuzione va ricostruita prima che il cambiamento sia visibile.

Prendete il file, deliberatamente

Se il routing è corretto e falliscono solo i nomi interni, il resolver è colpevole e potete fermare il generatore. È un cambiamento deliberato con un costo di manutenzione, non un espediente da applicare alla leggera.

Create /etc/wsl.conf dentro la distribuzione con la sezione di rete che disattiva la generazione, poi scrivete voi stessi il file resolver, prima il server aziendale e poi un pubblico di riserva:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

L’ordine conta. Un resolver pubblico non può rispondere a un nome interno, e la riserva esiste solo per le ricerche internet. Una volta che il file è vostro, niente lo rigenera, quindi un resolver aziendale che si sposta diventa un’interruzione che dovete notare voi stessi.

Controllate i nomi, poi i pacchetti

Verificate un nome interno e uno pubblico con il resolver di sistema, poi ripetete l’operazione che è fallita. I gestori di pacchetti a volte usano un resolver proprio, per questo un getent che funziona può convivere con un’installazione rotta.

Se automatizzate la riscrittura, rendetela idempotente: senza tunnel, conservate il file che esiste già invece di scrivere un elenco di server vuoto.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

Una ricerca interna che funziona e una ricerca pubblica che funziona, dall’interno della distribuzione, è il risultato che vale la pena registrare. Un’icona VPN verde sull’host non dimostra nessuna delle due.