Miks kaob WSL-il tööhostinimi, kui VPN ühendub?

Windows lahendab sisemise hosti ilma ühegi kaebuseta ning sama nimi ebaõnnestub WSL-is hetkel, mil tunnel püsti tõuseb. Tavaline parandus on kirjutada distributsiooni avalik resolver, mis taastab tavalise sirvimise ja muudab tööhostinime lahendamatuks. See vahetab ühe tõrke teise vastu ja peidab kihi, mis tegelikult katki läks. Enne mis tahes resolveri rea lisamist või eemaldamist tehke kindlaks, milline kolmest kihist ebaõnnestub.

Välistage esmalt marsruutimise tõrge

Pärige sama täielikult kvalifitseeritud nime mõlemalt poolt, mitte kahte sarnast nime. Õnnestumine Windowsis ja ebaõnnestumine WSL-is sama stringi puhul on kahe lahendusteekonna signatuur ja vähesed muud asjad tekitavad selle mustri nii puhtalt. Kui WSL ei pääse teenuseni ka selle teadaoleval numbrilisel aadressil, on olemas ka marsruutimis- või filtreerimisprobleem. Sel juhul ei paljasta DNS-töö seda ja pärastlõuna läheb vale kihi peale.

Kolm sümptomit katavad enamiku neist juhtudest ja igaüks osutab eri kohta. Lugege sobiv rida enne konfiguratsioonifaili avamist:

Keskmist rida loetakse sageli valesti, sest selle katki teinud muudatus tehti nädalaid varem ja näis tol ajal edukas. Kolmandale reale pannakse sageli vale diagnoos, sest lahenduv nimi tundub tõendina, et võrk on terve. Mõlemad read saadavad teid allpool teise jaotisse.

DNS-tunnelil on vähimisversioon

Microsoft dokumenteerib WSL-i võrgurežiimi, mis tunnelab DNS-päringud virtualiseerimiskanali kaudu Windowsi resolverisse. Toetatud Windows 11 koostistes on see vaikimisi lubatud, mistõttu kaks masinat samas ettevõttevõrgus käituvad erinevalt. Muutuja on koostise number, mitte ettevõtte poliitika.

WSL-i võrgu juhend kirjeldab seda režiimi ja versioone, mis seda toetavad. Funktsioon on oluline, sest ettevõtte DNS-poliitika elab tavaliselt Windowsi resolveris ning distributsioon, mis pärib Windowsi tee, pärib ka poliitika. Avalikku resolverit küsival distributsioonil pole ühtegi marsruuti privaatse nimeni, ükskõik kui korrapärane tema enda konfiguratsioon ka välja näeb. See mehhanism seletab kogu sümptomit ja seletab, miks avaliku resolveri möödaviik ebaõnnestub.

Lugege koostise numbrit enne, kui midagi muudate. Uuemast paigaldusest kopeeritud säte ei ole tõendiks, et vanem seda rakendab. Kirjutage koostise number muudatuse kõrvale, sest kahe masina erinevus on peaaegu alati versioon, mitte poliitika.

Vanad ülekirjutused elavad üle probleemi, mille nad lahendasid

Vanemad retseptid lülitasid genereeritud resolverifailid välja, kõvasid kodeerisid nimeserveri või lukustasid faili muutumatuse atribuudiga. Need muudatused jäävad paigale kaua pärast seda, kui neid põhjustanud ühenduvusprobleem on kadunud, ja tavaliselt on need põhjuseks, miks uuem säte näib mitte midagi tegevat. Need elavad üle ka distributsiooni uuesti paigaldamise shelli profiili kujul, mis kirjutab faili igal sisselogimisel üle. Viimast on kõige raskem leida, sest see on nähtamatu failist, mida kõik kontrollivad.

Otsige käsitsi kirjutatud resolverifaili, sellel olevat muutumatuse atribuuti ja käivituskripti, mis selle üle kirjutab. Kontrollige muutumatuse lippu enne muutmist, sest lukustatud faili kirjutamine ebaõnnestub viisil, mis loeb nagu õiguste probleem. Seejärel kontrollige shelli profiili, sest sealne skript taastab vana sisu sekundite jooksul pärast teie parandust.

Ülekirjutuse eemaldamisel on tagajärjed, seega kirjutage üles, mida eemaldasite ja miks. Distributsioon, mis tõesti vajab staatilist resolverit muul eesmärgil, läheb katki, kui genereeritud fail naaseb.

Kaks faili, kaks erinevat rolli

Kaks konfiguratsioonifaili asuvad erinevates kohtades ja juhivad erinevaid asju ning nende segamini ajamine tekitab muudatusi, mis rakenduvad valele kihile. Windowsi-poolne fail määrab virtuaalmasina omadused, samas kui distributsioonipoolne fail määrab, kuidas see distributsioon oma resolveri konfiguratsiooni üles ehitab. Kumbki ei kirjuta teist üle, mistõttu peavad mõlemad kokku sobima.

Paigalduse jaoks, mis seda funktsiooni toetab, on Windowsi-poolne fragment lühike. See on kogu muudatus sellel poolel:

[wsl2]
dnsTunneling=true

See fragment kuulub Windowsi kasutajaprofiili ja kehtib virtuaalmasinale, mitte üksikule distributsioonile. Tunnelda nõuab ka seda, et distributsioon ei oleks resolveri genereerimist välja lülitanud, seega peab distributsioonipoolne fail selle käitumise rahule jätma. Muutke ühte ilma teiseta ja režiim ei tee vaikselt midagi, mis on kõige tavalisem viis, kuidas seda parandust katkisena teatatakse. Kontrollige mõlemat faili samas seansis, sest nädalate vahega tehtud kaks muudatust on kaks muudatust, mida keegi ei saa omistada.

Taaskäivitage ja seejärel pärige mõlemalt poolt

Neid sätteid loetakse keskkonna käivitamisel, seega töötava distributsiooni sees uus shell ei laadi neid uuesti. Lülitage keskkond välja, selle asemel et shelli taaskäivitada, ja salvestage enne käimasolev töö, sest iga distributsioon peatub koos sellega. Ainuüksi see vahelejätmine seletab enamikku teatisi, et muudatusel pole mõju.

Seejärel esitage sama küsimus mõlemalt poolt. Väljund näitab ka, millise resolveri juurde distributsioon tegelikult jõudis:

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'

Esimene käsk lõpetab keskkonna, teine näitab, millist resolverit distributsioon nüüd kasutab, ja kaks viimast esitavad sama küsimuse kummale poole. Võrrelge vastuseid, mitte sätte olekut. Päring, mis ebaõnnestub endiselt pärast puhast taaskäivitust mõlema faili õige oleku juures, osutab ettevõtte resolveripoliitikale ja sellel vestlusel on teine omanik.