Kwa nini WSL hupoteza jina la mwenyeji wa kazi wakati VPN inaunganishwa?

Windows hutatua mwenyeji wa ndani bila malalamiko yoyote, na jina lilelile hushindwa ndani ya WSL katika dakika ambayo handaki linapoinuka. Suluhisho la kawaida ni kuandika kitatuzi cha umma ndani ya usambazaji, ambacho hurudisha uvinjari wa kawaida na hufanya jina la mwenyeji wa kazi lisiweze kutatuliwa. Hilo hubadilisha hitilafu moja na nyingine, na huficha tabaka ambalo kwa kweli lilivunjika. Kabla ya kuongeza au kuondoa mstari wowote wa kitatuzi, tambua ni tabaka gani kati ya matatu linaloshindwa.

Kwanza ondoa uwezekano wa hitilafu ya uelekezaji

Uliza jina lilelile lililostahiki kikamilifu pande zote mbili, sio majina mawili yanayofanana. Mafanikio katika Windows na kushindwa katika WSL kwa mfuatano uleule ni sahihi ya njia mbili za utatuzi, na ni machache mengine yanayozalisha muundo huo kwa usafi hivyo. Ikiwa WSL pia haiwezi kufikia huduma kwa anwani yake ya nambari inayojulikana, kuna pia tatizo la uelekezaji au uchujaji. Katika hali hiyo kazi ya DNS haitafichua, na mchana utaenda kwenye tabaka lisilofaa.

Dalili tatu hufunika mengi ya visa hivi, na kila moja huelekeza mahali tofauti. Soma safu inayolingana kabla ya kufungua faili ya usanidi:

Safu ya kati ndiyo ambayo watu huisoma vibaya, kwa sababu mabadiliko yaliyoivunja yalifanywa wiki kadhaa kabla na wakati huo yalionekana kuwa mafanikio. Safu ya tatu ndiyo ambayo watu huitambua vibaya, kwa sababu jina linalotatuliwa huonekana kama uthibitisho kwamba mtandao uko mzuri. Safu zote mbili zinakupeleka kwenye sehemu tofauti hapa chini.

Uhandakishaji wa DNS una kikomo cha chini cha toleo

Microsoft huandika hali ya mtandao ya WSL inayopitisha maombi ya DNS kwa kitatuzi cha Windows kupitia chaneli ya uboreshaji. Kwenye miundo ya Windows 11 inayotumika imewezeshwa kwa chaguo-msingi, ndiyo sababu mashine mbili kwenye mtandao mmoja wa shirika huishi tofauti. Kigezo ni namba ya muundo, sio sera ya shirika.

Mwongozo wa mtandao wa WSL unaeleza hali hiyo na matoleo yanayoiunga mkono. Kipengele hiki ni muhimu kwa sababu sera ya DNS ya shirika kawaida huishi kwenye kitatuzi cha Windows, na usambazaji unaorithi njia ya Windows hurithi pia sera hiyo. Usambazaji unaouliza kitatuzi cha umma hauna njia yoyote kuelekea jina la faragha, hata usanidi wake uonekane safi kiasi gani. Utaratibu huo unaeleza dalili yote, na unaeleza kwa nini suluhisho la kitatuzi cha umma hushindwa.

Soma muundo kabla ya kubadilisha chochote. Mpangilio ulionakiliwa kutoka usakinishaji mpya sio uthibitisho kwamba wa zamani unautekeleza. Andika namba ya muundo kando ya mabadiliko, kwa sababu tofauti kati ya mashine mbili karibu kila wakati ni toleo, sio sera.

Ubatilishaji wa zamani huishi muda mrefu kuliko tatizo walilolitatua

