Per què WSL perd el nom d’amfitrió de treball quan es connecta la VPN?

Windows resol l’amfitrió intern sense cap queixa, i el mateix nom falla dins de WSL en el moment que s’aixeca el túnel. La reparació habitual és escriure un resolutor públic dins de la distribució, cosa que restaura la navegació normal i fa que el nom d’amfitrió de treball sigui impossible de resoldre. Això intercanvia una fallada per una altra i amaga la capa que realment s’ha trencat. Abans d’afegir o treure qualsevol línia de resolutor, esbrineu quina de les tres capes falla.

Descarteu primer una fallada d’encaminament

Consulteu el mateix nom completament qualificat als dos costats, no dos noms que s’assemblen. Un èxit a Windows i una fallada a WSL per a la mateixa cadena és la signatura de dos camins de resolució, i poques coses més produeixen aquest patró amb tanta netedat. Si WSL tampoc no pot arribar al servei a la seva adreça numèrica coneguda, també hi ha un problema d’encaminament o de filtratge. En aquest cas la feina de DNS no ho revelarà, i la tarda se’n va a la capa equivocada.

Tres símptomes cobreixen la majoria d’aquests casos, i cadascun apunta a un lloc diferent. Llegiu la fila que correspongui abans d’obrir un fitxer de configuració:

La fila del mig és la que la gent llegeix malament, perquè el canvi que la va trencar es va fer setmanes abans i llavors va semblar un èxit. La tercera fila és la que la gent diagnostica malament, perquè un nom que es resol sembla una prova que la xarxa és sana. Totes dues files us porten a una secció diferent més avall.

El túnel DNS té un mínim de versió

Microsoft documenta un mode de xarxa de WSL que tunelitza les peticions DNS cap al resolutor de Windows a través d’un canal de virtualització. A les compilacions compatibles de Windows 11 està activat per defecte, i per això dues màquines de la mateixa xarxa corporativa es comporten de manera diferent. La variable és el número de compilació, no la política corporativa.

La guia de xarxes de WSL descriu aquest mode i les versions que el suporten. La funció importa perquè la política DNS corporativa sol viure al resolutor de Windows, i una distribució que hereta el camí de Windows n’hereta la política. Una distribució que consulta un resolutor públic no té cap ruta cap a un nom privat, per molt polida que sembli la seva pròpia configuració. Aquest mecanisme explica tot el símptoma i explica per què falla la solució alternativa del resolutor públic.

Llegiu la compilació abans d’editar res. Una opció copiada d’una instal·lació més nova no és prova que una de més antiga la implementi. Anoteu la compilació al costat del canvi, perquè la diferència entre dues màquines gairebé sempre és una versió i no una política.

Les anul·lacions antigues sobreviuen al problema que van resoldre

Les receptes més antigues desactivaven els fitxers de resolutor generats, fixaven un servidor de noms a mà o bloquejaven el fitxer amb un atribut immutable. Aquests canvis es queden al lloc molt després que hagi desaparegut el problema de connectivitat que els va motivar, i normalment són la raó per la qual una opció més nova sembla que no fa res. També sobreviuen a una reinstal·lació de la distribució en forma d’un perfil d’intèrpret d’ordres que reescriu el fitxer a cada inici de sessió. Aquest últim és el més difícil de trobar, perquè és invisible des del fitxer que tothom inspecciona.

Busqueu un fitxer de resolutor escrit a mà, un atribut immutable al damunt i un script d’inici que el reescrigui. Comproveu el flag immutable abans d’editar, perquè una escriptura en un fitxer bloquejat falla d’una manera que es llegeix com un problema de permisos. Comproveu després el perfil d’intèrpret d’ordres, perquè un script d’allà restaura el contingut antic en qüestió de segons després de la vostra reparació.

Treure una anul·lació té conseqüències, així que anoteu què heu tret i per què. Una distribució que realment necessiti un resolutor estàtic per a una altra finalitat es trencarà quan torni el fitxer generat.

Dos fitxers, dos papers diferents

Els dos fitxers de configuració viuen en llocs diferents i controlen coses diferents, i confondre’ls produeix edicions aplicades a la capa equivocada. El fitxer del costat de Windows estableix propietats de la màquina virtual, mentre que el fitxer del costat de la distribució estableix com aquesta distribució construeix la seva pròpia configuració de resolutor. Cap dels dos anul·la l’altre, i per això tots dos han d’estar d’acord.

Per a una instal·lació que admet la funció, el fragment del costat de Windows és curt. És tot el canvi en aquest costat:

[wsl2]
dnsTunneling=true

Aquest fragment va al perfil d’usuari de Windows i s’aplica a la màquina virtual, no a una sola distribució. El túnel també requereix que la distribució no hagi desactivat la generació de resolutor, així que el fitxer del costat de la distribució ha de deixar aquest comportament tranquil. Canvieu-ne un sense l’altre i el mode no fa res en silenci, que és la manera més habitual que aquesta reparació es reporti com a trencada. Comproveu tots dos fitxers a la mateixa sessió, perquè dues edicions fetes amb setmanes de diferència són dues edicions que ningú no pot atribuir.

Reinicieu i després consulteu des dels dos costats

Aquestes opcions es llegeixen quan arrenca l’entorn, així que un intèrpret d’ordres nou dins d’una distribució en marxa no les recarregarà. Apagueu l’entorn en lloc de reiniciar l’intèrpret d’ordres, i deseu primer qualsevol feina en curs perquè cada distribució s’atura amb ell. Aquesta omissió sola explica la majoria d’informes que un canvi no té cap efecte.

Després feu la mateixa pregunta des dels dos costats. La sortida també mostra amb quin resolutor s’ha quedat realment la distribució:

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'

La primera ordre acaba l’entorn, la segona mostra quin resolutor fa servir ara la distribució, i les dues últimes fan la mateixa pregunta a cada costat. Compareu les respostes, no l’estat de l’opció. Una consulta que encara falla després d’un reinici net amb tots dos fitxers correctes apunta a la política de resolutor corporativa, i aquesta conversa té un altre propietari.