resolv.conf su WSL 2: il DNS muore quando la VPN si connette

La navigazione dentro la distribuzione funziona, e il primo nome host interno fallisce nel momento in cui il tunnel sale. Il riflesso è aggiungere un resolver pubblico, che ripristina internet e rende il nome aziendale irraggiungibile per il resto della giornata. Su WSL 2, /etc/resolv.conf è un output generato e non una configurazione, e questo è il meccanismo che vale la pena capire. La correzione non è un resolver migliore, è la proprietà del file.

Il file viene generato, non configurato

WSL 2 scrive il file all’avvio dagli adattatori Windows che vede in quel momento, e stampa in cima un commento che lo dice. Quando un client VPN aggiunge o riscrive un adattatore dopo, la distribuzione non rigenera necessariamente nulla, e il file continua a descrivere una rete che non esiste più.

Un secondo modo di guasto è più silenzioso: WSL può copiare i server solo da alcuni adattatori. Se l’adattatore fisico ha già un resolver IPv6, i server IPv4 forniti dall’adattatore VPN possono essere scartati invece di aggiunti, e il file sembra completo mentre omette proprio quello che risponde ai nomi interni.

Confronta la vista di Windows con la vista di Linux

Leggi entrambi i lati prima di modificare. Dentro la distribuzione, guarda cosa contiene il file e se è un file regolare o un collegamento. Su Windows, elenca il resolver per ogni adattatore, incluso quello creato dalla VPN:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

Quando l’adattatore VPN mostra i server aziendali e Linux mostra altro, la discrepanza è nella generazione e non nella raggiungibilità. Confronta l’elenco degli adattatori oltre agli indirizzi, perché un adattatore mancante spiega un server mancante. Questa distinzione decide se stai riparando WSL o un firewall, e le due cose non hanno nulla in comune.

Disattiva la generazione e scrivi il tuo file

Un’impostazione documentata impedisce a WSL di riscrivere il file, e si trova in /etc/wsl.conf. Aggiungi una sezione di rete a quel file:

[network]
generateResolvConf = false

Poi termina la distribuzione da Windows con wsl --shutdown e avviala di nuovo. Se il percorso è un collegamento simbolico e non un file regolare, rimuovi il collegamento prima di scrivere il tuo contenuto, perché scrivere attraverso il collegamento può ricreare la destinazione generata al successivo avvio. Da quel momento il file è tuo e nulla lo riscrive.

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

Senza un dominio di ricerca, un nome host non qualificato viene completato con la radice pubblica e torna come nessun dominio del genere. timeout impedisce a un primo server morto di bloccare ogni interrogazione, attempts limita quanti tentativi spende un’interrogazione, e rotate distribuisce i tentativi invece di partire sempre dall’alto. Il compromesso è che il file non segue più una VPN il cui indirizzo di resolver cambia tra le sessioni.

Gestisci un resolver che si sposta, poi verifica

Alcuni client forniscono un resolver specifico della sessione, quindi un file statico si rompe alla connessione successiva. Due approcci sono difendibili. Scrivi il file da un piccolo script ogni volta che l’indirizzo cambia, oppure lascia attiva la generazione e assicurati che l’adattatore da cui WSL copia porti il server aziendale. Il secondo non richiede alcun hook e fallisce ogni volta che la generazione salta l’adattatore VPN; entrambi richiedono ancora di risolvere prima il conflitto IPv6.

Windows applica anche proprie politiche dei nomi, come un elenco di ricerca dei suffissi o una politica di risoluzione per domini specifici, e copiare gli indirizzi degli adattatori non riproduce queste regole. Se un nome si risolve su Windows e non nella distribuzione con lo stesso server, confronta la gestione dei suffissi prima di dare la colpa al tunnel.

Prova con un nome e non con un pacchetto: getent hosts sensor-access0.corp.example passa per lo stack dei resolver, mentre un ping può riuscire contro un indirizzo memorizzato o letterale. Poi ripeti dopo una disconnessione e una riconnessione, perché un’impostazione che funziona una volta e viene rigenerata alla ripresa non è mai stata corretta. Salva il contenuto precedente e annota quale componente possiede il percorso su quella macchina, così il prossimo cambiamento parte da prove.