¿WSL2 perdió el DNS tras conectar la VPN? Dos causas

El ping por dirección funciona dentro de la distribución, las instalaciones de paquetes y las descargas de git no, y el fallo apareció justo después de levantarse el túnel. Solo los nombres dejaron de resolverse, lo que apunta al DNS y no a la conectividad. Reinstalar paquetes es el primer movimiento equivocado más popular aquí. WSL2 tiene dos formas independientes de producir exactamente ese síntoma, y necesitan reparaciones distintas.

Por qué la distribución mantiene su propio resolver

El cliente DNS de Windows no se usa dentro de la distribución. WSL2 construye su propio archivo de resolver al arrancar, apuntando a una dirección stub que Windows publica en el conmutador virtual para la máquina virtual auxiliar.

Ese arreglo es estable ante cambios de red normales porque se escribe una vez y se reutiliza. El arreglo deja de ser correcto cuando un cliente de túnel reescribe la lista de adaptadores del host después de que la máquina virtual auxiliar ya se ha iniciado.

Nada dentro de la distribución vigila el cambio, así que el archivo sigue apuntando a una dirección que puede que ya no esté en la ruta. La siguiente consulta entonces espera, expira o recibe respuesta de un servidor que nunca ha oído hablar de la zona interna. Desde dentro, el resolver simplemente deja de responder, y todos los nombres fallan a la vez.

Reúna pruebas en ambos lados primero

Registre lo que ve la distribución y luego lo que ve Windows, antes de cambiar cualquiera de los dos. Las dos vistas juntas son lo que distingue los modos de fallo.

Dentro de la distribución, imprima el archivo de resolver, la tabla de rutas y una consulta interna y otra pública:

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

En Windows, liste los servidores DNS por adaptador y la tabla IPv4 con métricas. Un cliente VPN suele instalar una ruta para la subred de WSL2, y su métrica decide si ese tráfico sale por el túnel o se queda local.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Métrica de ruta o archivo obsoleto

El primer fallo es el archivo obsoleto. El resolver se escribió para el estado del adaptador al arrancar, y el túnel cambió ese estado. Su dirección stub puede ser ahora inalcanzable, o puede nombrar un servidor que no sabe nada de la zona interna.

El segundo es un problema de enrutamiento. Cuando la VPN añade una ruta que cubre la subred de WSL2 con una métrica inferior a la ruta de enlace del host, los paquetes dirigidos a la máquina virtual auxiliar entran en el túnel. Entonces expira cada servicio de WSL2, no solo el DNS.

La prueba que los distingue cuesta una línea. Si una dirección numérica como un resolver público sigue respondiendo al ping mientras los nombres fallan, la ruta está intacta y el problema es el DNS. Ese es el caso en que un cambio de resolver está justificado, y el caso en que no lo está también se vuelve obvio. Si la prueba numérica también falla, la máquina virtual auxiliar ha perdido su ruta y ningún archivo de resolver lo arreglará.

Para el caso de enrutamiento, quite la métrica automática del adaptador del túnel y dele un número por encima de la ruta de enlace de WSL2:

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

Apagarla importa. Cambiar la métrica no reescribe la máquina virtual auxiliar en marcha, así que la distribución debe reconstruirse antes de que el cambio sea visible.

Tome el archivo, deliberadamente

Si el enrutamiento es correcto y solo fallan los nombres internos, el resolver es el culpable y puede detener el generador. Es un cambio deliberado con un coste de mantenimiento, no un apaño para aplicar sin cuidado.

Cree /etc/wsl.conf dentro de la distribución con la sección de red que desactiva la generación, y luego escriba el archivo de resolver usted mismo, primero el servidor corporativo y después un público de reserva:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

El orden importa. Un resolver público no puede responder un nombre interno, y la reserva existe solo para consultas de internet. Una vez el archivo es suyo, nada lo regenera, así que un resolver corporativo que se muda se convierte en una caída que usted mismo debe notar.

Compruebe nombres y luego paquetes

Verifique un nombre interno y uno público con el resolver del sistema, y repita después la operación que falló. Los gestores de paquetes a veces usan un resolver propio, por eso un getent que funciona puede convivir con una instalación rota.

Si automatiza la reescritura, hágalo idempotente: sin túnel, conserve el archivo que ya existe en lugar de escribir una lista de servidores vacía.

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

Una consulta interna que funciona y una consulta pública que funciona, desde dentro de la distribución, es el resultado que merece registrarse. Un icono verde de VPN en el host no demuestra ninguna de las dos.