Miksi WSL menettää työn isäntänimen, kun VPN yhdistyy?

Windows ratkaisee sisäisen isännän ilman mitään valitusta, ja sama nimi epäonnistuu WSL:n sisällä sinä hetkenä, kun tunneli nousee. Tavallinen korjaus on kirjoittaa julkinen ratkaisija jakeluun, mikä palauttaa tavallisen selailun ja tekee työn isäntänimestä ratkaisemattoman. Se vaihtaa yhden vian toiseen ja kätkee kerroksen, joka todella hajosi. Ennen kuin lisäät tai poistat yhtään ratkaisijariviä, selvitä, mikä kolmesta kerroksesta epäonnistuu.

Sulje ensin pois reititysvika

Kysy sama täysin kelvollinen nimi molemmilta puolilta, älä kahta samannäköistä nimeä. Onnistuminen Windowsissa ja epäonnistuminen WSL:ssä samalle merkkijonolle on kahden ratkaisupolun allekirjoitus, ja harva muu asia tuottaa sitä kuviota yhtä puhtaasti. Jos WSL ei pääse palveluun myöskään sen tunnetulla numeerisella osoitteella, myös reititys- tai suodatusongelma on läsnä. Siinä tapauksessa DNS-työ ei paljasta sitä, ja iltapäivä menee väärään kerrokseen.

Kolme oiretta kattaa useimmat näistä tapauksista, ja jokainen osoittaa eri paikkaan. Lue sopiva rivi ennen kuin avaat asetustiedoston:

Keskimmäisen rivin ihmiset lukevat väärin, koska sen rikkonut muutos tehtiin viikkoja aiemmin ja näytti silloin onnistuneelta. Kolmannen rivin ihmiset diagnosoivat väärin, koska ratkeava nimi tuntuu todisteelta siitä, että verkko on terve. Molemmat rivit lähettävät sinut eri osioon alempana.

DNS-tunnelilla on vähimmäisversio

Microsoft dokumentoi WSL-verkkotilan, joka tunneloi DNS-pyynnöt Windowsin ratkaisijaan virtualisointikanavan kautta. Tuetuissa Windows 11 -koontiversioissa se on oletuksena käytössä, minkä vuoksi kaksi konetta samassa yritysverkossa käyttäytyvät eri tavoin. Muuttuja on koontiversion numero, ei yrityskäytäntö.

WSL-verkko-opas kuvaa tätä tilaa ja versioita, jotka tukevat sitä. Ominaisuus on tärkeä, koska yrityksen DNS-käytäntö asuu yleensä Windowsin ratkaisijassa, ja jakelu, joka perii Windowsin polun, perii käytännön mukanaan. Julkista ratkaisijaa kysyvässä jakelussa ei ole reittiä yksityiseen nimeen, oli sen oma asetustiedosto kuinka siisti tahansa. Tämä mekanismi selittää koko oireen ja selittää, miksi julkisen ratkaisijan kiertotie epäonnistuu.

Lue koontiversio ennen kuin muutat mitään. Uudemmasta asennuksesta kopioitu asetus ei ole todiste siitä, että vanhempi toteuttaa sen. Kirjaa koontiversio muutoksen viereen, koska kahden koneen ero on lähes aina versio eikä käytäntö.

Vanhat ohitukset elävät kauemmin kuin ratkaisemansa ongelma

Vanhemmat reseptit poistivat käytöstä luodut ratkaisijatiedostot, kovakoodasivat nimipalvelimen tai lukitsivat tiedoston muuttumattomuusattribuutilla. Nämä muutokset pysyvät paikallaan kauan sen jälkeen, kun ne aiheuttanut yhteysongelma on kadonnut, ja ne ovat yleensä syy siihen, miksi uudempi asetus näyttää tekevän ei mitään. Ne selviävät myös jakelun uudelleenasennuksesta shell-profiilin muodossa, joka kirjoittaa tiedoston uudelleen joka kirjautumisella. Viimeisin on vaikein löytää, koska se on näkymätön siitä tiedostosta, jota kaikki tarkistavat.

Etsi käsin kirjoitettu ratkaisijatiedosto, siinä oleva muuttumattomuusattribuutti ja käynnistyskomentosarja, joka kirjoittaa sen uudelleen. Tarkista muuttumattomuuslippu ennen muokkausta, koska lukittuun tiedostoon kirjoittaminen epäonnistuu tavalla, joka luetaan käyttöoikeusongelmaksi. Tarkista sen jälkeen shell-profiili, koska siellä oleva komentosarja palauttaa vanhan sisällön sekunneissa korjauksesi jälkeen.

Ohituksen poistamisella on seurauksia, joten kirjaa, mitä poistit ja miksi. Jakelu, joka todella tarvitsee staattisen ratkaisijan toiseen tarkoitukseen, hajoaa, kun luotu tiedosto palaa.

Kaksi tiedostoa, kaksi eri roolia

Kaksi asetustiedostoa asuvat eri paikoissa ja ohjaavat eri asioita, ja niiden sekoittaminen tuottaa muokkauksia, jotka kohdistuvat väärään kerrokseen. Windowsin puolen tiedosto asettaa virtuaalikoneen ominaisuudet, kun taas jakelun puolen tiedosto asettaa, miten kyseinen jakelu rakentaa oman ratkaisija-asetuksensa. Kumpikaan ei ohita toistaan, minkä vuoksi molempien on oltava yhtä mieltä.

Asennukselle, joka tukee ominaisuutta, Windowsin puolen katkelma on lyhyt. Se on koko muutos sillä puolella:

[wsl2]
dnsTunneling=true

Tämä katkelma kuuluu Windowsin käyttäjäprofiiliin ja koskee virtuaalikonetta eikä yksittäistä jakelua. Tunnelointi edellyttää myös, että jakelu ei ole poistanut ratkaisijan luontia käytöstä, joten jakelun puolen tiedoston on jätettävä tämä käyttäytyminen rauhaan. Muuta toista ilman toista, niin tila ei tee hiljaa mitään, ja se on tavallisin tapa, jolla tämä korjaus raportoidaan rikkinäisenä. Tarkista molemmat tiedostot samassa istunnossa, koska viikkojen välein tehdyt kaksi muokkausta ovat kaksi muokkausta, joita kukaan ei voi kohdistaa.

Käynnistä uudelleen ja kysy sitten molemmilta puolilta

Nämä asetukset luetaan, kun ympäristö käynnistyy, joten käynnissä olevan jakelun sisällä uusi shell ei lataa niitä uudelleen. Sammuta ympäristö sen sijaan, että käynnistäisit shellin uudelleen, ja tallenna ensin mahdollinen käynnissä oleva työ, koska jokainen jakelu pysähtyy sen mukana. Pelkästään tämä laiminlyönti selittää useimmat raportit siitä, että muutoksella ei ole vaikutusta.

Esitä sitten sama kysymys molemmilta puolilta. Tuloste näyttää myös, mihin ratkaisijaan jakelu todella päätyi:

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'

Ensimmäinen komento lopettaa ympäristön, toinen näyttää, mitä ratkaisijaa jakelu nyt käyttää, ja kaksi viimeistä esittävät saman kysymyksen kummallekin puolelle. Vertaa vastauksia, älä asetuksen tilaa. Kysely, joka epäonnistuu edelleen puhtaan uudelleenkäynnistyksen jälkeen molempien tiedostojen ollessa oikein, osoittaa yrityksen ratkaisijakäytäntöön, ja sillä keskustelulla on eri omistaja.