Pse WSL humb emrin e hostit të punës kur lidhet VPN-i?

Windows e zgjidh hostin e brendshëm pa asnjë ankesë, dhe i njëjti emër dështon brenda WSL në momentin kur ngrihet tuneli. Rregullimi i zakonshëm është të shkruhet një zgjidhës publik në distribucion, gjë që rikthen shfletimin normal dhe e bën emrin e hostit të punës të pazgjidhshëm. Kjo ndërron një dështim me një tjetër dhe fsheh shtresën që u prish vërtet. Përpara se të shtoni ose hiqni çdo rresht zgjidhësi, përcaktoni cila nga tre shtresat po dështon.

Fillimisht përjashtoni një dështim rrugëtimi

Pyetni të njëjtin emër plotësisht të kualifikuar në të dyja anët, jo dy emra që duken njësoj. Suksesi në Windows dhe dështimi në WSL për të njëjtin varg është nënshkrimi i dy rrugëve të zgjidhjes, dhe pak gjëra të tjera e prodhojnë atë model kaq pastër. Nëse WSL nuk arrin ta prekë shërbimin as në adresën e tij numerike të njohur, ka edhe një problem rrugëtimi ose filtrimi. Në atë rast puna me DNS nuk do ta zbulojë, dhe pasditja shkon në shtresën e gabuar.

Tre simptoma mbulojnë shumicën e këtyre rasteve, dhe secili tregon diku tjetër. Lexoni rreshtin që përputhet përpara se të hapni një skedar konfigurimi:

Rreshti i mesëm është ai që njerëzit e lexojnë gabim, sepse ndryshimi që e prishi u bë javë më parë dhe atëherë dukej i suksesshëm. Rreshti i tretë është ai që njerëzit e diagnozojnë gabim, sepse një emër që zgjidhet duket si provë që rrjeti është i shëndoshë. Të dy rreshtat ju dërgojnë në një seksion tjetër më poshtë.

Tunelimi i DNS ka një kufi minimal versioni

Microsoft dokumenton një modalitet rrjeti të WSL që tunelon kërkesat DNS drejt zgjidhësit të Windows përmes një kanali virtualizimi. Në ndërtimet e mbështetura të Windows 11 është i aktivizuar si parazgjedhje, dhe për këtë arsye dy makina në të njëjtin rrjet korporativ sillen ndryshe. Variabli është numri i ndërtimit, jo politika e korporatës.

Udhëzuesi i rrjetit të WSL përshkruan atë modalitet dhe versionet që e mbështesin. Funksioni ka rëndësi sepse politika e DNS-së korporative zakonisht jeton në zgjidhësin e Windows, dhe një distribucion që trashëgon rrugën e Windows trashëgon edhe politikën. Një distribucion që pyet një zgjidhës publik nuk ka asnjë rrugë drejt një emri privat, sado e rregullt të duket konfigurimi i tij. Ai mekanizëm shpjegon të gjithë simptomën, dhe shpjegon pse zgjidhja anësore me zgjidhës publik dështon.

Lexoni ndërtimin përpara se të ndryshoni çdo gjë. Një cilësim i kopjuar nga një instalim më i ri nuk është provë që një më i vjetër e zbaton. Shënoni numrin e ndërtimit pranë ndryshimit, sepse dallimi midis dy makinave është pothuajse gjithmonë version, jo politikë.

Mbivendosjet e vjetra i mbijetojnë problemit që zgjidhën

Recetat më të vjetra çaktivizonin skedarët e zgjidhësit të gjeneruar, kodonin fort një server emrash ose bllokonin skedarin me një atribut të pandryshueshëm. Ato ndryshime mbeten në vend shumë kohë pasi problemi i lidhjes që i shkaktoi zhduket, dhe zakonisht janë arsyeja pse një cilësim më i ri duket se nuk bën asgjë. Ato i mbijetojnë edhe një riinstalimi të distribucionit në formën e një profili shell që rishkruan skedarin në çdo hyrje. I fundit është më i vështiri për t’u gjetur, sepse është i padukshëm nga skedari që të gjithë inspektojnë.

Kërkoni një skedar zgjidhësi të shkruar me dorë, një atribut të pandryshueshëm mbi të dhe një skript nisjeje që e rishkruan. Kontrolloni flamurin e pandryshueshmërisë përpara redaktimit, sepse shkrimi në një skedar të bllokuar dështon në një mënyrë që lexohet si problem lejeje. Më pas kontrolloni profilin shell, sepse një skript atje rikthen përmbajtjen e vjetër brenda sekondave pas korrigjimit tuaj.

Heqja e një mbivendosjeje ka pasoja, prandaj shënoni çfarë hoqët dhe pse. Një distribucion që vërtet ka nevojë për një zgjidhës statik për një qëllim tjetër do të prishet kur të kthehet skedari i gjeneruar.

Dy skedarë, dy role të ndryshme

Dy skedarët e konfigurimit jetojnë në vende të ndryshme dhe kontrollojnë gjëra të ndryshme, dhe ngatërrimi i tyre prodhon redaktime të aplikuara në shtresën e gabuar. Skedari në anën e Windows vendos vetitë e makinës virtuale, ndërsa skedari në anën e distribucionit vendos si ai distribucion ndërton konfigurimin e vet të zgjidhësit. Asnjëri nuk e anulon tjetrin, prandaj të dy duhet të bien dakord.

Për një instalim që e mbështet funksionin, fragmenti në anën e Windows është i shkurtër. Është i gjithë ndryshimi në atë anë:

[wsl2]
dnsTunneling=true

Ai fragment i përket profilit të përdoruesit të Windows dhe zbatohet për makinën virtuale, jo për një distribucion të vetëm. Tunelimi kërkon gjithashtu që distribucioni të mos ketë çaktivizuar gjenerimin e zgjidhësit, kështu që skedari në anën e distribucionit duhet ta lërë atë sjellje në paqe. Ndryshoni njërin pa tjetrin dhe modaliteti bën heshtazi asgjë, dhe kjo është mënyra më e zakonshme se si ky rregullim raportohet si i prishur. Kontrolloni të dy skedarët në të njëjtën sesion, sepse dy redaktime të bëra me javë distancë janë dy redaktime që askush nuk mund t’i atribuojë.

Rinisni, pastaj pyesni nga të dyja anët

Këto cilësime lexohen kur nis mjedisi, kështu që një shell i ri brenda një distribucioni që po punon nuk do t’i ringarkojë. Fikeni mjedisin në vend që të rinisni shell-in, dhe fillimisht ruani çdo punë në vazhdim sepse çdo distribucion ndalon bashkë me të. Vetëm kjo lënie jashtë shpjegon shumicën e raporteve se një ndryshim nuk ka efekt.

Më pas bëni të njëjtën pyetje nga të dyja anët. Rezultati tregon gjithashtu me cilin zgjidhës përfundoi në të vërtetë distribucioni:

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'

Komanda e parë e përfundon mjedisin, e dyta tregon cilin zgjidhës përdor tani distribucioni, dhe dy të fundit i bëjnë të njëjtën pyetje secilës anë. Krahasoni përgjigjet, jo gjendjen e cilësimit. Një pyetje që vazhdon të dështojë pas një rinisjeje të pastër me të dy skedarët të saktë tregon politikën e zgjidhësit korporativ, dhe ai bisedë ka një pronar tjetër.