Kodėl WSL praranda darbo hosto vardą, kai prisijungia VPN?

Windows išsprendžia vidinį hostą be jokių priekaištų, o tas pats vardas WSL viduje nepavyksta tą akimirką, kai pakyla tunelis. Įprastas taisymas – į distribuciją įrašyti viešą resolvatorių, kuris atkuria įprastą naršymą ir darbo hosto vardą padaro neišsprendžiamą. Tai iškeičia vieną gedimą į kitą ir paslepia sluoksnį, kuris iš tikrųjų lūžo. Prieš pridėdami ar pašalindami bet kurią resolvatoriaus eilutę, nustatykite, kuris iš trijų sluoksnių nepavyksta.

Pirmiausia atmeskite maršrutizavimo gedimą

Užklauskite to paties visiškai kvalifikuoto vardo abiejose pusėse, o ne dviejų panašių vardų. Sėkmė Windows ir nesėkmė WSL tam pačiam stringui yra dviejų sprendimo kelių parašas, ir mažai kas kita sukuria šį modelį taip švariai. Jei WSL negali pasiekti paslaugos ir žinomu skaitiniu adresu, taip pat yra maršrutizavimo arba filtravimo problema. Tokiu atveju DNS darbas to neatskleis, ir popietė nueis į netinkamą sluoksnį.

Trys simptomai apima daugumą šių atvejų, ir kiekvienas rodo į skirtingą vietą. Prieš atidarydami konfigūracijos failą perskaitykite atitinkamą eilutę:

Vidurinė eilutė yra ta, kurią žmonės perskaito neteisingai, nes ją sulaužęs pakeitimas buvo padarytas prieš savaites ir tada atrodė sėkmingas. Trečioji eilutė yra ta, kurią žmonės diagnozuoja neteisingai, nes išsprendžiamas vardas atrodo kaip įrodymas, kad tinklas sveikas. Abi eilutės nukreipia jus į skirtingą skyrių žemiau.

DNS tuneliavimas turi minimalią versijos ribą

Microsoft dokumentuoja WSL tinklo režimą, kuris per virtualizacijos kanalą tuneliuoja DNS užklausas į Windows resolvatorių. Palaikomuose Windows 11 build’uose jis įjungtas pagal nutylėjimą, todėl du kompiuteriai tame pačiame įmonės tinkle elgiasi skirtingai. Kintamasis yra build’o numeris, o ne įmonės politika.

WSL tinklo vadovas aprašo tą režimą ir versijas, kurios jį palaiko. Ši funkcija svarbi, nes įmonės DNS politika paprastai gyvena Windows resolvatoriuje, o distribucija, kuri paveldi Windows kelią, paveldi ir politiką. Distribucija, kuri klausia viešo resolvatoriaus, neturi jokio kelio į privatų vardą, kad ir kaip tvarkingai atrodytų jos pačios konfigūracija. Šis mechanizmas paaiškina visą simptomą ir paaiškina, kodėl viešo resolvatoriaus apėjimas nepavyksta.

Perskaitykite build’ą prieš ką nors redaguodami. Iš naujesnės instaliacijos nukopijuotas nustatymas nėra įrodymas, kad senesnė jį įgyvendina. Užsirašykite build’o numerį šalia pakeitimo, nes dviejų kompiuterių skirtumas beveik visada yra versija, o ne politika.

Seni perrašymai pergyvena problemą, kurią išsprendė

Senesni receptai išjungdavo sugeneruotus resolvatoriaus failus, kietai įrašydavo vardų serverį arba užrakindavo failą nekeičiamu atributu. Tie pakeitimai lieka vietoje dar ilgai po to, kai išnyksta juos sukėlusi ryšio problema, ir dažniausiai jie yra priežastis, kodėl naujesnis nustatymas atrodo nieko nedarantis. Jie taip pat pergyvena distribucijos perįrašymą shell profilio pavidalu, kuris perrašo failą kiekvieno prisijungimo metu. Pastarąjį rasti sunkiausia, nes jis nematomas iš failo, kurį visi tikrina.

Ieškokite ranka rašyto resolvatoriaus failo, nekeičiamo atributo jame ir paleidimo scenarijaus, kuris jį perrašo. Prieš redaguodami patikrinkite nekeičiamumo vėliavėlę, nes rašymas į užrakintą failą nepavyksta taip, kad skaitosi kaip teisių problema. Po to patikrinkite shell profilį, nes ten esantis scenarijus atkuria seną turinį per kelias sekundes po jūsų pataisymo.

Perrašymo pašalinimas turi pasekmių, todėl užsirašykite, ką pašalinote ir kodėl. Distribucija, kuriai iš tikrųjų reikia statinio resolvatoriaus kitam tikslui, suges, kai sugeneruotas failas grįš.

Du failai, du skirtingi vaidmenys

Du konfigūracijos failai gyvena skirtingose vietose ir valdo skirtingus dalykus, o jų painiojimas sukuria pakeitimus, taikomus netinkamam sluoksniui. Windows pusės failas nustato virtualios mašinos savybes, o distribucijos pusės failas nustato, kaip ta distribucija kuria savo resolvatoriaus konfigūraciją. Nė vienas nepakeičia kito, todėl abu turi sutapti.

Instaliacijai, kuri palaiko šią funkciją, Windows pusės fragmentas yra trumpas. Tai visas pakeitimas toje pusėje:

[wsl2]
dnsTunneling=true

Tas fragmentas priklauso Windows naudotojo profiliui ir taikomas virtualiai mašinai, o ne vienai distribucijai. Tuneliavimas taip pat reikalauja, kad distribucija nebūtų išjungusi resolvatoriaus generavimo, todėl distribucijos pusės failas turi palikti šį elgesį ramybėje. Pakeiskite vieną be kito – režimas tyliai nieko nedaro, ir tai yra dažniausias būdas, kuriuo šis taisymas pranešamas kaip sugedęs. Patikrinkite abu failus toje pačioje sesijoje, nes du pakeitimai, padaryti su savaičių pertrauka, yra du pakeitimai, kurių niekas negali priskirti.

Paleiskite iš naujo, tada užklauskite iš abiejų pusių

Šie nustatymai skaitomi paleidžiant aplinką, todėl naujas shell veikiančios distribucijos viduje jų neperkraus. Išjunkite aplinką, o ne paleiskite shell iš naujo, ir pirmiausia išsaugokite bet kokį vykdomą darbą, nes kiekviena distribucija sustoja kartu su ja. Vien šis praleidimas paaiškina daugumą pranešimų, kad pakeitimas neturi poveikio.

Tada užduokite tą patį klausimą iš abiejų pusių. Išvestis taip pat parodo, su kokiu resolvatoriumi distribucija iš tikrųjų liko:

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'

Pirmoji komanda baigia aplinką, antroji parodo, kokį resolvatorių distribucija dabar naudoja, o paskutinės dvi užduoda tą patį klausimą kiekvienai pusei. Palyginkite atsakymus, o ne nustatymo būseną. Užklausa, kuri vis dar nepavyksta po švaraus paleidimo iš naujo, kai abu failai teisingi, rodo į įmonės resolvatoriaus politiką, ir tas pokalbis turi kitą savininką.