WSL2 va perdre el DNS després de connectar la VPN? Dues causes

El ping per adreça funciona dins de la distribució, les instal·lacions de paquets i les descàrregues de git no, i la fallada va aparèixer just després d’aixecar-se el túnel. Només van deixar de resoldre’s els noms, cosa que apunta al DNS i no a la connectivitat. Reinstal·lar paquets és el primer moviment equivocat més popular aquí. WSL2 té dues maneres independents de produir exactament aquest símptoma, i necessiten reparacions diferents.

Per què la distribució manté el seu propi resolutor

El client DNS de Windows no s’utilitza dins de la distribució. WSL2 construeix el seu propi fitxer de resolutor en arrencar, apuntant a una adreça stub que Windows publica al commutador virtual per a la màquina virtual d’utilitat.

Aquest arranjament és estable davant canvis de xarxa normals perquè s’escriu una vegada i es reutilitza. L’arranjament deixa de ser correcte quan un client de túnel reescriu la llista d’adaptadors de l’amfitrió després que la màquina virtual d’utilitat ja s’hagi iniciat.

Res dins de la distribució no vigila el canvi, així que el fitxer continua apuntant a una adreça que potser ja no és al camí. La consulta següent aleshores espera, expira o rep una resposta d’un servidor que mai no ha sentit a parlar de la zona interna. Des de dins, el resolutor simplement deixa de respondre i tots els noms fallen alhora.

Primer recolliu proves de les dues bandes

Anoteu què veu la distribució i després què veu Windows, abans de canviar cap dels dos. Les dues vistes juntes són el que distingeix els modes de fallada.

Dins de la distribució, imprimiu el fitxer de resolutor, la taula d’encaminament i una consulta interna i una de pública:

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

A Windows, llisteu els servidors DNS per adaptador i la taula IPv4 amb mètriques. Un client de VPN instal·la normalment una ruta per a la subxarxa WSL2, i la seva mètrica decideix si aquest trànsit surt pel túnel o es queda local.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Mètrica de ruta o fitxer antic

La primera fallada és el fitxer antic. El resolutor es va escriure per a l’estat de l’adaptador en arrencar, i el túnel va canviar aquest estat. La seva adreça stub pot ser ara inaccessible, o pot nomenar un servidor que no sap res de la zona interna.

La segona és un problema d’encaminament. Quan la VPN afegeix una ruta que cobreix la subxarxa WSL2 amb una mètrica inferior a la de la ruta d’enllaç de l’amfitrió, els paquets adreçats a la màquina virtual d’utilitat entren al túnel. Llavors expira cada servei de WSL2, no només el DNS.

La prova que les distingeix costa una línia. Si una adreça numèrica com un resolutor públic encara respon al ping mentre els noms fallen, el camí és intacte i el problema és el DNS. Aquest és el cas en què un canvi de resolutor està justificat, i el cas en què no ho està també es fa evident. Si la prova numèrica també falla, la màquina virtual d’utilitat ha perdut la ruta i cap fitxer de resolutor ho arreglarà.

Per al cas d’encaminament, traieu la mètrica automàtica de l’adaptador del túnel i doneu-li un número per sobre de la ruta d’enllaç de WSL2:

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

Aturar-la importa. Canviar la mètrica no reescriu la màquina virtual d’utilitat en marxa, així que la distribució s’ha de reconstruir abans que el canvi sigui visible.

Preneu el fitxer, deliberadament

Si l’encaminament és correcte i només fallen els noms interns, el resolutor és la culpa i podeu aturar el generador. És un canvi deliberat amb un cost de manteniment, no una solució provisional per aplicar sense pensar.

Creeu /etc/wsl.conf dins de la distribució amb la secció de xarxa que desactiva la generació, i després escriviu el fitxer de resolutor vosaltres mateixos, primer el servidor corporatiu i després un de públic de reserva:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

L’ordre importa. Un resolutor públic no pot respondre un nom intern, i la reserva només existeix per a consultes d’internet. Un cop el fitxer és vostre, res no el regenera, així que un resolutor corporatiu que es trasllada es converteix en una caiguda que heu de notar vosaltres.

Comproveu els noms, després els paquets

Verifiqueu un nom intern i un de públic amb el resolutor del sistema, i repetiu després l’operació que va fallar. Els gestors de paquets de vegades fan servir un resolutor propi, i per això un getent que funciona pot conviure amb una instal·lació trencada.

Si automatitzeu la reescriptura, feu-la idempotent: sense cap túnel, conserveu el fitxer que ja existeix en lloc d’escriure una llista de servidors buida.

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

Una consulta interna que funciona i una consulta pública que funciona, des de dins de la distribució, és el resultat que val la pena enregistrar. Una icona verda de VPN a l’amfitrió no demostra ni una cosa ni l’altra.