¿Por qué WSL pierde el nombre de host de trabajo cuando se conecta la VPN?

Windows resuelve el host interno sin queja alguna, y el mismo nombre falla dentro de WSL en el momento en que se levanta el túnel. La reparación habitual es escribir un resolutor público dentro de la distribución, lo que restaura la navegación normal y hace que el nombre de host de trabajo sea imposible de resolver. Eso cambia un fallo por otro y oculta la capa que realmente se rompió. Antes de añadir o quitar cualquier línea de resolutor, averigüe cuál de las tres capas está fallando.

Descarte primero un fallo de enrutamiento

Consulte el mismo nombre completamente cualificado en ambos lados, no dos nombres que se parezcan. Un éxito en Windows y un fallo en WSL para la misma cadena es la firma de dos rutas de resolución, y pocas cosas más producen ese patrón con tanta limpieza. Si WSL tampoco puede alcanzar el servicio en su dirección numérica conocida, también hay un problema de enrutamiento o de filtrado. En ese caso el trabajo de DNS no lo revelará, y la tarde se va a la capa equivocada.

Tres síntomas cubren la mayoría de estos casos, y cada uno apunta a un sitio distinto. Lea la fila que corresponda antes de abrir un archivo de configuración:

La fila central es la que la gente lee mal, porque el cambio que la rompió se hizo semanas antes y en su momento pareció exitoso. La tercera fila es la que la gente diagnostica mal, porque un nombre que se resuelve parece prueba de que la red está sana. Ambas filas le llevan a una sección distinta más abajo.

El túnel DNS tiene un mínimo de versión

Microsoft documenta un modo de red de WSL que tuneliza las peticiones DNS hacia el resolutor de Windows a través de un canal de virtualización. En las compilaciones compatibles de Windows 11 está activado por defecto, y por eso dos máquinas de la misma red corporativa se comportan de forma distinta. La variable es el número de compilación, no la política corporativa.

La guía de redes de WSL describe ese modo y las versiones que lo admiten. La función importa porque la política DNS corporativa suele vivir en el resolutor de Windows, y una distribución que hereda la ruta de Windows hereda la política con ella. Una distribución que consulta un resolutor público no tiene ruta hacia un nombre privado, por muy ordenada que parezca su propia configuración. Ese mecanismo explica todo el síntoma y explica por qué falla la solución alternativa del resolutor público.

Lea la compilación antes de editar nada. Un ajuste copiado de una instalación más reciente no es prueba de que una más antigua lo implemente. Anote la compilación junto al cambio, porque la diferencia entre dos máquinas casi siempre es una versión y no una política.

Las anulaciones antiguas sobreviven al problema que resolvieron

Las recetas más antiguas desactivaban los archivos de resolutor generados, fijaban un servidor de nombres a mano o bloqueaban el archivo con un atributo inmutable. Esos cambios permanecen mucho después de que haya desaparecido el problema de conectividad que los motivó, y suelen ser la razón de que un ajuste más reciente parezca no hacer nada. También sobreviven a una reinstalación de la distribución en forma de perfil de shell que reescribe el archivo en cada inicio de sesión. Este último es el más difícil de encontrar, porque es invisible desde el archivo que todo el mundo inspecciona.

Busque un archivo de resolutor escrito a mano, un atributo inmutable sobre él y un script de inicio que lo reescriba. Compruebe el flag inmutable antes de editar, porque una escritura en un archivo bloqueado falla de una forma que se lee como un problema de permisos. Compruebe después el perfil de shell, porque un script allí restaura el contenido antiguo en cuestión de segundos tras su corrección.

Quitar una anulación tiene consecuencias, así que anote qué quitó y por qué. Una distribución que de verdad necesite un resolutor estático para otro propósito se romperá cuando vuelva el archivo generado.

Dos archivos, dos papeles distintos

Los dos archivos de configuración viven en lugares distintos y controlan cosas distintas, y confundirlos produce ediciones aplicadas a la capa equivocada. El archivo del lado de Windows establece propiedades de la máquina virtual, mientras que el archivo del lado de la distribución establece cómo esa distribución construye su propia configuración de resolutor. Ninguno anula al otro, por eso ambos tienen que coincidir.

Para una instalación que admite la función, el fragmento del lado de Windows es corto. Es todo el cambio en ese lado:

[wsl2]
dnsTunneling=true

Ese fragmento va en el perfil de usuario de Windows y se aplica a la máquina virtual, no a una sola distribución. El túnel también exige que la distribución no haya desactivado la generación de resolutor, así que el archivo del lado de la distribución debe dejar ese comportamiento en paz. Cambie uno sin el otro y el modo no hace nada en silencio, que es la forma más habitual de que esta reparación se reporte como rota. Compruebe ambos archivos en la misma sesión, porque dos ediciones hechas con semanas de diferencia son dos ediciones que nadie puede atribuir.

Reinicie y luego consulte desde ambos lados

Estos ajustes se leen cuando arranca el entorno, así que un shell nuevo dentro de una distribución en marcha no los recargará. Apague el entorno en lugar de reiniciar el shell, y guarde primero cualquier trabajo en curso porque cada distribución se detiene con él. Esa omisión por sí sola explica la mayoría de los informes de que un cambio no tiene efecto.

Después haga la misma pregunta desde ambos lados. La salida también muestra con qué resolutor se quedó realmente la distribución:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

El primer comando termina el entorno, el segundo muestra qué resolutor usa ahora la distribución, y los dos últimos plantean la misma pregunta a cada lado. Compare las respuestas y no el estado del ajuste. Una consulta que sigue fallando tras un reinicio limpio con ambos archivos correctos apunta a la política de resolutor corporativa, y esa conversación tiene otro dueño.