WSL2 perdeu o DNS despois de conectar a VPN? Dúas causas

O ping por enderezo funciona dentro da distribución, as instalacións de paquetes e as descargas de git non, e o fallo apareceu xusto despois de erguerse o túnel. Só os nomes deixaron de resolverse, o que apunta ao DNS e non á conectividade. Reinstalar paquetes é o primeiro movemento equivocado máis popular aquí. WSL2 ten dúas formas independentes de producir exactamente ese síntoma, e necesitan reparacións distintas.

Por que a distribución mantén o seu propio resolver

O cliente DNS de Windows non se usa dentro da distribución. WSL2 constrúe o seu propio ficheiro de resolver ao arrincar, apuntando a un enderezo stub que Windows publica no conmutador virtual para a máquina virtual auxiliar.

Ese arranxo é estable ante cambios de rede normais porque se escribe unha vez e reutilízase. O arranxo deixa de ser correcto cando un cliente de túnel reescribe a lista de adaptadores do host despois de que a máquina virtual auxiliar xa se iniciou.

Nada dentro da distribución vixía o cambio, así que o ficheiro segue apuntando a un enderezo que pode que xa non estea na ruta. A seguinte consulta entón espera, expira ou recibe resposta dun servidor que nunca oíu falar da zona interna. Desde dentro, o resolver simplemente deixa de responder, e todos os nomes fallan á vez.

Reúne probas en ambos os lados primeiro

Rexistra o que ve a distribución e logo o que ve Windows, antes de cambiar calquera dos dous. As dúas vistas xuntas son o que distingue os modos de fallo.

Dentro da distribución, imprime o ficheiro de resolver, a táboa de rutas e unha consulta interna e outra pública:

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

En Windows, lista os servidores DNS por adaptador e a táboa IPv4 con métricas. Un cliente VPN adoita instalar unha ruta para a subrede de WSL2, e a súa métrica decide se ese tráfico sae polo túnel ou queda local.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Métrica de ruta ou ficheiro obsoleto

O primeiro fallo é o ficheiro obsoleto. O resolver escribiuse para o estado do adaptador ao arrincar, e o túnel cambiou ese estado. O seu enderezo stub pode ser agora inalcanzable, ou pode nomear un servidor que non sabe nada da zona interna.

O segundo é un problema de encamiñamento. Cando a VPN engade unha ruta que cobre a subrede de WSL2 cunha métrica inferior á ruta de enlace do host, os paquetes dirixidos á máquina virtual auxiliar entran no túnel. Entón expira cada servizo de WSL2, non só o DNS.

A proba que os distingue custa unha liña. Se un enderezo numérico coma un resolver público segue respondendo ao ping mentres os nomes fallan, a ruta está intacta e o problema é o DNS. Ese é o caso no que un cambio de resolver está xustificado, e o caso no que non o está tamén se fai evidente. Se a proba numérica tamén falla, a máquina virtual auxiliar perdeu a súa ruta e ningún ficheiro de resolver o arranxará.

Para o caso de encamiñamento, quita a métrica automática do adaptador do túnel e dálle un número por riba da ruta de enlace de WSL2:

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

Apagala importa. Cambiar a métrica non reescribe a máquina virtual auxiliar en marcha, así que a distribución debe reconstruírse antes de que o cambio sexa visible.

Toma o ficheiro, deliberadamente

Se o encamiñamento é correcto e só fallan os nomes internos, o resolver é o culpable e podes deter o xerador. É un cambio deliberado cun custo de mantemento, non unha solución provisional para aplicar sen coidado.

Crea /etc/wsl.conf dentro da distribución coa sección de rede que desactiva a xeración, e despois escribe o ficheiro de resolver ti mesmo, primeiro o servidor corporativo e despois un público de reserva:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

A orde importa. Un resolver público non pode responder un nome interno, e a reserva existe só para consultas de internet. Unha vez o ficheiro é teu, nada o rexenera, así que un resolver corporativo que se muda convértese nunha caída que ti mesmo debes notar.

Comproba nomes e despois paquetes

Verifica un nome interno e un público co resolver do sistema, e repite despois a operación que fallou. Os xestores de paquetes usan ás veces un resolver propio, por iso un getent que funciona pode convivir cunha instalación rota.

Se automatizas a reescritura, faina idempotente: sen túnel, conserva o ficheiro que xa existe en lugar de escribir unha lista de servidores baleira.

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

Unha consulta interna que funciona e unha consulta pública que funciona, desde dentro da distribución, é o resultado que merece rexistrarse. Unha icona verde de VPN no host non demostra ningunha das dúas.