Mapishi ya zamani yalizima faili za kitatuzi zinazozalishwa, yaliandika kwa msimbo mgumu seva ya majina au yalifunga faili kwa sifa isiyobadilika. Mabadiliko hayo hubaki mahali pake muda mrefu baada ya tatizo la muunganisho lililoyasababisha kutoweka, na kawaida ndiyo sababu mpangilio mpya huonekana kama haufanyi chochote. Pia huishi baada ya usakinishaji upya wa usambazaji kwa namna ya wasifu wa shell unaoandika faili upya kwenye kila kuingia. La mwisho ni gumu zaidi kupatikana, kwa sababu halionekani kutoka kwenye faili ambayo kila mtu huikagua.

Tafuta faili ya kitatuzi iliyoandikwa kwa mkono, sifa isiyobadilika juu yake, na skripti ya kuanzisha inayoandika upya. Angalia bendera isiyobadilika kabla ya kuhariri, kwa sababu kuandika kwenye faili iliyofungwa hushindwa kwa namna inayosomwa kama tatizo la ruhusa. Kisha angalia wasifu wa shell, kwa sababu skripti hapo hurudisha maudhui ya zamani ndani ya sekunde chache baada ya marekebisho yako.

Kuondoa ubatilishaji kuna matokeo, kwa hiyo andika ulichoondoa na kwa nini. Usambazaji unaohitaji kwa kweli kitatuzi tuli kwa madhumuni mengine utavunjika wakati faili iliyozalishwa inarudi.

Faili mbili, majukumu mawili tofauti

Faili mbili za usanidi huishi mahali tofauti na hudhibiti vitu tofauti, na kuzichanganya huzalisha uhariri unaotumika kwenye tabaka lisilofaa. Faili ya upande wa Windows huweka sifa za mashine pepe, wakati faili ya upande wa usambazaji huweka jinsi usambazaji huo unajenga usanidi wake wa kitatuzi. Hakuna inayobatilisha nyingine, ndiyo sababu zote mbili lazima zikubaliane.

Kwa usakinishaji unaounga mkono kipengele, kipande cha upande wa Windows ni kifupi. Hicho ndicho mabadiliko yote upande huo:

[wsl2]
dnsTunneling=true

Kipande hicho ni cha wasifu wa mtumiaji wa Windows na kinatumika kwa mashine pepe sio kwa usambazaji mmoja. Uhandakishaji pia unahitaji kwamba usambazaji haujazima uundaji wa kitatuzi, kwa hiyo faili ya upande wa usambazaji lazima iachie tabia hiyo kwa utulivu. Badilisha kimoja bila kingine na hali hiyo hufanya kitu chochote kimyakimya, na hiyo ndiyo njia ya kawaida zaidi ambayo marekebisho haya huripotiwa kuwa yamevunjika. Angalia faili zote mbili katika kikao kimoja, kwa sababu uhariri mbili zilizofanywa kwa wiki tofauti ni uhariri mbili ambazo hakuna mtu anayeweza kuzihusisha.

Anzisha upya, kisha uliza kutoka pande zote mbili

Mipangilio hii husomwa wakati mazingira yanapoanza, kwa hiyo shell mpya ndani ya usambazaji unaoendelea haitapakia upya. Zima mazingira badala ya kuanzisha upya shell, na kwanza hifadhi kazi yoyote inayoendelea kwa sababu kila usambazaji husimama nayo. Kuacha huku peke yake kunaeleza ripoti nyingi kwamba mabadiliko hayana athari.

Kisha uliza swali lilelile kutoka pande zote mbili. Matokeo pia yanaonyesha kitatuzi ambacho usambazaji uliishia nacho:

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'

Amri ya kwanza humaliza mazingira, ya pili inaonyesha kitatuzi ambacho usambazaji unatumia sasa, na mbili za mwisho huuliza swali lilelile kwa kila upande. Linganisha majibu sio hali ya mpangilio. Swali ambalo bado hushindwa baada ya kuanzisha upya safi wakati faili zote mbili ni sahihi huelekeza kwenye sera ya kitatuzi ya shirika, na mazungumzo hayo yana mmiliki mwingine.