Windows atrisina iekšējo resursdatoru bez jebkādām sūdzībām, un tas pats nosaukums WSL iekšienē neizdodas tajā mirklī, kad tunele ir pacelts. Ierastais labojums ir ierakstīt distribūcijā publisku atrisinātāju, kas atjauno parasto pārlūkošanu un padara darba resursdatora nosaukumu neatrisināmu. Tas apmaina vienu kļūmi pret citu un noslēpj slāni, kas patiešām sabruka. Pirms pievienojat vai noņemat jebkuru atrisinātāja rindu, noskaidrojiet, kurš no trim slāņiem neizdodas.

Vispirms izslēdziet maršrutēšanas kļūmi

Vaicājiet to pašu pilnībā kvalificēto nosaukumu abās pusēs, nevis divus līdzīgus nosaukumus. Panākumi Windows un neveiksme WSL vienai un tai pašai virknei ir divu atrisināšanas ceļu paraksts, un maz kas cits rada šo modeli tik tīri. Ja WSL nevar sasniegt pakalpojumu arī tā zināmajā skaitliskajā adresē, pastāv arī maršrutēšanas vai filtrēšanas problēma. Tādā gadījumā DNS darbs to neatklās, un pēcpusdiena aizies nepareizajā slānī.

Trīs simptomi aptver lielāko daļu šo gadījumu, un katrs norāda uz citu vietu. Pirms atverat konfigurācijas failu, izlasiet atbilstošo rindu:

Symptom inside WSLLikely layerWhere to look
Private name fails while public browsing worksResolver pathTunneling mode and the Windows build
A name that worked yesterday fails todayStale overrideGenerated resolver file, immutable flag, shell profile
The name resolves but the service does notRouting or filteringThe resolved address and the path to it

Vidējā rinda ir tā, kuru cilvēki izlasa nepareizi, jo to salauzušais lēmums tika pieņemts nedēļas iepriekš un toreiz šķita veiksmīgs. Trešā rinda ir tā, kurai cilvēki uzstāda nepareizu diagnozi, jo atrisināts nosaukums šķiet kā pierādījums, ka tīkls ir vesels. Abas rindas sūta jūs uz citu sadaļu zemāk.

DNS tuneļošanai ir minimālā versijas robeža

Microsoft dokumentē WSL tīkla režīmu, kas tunelē DNS pieprasījumus uz Windows atrisinātāju caur virtualizācijas kanālu. Atbalstītajos Windows 11 būvējumos tas ir iespējots pēc noklusējuma, tāpēc divas mašīnas vienā uzņēmuma tīklā uzvedas atšķirīgi. Mainīgais ir būvējuma numurs, nevis uzņēmuma politika.

WSL tīkla rokasgrāmata apraksta šo režīmu un versijas, kas to atbalsta. Šī funkcija ir svarīga, jo uzņēmuma DNS politika parasti mīt Windows atrisinātājā, un distribūcija, kas manto Windows ceļu, manto arī politiku. Distribūcijai, kas vaicā publisku atrisinātāju, nav neviena ceļa uz privātu nosaukumu, lai cik kārtīga izskatītos tās pašas konfigurācija. Šis mehānisms izskaidro visu simptomu un izskaidro, kāpēc publiskā atrisinātāja apiešana neizdodas.

Izlasiet būvējumu, pirms kaut ko rediģējat. No jaunākas instalācijas nokopēts iestatījums nav pierādījums, ka vecāka to īsteno. Pierakstiet būvējuma numuru blakus izmaiņai, jo divu mašīnu atšķirība gandrīz vienmēr ir versija, nevis politika.

Vecie pārraksti pārdzīvo problēmu, kuru tie atrisināja

Vecākas receptes atspējoja ģenerētos atrisinātāja failus, iekodēja vārdu serveri vai bloķēja failu ar nemaināmu atribūtu. Šīs izmaiņas paliek savā vietā ilgi pēc tam, kad problēma ar savienojumu, kas tās izraisīja, ir pazudusi, un parasti tieši tās ir iemesls, kāpēc jaunāks iestatījums šķiet neko nedarām. Tās pārdzīvo arī distribūcijas pārinstalēšanu shell profila formā, kas pārraksta failu pie katras pieteikšanās. Pēdējo ir visgrūtāk atrast, jo tas nav redzams no faila, kuru visi pārbauda.

Meklējiet ar roku rakstītu atrisinātāja failu, nemaināmu atribūtu uz tā un palaišanas skriptu, kas to pārraksta. Pirms rediģēšanas pārbaudiet nemaināmības karodziņu, jo rakstīšana bloķētā failā neizdodas tā, ka to nolasa kā atļauju problēmu. Pēc tam pārbaudiet shell profilu, jo skripts tur atjauno veco saturu dažu sekunžu laikā pēc jūsu labojuma.

Pārraksta noņemšanai ir sekas, tāpēc pierakstiet, ko noņēmāt un kāpēc. Distribūcija, kurai patiešām vajadzīgs statisks atrisinātājs citam mērķim, sabruks, kad ģenerētais fails atgriezīsies.

Divi faili, divas dažādas lomas

Abi konfigurācijas faili mīt dažādās vietās un kontrolē dažādas lietas, un to sajaukšana rada labojumus, kas tiek piemēroti nepareizajam slānim. Windows puses fails iestata virtuālās mašīnas īpašības, bet distribūcijas puses fails iestata, kā šī distribūcija veido savu atrisinātāja konfigurāciju. Neviens neaizstāj otru, tāpēc abiem jāsaskan.

Instalācijai, kas atbalsta šo funkciju, Windows puses fragments ir īss. Tas ir viss labojums tajā pusē:

[wsl2]
dnsTunneling=true

Šis fragments pieder Windows lietotāja profilam un attiecas uz virtuālo mašīnu, nevis uz vienu distribūciju. Tuneļošana arī prasa, lai distribūcija nebūtu atspējojusi atrisinātāja ģenerēšanu, tāpēc distribūcijas puses failam šī uzvedība jāatstāj mierā. Nomainiet vienu bez otra, un režīms klusi neko nedara, un tas ir visizplatītākais veids, kā šis labojums tiek ziņots kā salauzts. Pārbaudiet abus failus tajā pašā sesijā, jo divi labojumi, kas izdarīti ar nedēļu starpību, ir divi labojumi, kurus neviens nevar piedēvēt.

Pārstartējiet, tad vaicājiet no abām pusēm

Šie iestatījumi tiek lasīti, kad vide startē, tāpēc jauns shell darbojošā distribūcijā tos nepārlādēs. Izslēdziet vidi, nevis pārstartējiet shell, un vispirms saglabājiet jebkuru darbojošos darbu, jo katra distribūcija apstājas kopā ar to. Vien šī izlaišana izskaidro lielāko daļu ziņojumu, ka izmaiņām nav efekta.

Pēc tam uzdodiet to pašu jautājumu no abām pusēm. Izvade arī parāda, ar kuru atrisinātāju distribūcija patiešām nonāca:

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'

Pirmā komanda beidz vidi, otrā parāda, kuru atrisinātāju distribūcija tagad izmanto, un pēdējās divas uzdod to pašu jautājumu katrai pusei. Salīdziniet atbildes, nevis iestatījuma statusu. Vaicājums, kas joprojām neizdodas pēc tīras pārstartēšanas ar abiem pareizajiem failiem, norāda uz uzņēmuma atrisinātāja politiku, un šai sarunai ir cits īpašnieks.

Saistītie raksti