WSL2 non eredita la VPN aziendale, ed è proprio questo il bug

Il wiki interno si carica in Edge, mentre git clone dentro la distribuzione va in timeout. Questa singola osservazione viene di solito letta come «la VPN blocca WSL2», e l'ora successiva se ne va a modificare /etc/resolv.conf. La lettura più utile è che WSL2 non ha mai avuto il percorso di rete dell'host: gira in una VM di servizio con il proprio adattatore, le proprie route e un file resolver che Windows genera per lei. Tutto ciò che segue dipende da quale di questi tre vi manca davvero.

La VM ha il proprio stack, le proprie metriche e il proprio resolver

Nella modalità NAT predefinita, la distribuzione sta dietro uno switch virtuale e raggiunge Internet tramite l'host, ma non vede gli adattatori dell'host. ip addr mostra un'interfaccia con un indirizzo privato, ip route mostra una route predefinita attraverso quello switch, e /etc/resolv.conf è un file generato che punta a uno stub resolver scelto da Windows. Niente di tutto questo cambia perché sul lato Windows è partito un client VPN.

Per questo «il browser funziona» dimostra così poco. Il browser usa lo stack dell'host, il tunnel e la politica resolver dell'host. La vostra shell usa un altro stack che per caso condivide una scheda di rete fisica. Concordano nel caso felice e divergono esattamente quando la VPN installa un filtro, riscrive l'elenco DNS o aggiunge una route per la subnet dello switch virtuale.

Due test stabiliscono in quale mondo siete, e devono girare dentro la distribuzione:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Il fallimento dei nomi mentre un indirizzo letterale risponde è un problema di resolver. Il fallimento congiunto di nomi e indirizzi è un problema di percorso, e nessuna modifica al resolver lo toccherà. Le prove dal lato Windows arrivano dopo: Get-NetAdapter | Get-DnsClientServerAddress e route print -4 mostrano se il tunnel si è preso la subnet in cui vive la vostra VM.

Primo mito: i server DNS aziendali risolvono tutto

Modificare il file resolver è il consiglio classico, ed è giusto circa la metà delle volte. Quando è giusto, lo è per un motivo preciso: il file generato punta a un resolver che conosce solo nomi pubblici, quindi una query per intranet.example.internal torna come inesistente anche se il percorso è a posto.

Fissare i server della VPN significa impedire a Windows di rigenerare il file, perché qualsiasi file scritto a mano viene sostituito al successivo avvio:

[network]
generateResolvConf = false

Salvatelo come /etc/wsl.conf, eseguite wsl --shutdown da Windows, poi avviate la distribuzione e scrivete /etc/resolv.conf con i server del tunnel per primi e un resolver pubblico solo come riserva. È un cambiamento duraturo con un costo di manutenzione: il file non segue più l'host, quindi quando gli indirizzi DNS aziendali cambiano la distribuzione continua a chiedere quelli vecchi. Qualcuno deve possedere quel file.

Non fa nulla nemmeno quando il guasto è più ampio. Se curl verso 1.1.1.1 va in timeout, il client del tunnel sta filtrando lo switch virtuale o sta instradando la subnet della VM nel tunnel, e un resolver corretto vi dà solo nomi ancora irraggiungibili.

Secondo mito: la modifica della metrica regge

Quando i nomi si risolvono ma il traffico esce dall'adattatore fisico, la leva sono le metriche di interfaccia. Date un costo alto all'adattatore VPN e uno basso allo switch WSL:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Poi ricordate che in molte build del client l'adattatore del tunnel viene ricreato a ogni connessione e la metrica torna al valore predefinito. Un comando una tantum è una correzione che scade in silenzio, di solito nel fine settimana, e il ticket torna con «la settimana scorsa funzionava». Un'attività pianificata attivata dall'evento VPN, o uno script che l'utente esegue dopo la connessione, è la versione onesta di questa riparazione.

La stessa scadenza vale per le route dell'host aggiunte per un singolo prefisso ostinato. Valgono come diagnostica, perché dicono se il problema è una destinazione o l'intero percorso, ma non sono un'architettura.

Terzo mito: una correzione copre ogni build di Windows

wsl-vpnkit è il pattern sidecar: una piccola distribuzione possiede il percorso lato host e inoltra per le altre distribuzioni tramite un socket virtuale, così il traffico delle applicazioni smette di dipendere dallo switch filtrato. Serve che il percorso standard funzioni, il che significa rimuovere gli override networkingMode e dnsTunneling da %UserProfile%\.wslconfig, ripristinare generateResolvConf = true in ogni distribuzione funzionante e avviare il servizio all'accesso.

La modalità mirror è l'alternativa integrata in Windows 11 22H2 e successivi, ed è un'impostazione più uno spegnimento:

[wsl2]
networkingMode=mirrored

Dentro la distribuzione ip addr elenca allora gli adattatori dell'host, il tunnel può comparire tra loro, e il tunneling DNS inoltra le query attraverso il resolver di Windows anche quando il client riscrive l'elenco DNS. Non è universale: alcuni driver di filtro scartano ancora il percorso mirror, e le regole del firewall Hyper-V possono richiedere un'autorizzazione esplicita. La guida di rete WSL di Microsoft è la pagina da confrontare con la vostra build prima di applicare una ricetta scritta per una più recente.

Provate tre cose dopo ogni modifica

Scegliete un meccanismo per macchina e scrivetelo, perché i due si combinano male. Un sidecar sopra la modalità mirror raddoppia l'inoltro, e un host mirror con una voce sidecar obsoleta in .wslconfig tende a fallire dopo un aggiornamento, non prima.

Qualunque cosa abbiate scelto, il test di accettazione sono le stesse tre richieste dentro la distribuzione: un nome interno, un nome pubblico e un indirizzo grezzo. Poi ripetetele dopo aver disconnesso e riconnesso il tunnel, e dopo wsl --shutdown. Se fallisce solo il nome interno è politica del resolver; se falliscono insieme nome interno e pubblico con un indirizzo che funziona è ancora politica del resolver; se fallisce tutto è il percorso.

Se un host interno fallisce mentre il resto funziona, smettete di guardare il resolver e cercate una route mancante per quel prefisso. Se tutto funziona fino alla riconnessione successiva, avete trovato una correzione che dipende dallo stato di runtime, e va riapplicata automaticamente o sostituita con uno dei due meccanismi sopra.