Por que WSL perde o nome de host de traballo cando se conecta a VPN?

Windows resolve o host interno sen ningunha queixa, e o mesmo nome falla dentro de WSL no momento en que se ergue o túnel. A reparación habitual é escribir un resolutor público dentro da distribución, o que restaura a navegación normal e fai que o nome de host de traballo sexa imposible de resolver. Iso cambia un fallo por outro e oculta a capa que realmente se rompeu. Antes de engadir ou quitar calquera liña de resolutor, averigüe cal das tres capas está a fallar.

Descarte primeiro un fallo de encamiñamento

Consulte o mesmo nome completamente cualificado en ambos os lados, non dous nomes que se parezan. Un éxito en Windows e un fallo en WSL para a mesma cadea é a sinatura de dúas rutas de resolución, e poucas cousas máis producen ese patrón con tanta limpeza. Se WSL tampouco pode alcanzar o servizo no seu enderezo numérico coñecido, tamén hai un problema de encamiñamento ou de filtrado. Nese caso o traballo de DNS non o revelará, e a tarde vaise á capa equivocada.

Tres síntomas cobren a maioría destes casos, e cada un apunta a un sitio distinto. Lea a fila que corresponda antes de abrir un ficheiro de configuración:

A fila central é a que a xente le mal, porque o cambio que a rompeu fixérase semanas antes e daquela parecía exitoso. A terceira fila é a que a xente diagnostica mal, porque un nome que se resolve parece proba de que a rede está san. Ambas as filas lévanlle a unha sección distinta máis abaixo.

O túnel DNS ten un mínimo de versión

Microsoft documenta un modo de rede de WSL que tuneliza as peticións DNS cara ao resolutor de Windows a través dunha canle de virtualización. Nas compilacións compatibles de Windows 11 está activado por defecto, e por iso dúas máquinas da mesma rede corporativa compórtanse de forma distinta. A variable é o número de compilación, non a política corporativa.

A guía de redes de WSL describe ese modo e as versións que o admiten. A función importa porque a política DNS corporativa adoita vivir no resolutor de Windows, e unha distribución que herda a ruta de Windows herda a política con ela. Unha distribución que consulta un resolutor público non ten ruta cara a un nome privado, por moi ordenada que pareza a súa propia configuración. Ese mecanismo explica todo o síntoma e explica por que falla a solución alternativa do resolutor público.

Lea a compilación antes de editar nada. Un axuste copiado dunha instalación máis recente non é proba de que unha máis antiga o implemente. Anote a compilación xunto ao cambio, porque a diferenza entre dúas máquinas case sempre é unha versión e non unha política.

As anulacións antigas sobreviven ao problema que resolveron

As receitas máis antigas desactivaban os ficheiros de resolutor xerados, fixaban un servidor de nomes a man ou bloqueaban o ficheiro cun atributo inmutable. Eses cambios permanecen moito despois de que desapareza o problema de conectividade que os motivou, e adoitan ser a razón de que un axuste máis recente pareza non facer nada. Tamén sobreviven a unha reinstalación da distribución en forma de perfil de shell que reescribe o ficheiro en cada inicio de sesión. Este último é o máis difícil de atopar, porque é invisible desde o ficheiro que todo o mundo inspecciona.

Busque un ficheiro de resolutor escrito a man, un atributo inmutable sobre el e un script de inicio que o reescriba. Comprobe o flag inmutable antes de editar, porque unha escritura nun ficheiro bloqueado falla dunha forma que se le como un problema de permisos. Comprobe despois o perfil de shell, porque un script alí restaura o contido antigo en cuestión de segundos tras a súa corrección.

Quitar unha anulación ten consecuencias, así que anote que quitou e por que. Unha distribución que de verdade necesite un resolutor estático para outro propósito romperase cando volva o ficheiro xerado.

Dous ficheiros, dous papeis distintos

Os dous ficheiros de configuración viven en lugares distintos e controlan cousas distintas, e confundilos produce edicións aplicadas á capa equivocada. O ficheiro do lado de Windows establece propiedades da máquina virtual, mentres que o ficheiro do lado da distribución establece como esa distribución constrúe a súa propia configuración de resolutor. Ningún anula o outro, por iso ambos deben coincidir.

Para unha instalación que admite a función, o fragmento do lado de Windows é curto. É todo o cambio nese lado:

[wsl2]
dnsTunneling=true

Ese fragmento vai no perfil de usuario de Windows e aplícase á máquina virtual, non a unha soa distribución. O túnel tamén esixe que a distribución non teña desactivado a xeración de resolutor, así que o ficheiro do lado da distribución debe deixar ese comportamento en paz. Cambie un sen o outro e o modo non fai nada en silencio, que é a forma máis habitual de que esta reparación se informe como rota. Comprobe ambos os ficheiros na mesma sesión, porque dúas edicións feitas con semanas de diferenza son dúas edicións que ninguén pode atribuír.

Reinicie e logo consulte desde ambos os lados

Estes axustes len cando arranca a contorna, así que un shell novo dentro dunha distribución en marcha non os recargará. Apague a contorna en lugar de reiniciar o shell, e garde primeiro calquera traballo en curso porque cada distribución detense con el. Esa omisión por si soa explica a maioría dos informes de que un cambio non ten efecto.

Despois faga a mesma pregunta desde ambos os lados. A saída tamén mostra con que resolutor quedou realmente a 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'

O primeiro comando termina a contorna, o segundo mostra que resolutor usa agora a distribución, e os dous últimos formulan a mesma pregunta a cada lado. Compare as respostas e non o estado do axuste. Unha consulta que segue fallando tras un reinicio limpo cos dous ficheiros correctos apunta á política de resolutor corporativa, e esa conversa ten outro dono.