resolv.conf en WSL 2: el DNS muere cuando se conecta la VPN
WSL regenera resolv.conf a partir de los adaptadores de Windows que ve, así que el resolutor de la VPN puede no llegar nunca. Detén la generación y luego prueba un nombre corporativo.
Navegar dentro de la distribución funciona, y el primer nombre de host interno falla en el momento en que sube el túnel. El reflejo es añadir un resolutor público, que restaura internet y deja el nombre corporativo inalcanzable durante el resto del día. En WSL 2, /etc/resolv.conf es una salida generada y no una configuración, y ese es el mecanismo que merece entenderse. La solución no es un mejor resolutor, sino la propiedad del archivo.
El archivo se genera, no se configura
WSL 2 escribe el archivo al arrancar a partir de los adaptadores de Windows que ve en ese momento, e imprime un comentario arriba que lo dice. Cuando un cliente de VPN añade o reescribe un adaptador después, la distribución no necesariamente regenera nada, y el archivo sigue describiendo una red que ya no existe.
Un segundo modo de fallo es más silencioso: WSL puede copiar servidores solo de algunos adaptadores. Si el adaptador físico ya tiene un resolutor IPv6, los servidores IPv4 que aporta el adaptador de la VPN pueden descartarse en lugar de añadirse, y el archivo parece completo mientras omite justo el que responde a los nombres internos.
Compara la vista de Windows con la vista de Linux
Lee ambos lados antes de editar. Dentro de la distribución, mira qué contiene el archivo y si es un archivo normal o un enlace. En Windows, enumera el resolutor de cada adaptador, incluido el que creó la VPN:
ls -l /etc/resolv.conf
cat /etc/resolv.conf
Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'
Cuando el adaptador de la VPN muestra los servidores corporativos y Linux muestra otra cosa, la discrepancia está en la generación y no en el alcance. Compara la lista de adaptadores además de las direcciones, porque un adaptador ausente explica un servidor ausente. Esa distinción decide si reparas WSL o un cortafuegos, y ambas cosas no tienen nada en común.
Desactiva la generación y escribe tu propio archivo
Un ajuste documentado impide que WSL reescriba el archivo, y se encuentra en /etc/wsl.conf. Añade una sección de red a ese archivo:
[network]
generateResolvConf = false
Después termina la distribución desde Windows con wsl --shutdown y vuelve a iniciarla. Si la ruta es un enlace simbólico y no un archivo normal, elimina el enlace antes de escribir tu propio contenido, porque escribir a través del enlace puede recrear el objetivo generado en el siguiente arranque. Desde ese momento el archivo es tuyo y nada lo reescribe.
nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate
Sin un dominio de búsqueda, un nombre de host no cualificado se completa con la raíz pública y vuelve como que no existe tal dominio. timeout evita que un primer servidor muerto bloquee cada consulta, attempts limita cuántos intentos gasta una consulta, y rotate reparte los reintentos en lugar de empezar siempre por el primero. El intercambio es que el archivo ya no sigue a una VPN cuya dirección de resolutor cambia entre sesiones.
Gestiona un resolutor que se mueve y luego verifica
Algunos clientes entregan un resolutor específico de la sesión, así que un archivo estático se rompe en la siguiente conexión. Dos enfoques son defendibles. Escribe el archivo desde un script pequeño siempre que cambie la dirección, o deja la generación activada y asegúrate de que el adaptador del que copia WSL lleve el servidor corporativo. El segundo no necesita ningún gancho y falla cuando la generación omite el adaptador de la VPN; ambos siguen exigiendo resolver primero el conflicto de IPv6.
Windows también aplica sus propias directivas de nombres, como una lista de búsqueda de sufijos o una directiva de resolución para dominios concretos, y copiar las direcciones de los adaptadores no reproduce esas reglas. Si un nombre se resuelve en Windows y no en la distribución con el mismo servidor, compara el tratamiento de sufijos antes de culpar al túnel.
Prueba con un nombre y no con un paquete: getent hosts sensor-access0.corp.example pasa por la pila de resolutores, mientras que un ping puede tener éxito contra una dirección almacenada o literal. Luego repite tras desconectar y reconectar, porque un ajuste que funciona una vez y se regenera al reanudar nunca se arregló. Guarda el contenido anterior y anota qué componente posee la ruta en esa máquina, para que el siguiente cambio empiece con pruebas.