WSL2 nepaveldi įmonės VPN, ir būtent tai yra klaida

WSL2 veikia savo virtualiame tinkle ir niekada nepaveldi pagrindinio kompiuterio VPN steko. Prieš redaguodami resolv.conf atskirkite vardų ir kelio gedimus.

Vidinis vikis įkeliamas Edge, o git clone distribucijos viduje baigiasi skirtuoju laiku. Šis vienintelis pastebėjimas paprastai skaitomas kaip «VPN blokuoja WSL2», ir kita valanda nueina redaguojant /etc/resolv.conf. Naudingesnis skaitymas yra tas, kad WSL2 niekada neturėjo pagrindinio kompiuterio tinklo kelio: jis veikia pagalbinėje VM su savo adapteriu, savo maršrutais ir resolver failu, kurį Windows jam sukuria. Viskas, kas toliau, priklauso nuo to, kurio iš šių trijų jums iš tikrųjų trūksta.

VM turi savo steką, metrikas ir resolver

Numatytuoju NAT režimu distribucija yra už virtualaus komutatoriaus ir pasiekia internetą per pagrindinį kompiuterį, bet nemato jo adapterių. ip addr rodo vieną sąsają su privačiu adresu, ip route rodo numatytąjį maršrutą per tą komutatorių, o /etc/resolv.conf yra sugeneruotas failas, nukreipiantis į Windows pasirinktą stub resolver. Niekas iš to nesikeičia dėl to, kad Windows pusėje buvo paleistas VPN klientas.

Štai kodėl «naršyklė veikia» įrodo taip mažai. Naršyklė naudoja pagrindinio kompiuterio steką, tunelį ir jo resolver politiką. Jūsų apvalkalas naudoja kitą steką, kuris atsitiktinai dalijasi fizine tinklo kortele. Jie sutampa laimingu atveju ir išsiskiria būtent tada, kai VPN įdiegia filtrą, perrašo DNS sąrašą arba prideda maršrutą virtualaus komutatoriaus potinkliui.

Du testai nusprendžia, kuriame pasaulyje esate, ir jie turi būti paleisti distribucijos viduje:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Vardų nepavykimas, kai atsako pažodinis adresas, yra resolver problema. Vardų ir adresų nepavykimas kartu yra kelio problema, ir jokia resolver redakcija jos nepaliestų. Toliau ateina Windows pusės įrodymai: Get-NetAdapter | Get-DnsClientServerAddress ir route print -4 parodo, ar tunelis užėmė potinklį, kuriame gyvena jūsų VM.

Pirmas mitas: įmonės DNS serveriai tai sutvarko

Resolver failo redagavimas yra klasikinis patarimas, ir jis teisingas maždaug pusę laiko. Kai jis teisingas, jis teisingas dėl konkrečios priežasties: sugeneruotas failas nukreipia į resolver, kuris žino tik viešus vardus, todėl užklausa dėl intranet.example.internal grįžta kaip neegzistuojanti, nors kelias tvarkingas.

VPN serverių priskyrimas reiškia sustabdyti Windows, kad jis nepergeneruotų failo, nes bet koks ranka rašomas failas pakeičiamas kitą kartą paleidus:

[network]
generateResolvConf = false

Išsaugokite tai kaip /etc/wsl.conf, paleiskite wsl --shutdown iš Windows, tada paleiskite distribuciją ir įrašykite /etc/resolv.conf su tunelio serveriais pirmaisiais, o viešą resolver tik kaip atsarginį. Tai ilgalaikis pakeitimas su priežiūros kaina: failas nebeseka pagrindinio kompiuterio, todėl kai pasikeičia įmonės DNS adresai, distribucija toliau klausia senųjų. Kažkas turi būti to failo savininkas.

Jis taip pat nieko nedaro, kai gedimas platesnis. Jei curl į 1.1.1.1 baigiasi skirtuoju laiku, tunelio klientas filtruoja virtualų komutatorių arba nukreipia VM potinklį į tunelį, ir teisingas resolver duoda tik vardus, kurių dar neįmanoma pasiekti.

Antras mitas: metrikos pakeitimas išlieka

Kai vardai išsprendžiami, bet srautas išeina per fizinį adapterį, svirtis yra sąsajos metrikos. Suteikite VPN adapteriui didelę kainą, o WSL komutatoriui mažą:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Tada atsiminkite, kad daugelyje kliento versijų tunelio adapteris atkuriamas kiekvieno prisijungimo metu ir metrika grįžta į numatytąją. Vienkartinė komanda yra pataisa, kuri tyliai baigiasi, dažniausiai per savaitgalį, ir bilietas grįžta su «praėjusią savaitę veikė». Suplanuota užduotis, kurią paleidžia VPN įvykis, arba scenarijus, kurį vartotojas paleidžia prisijungęs, yra sąžininga šios pataisos versija.

Tas pats galiojimo laikas taikomas pagrindinio kompiuterio maršrutams, pridėtiems vienam užsispyrusiam priešdėliui. Jie vertingi kaip diagnostika, nes pasako, ar problema vienas tikslas, ar visas kelias, bet jie nėra architektūra.

Trečias mitas: viena pataisa apima kiekvieną Windows versiją

ApproachWhat it actually does
Resolver pinFixes private names only; no effect on path failures
Sidecar distributionForwards traffic over a socket to a helper VM, so the switch's filter no longer matters
Mirrored networkingGives the distribution the host's interface set; also enables DNS tunnelling

wsl-vpnkit yra sidecar šablonas: maža distribucija valdo kelią pagrindinio kompiuterio pusėje ir persiunčia kitoms distribucijoms per virtualų lizdą, todėl programų srautas nustoja priklausyti nuo filtruojamo komutatoriaus. Reikia, kad veiktų standartinis kelias, tai yra pašalinti networkingMode ir dnsTunneling perrašymus iš %UserProfile%\.wslconfig, atkurti generateResolvConf = true kiekvienoje veikiančioje distribucijoje ir paleisti tarnybą prisijungus.

Veidrodinis režimas yra integruota alternatyva Windows 11 22H2 ir naujesnėse, ir tai vienas nustatymas plius išjungimas:

[wsl2]
networkingMode=mirrored

Distribucijos viduje ip addr tada išvardija pagrindinio kompiuterio adapterius, tunelis gali pasirodyti tarp jų, ir DNS tuneliavimas persiunčia užklausas per Windows resolver net kai klientas perrašo DNS sąrašą. Tai nėra universalu: kai kurios filtravimo tvarkyklės vis dar atmeta veidrodinį kelią, o Hyper-V užkardos taisyklėms gali prireikti aiškaus leidimo. Microsoft WSL tinklų vadovas yra puslapis, kurį reikia palyginti su savo versija prieš taikant receptą, parašytą naujesnei.

Po kiekvieno pakeitimo patikrinkite tris dalykus

Pasirinkite vieną mechanizmą vienai mašinai ir užsirašykite, nes abu dera blogai. Sidecar virš veidrodinio režimo padvigubina persiuntimą, o veidrodinis pagrindinis kompiuteris su pasenusiu sidecar įrašu .wslconfig paprastai sugenda po atnaujinimo, o ne prieš jį.

Kad ir ką pasirinktumėte, priėmimo testas yra tie patys trys prašymai distribucijos viduje: vidinis vardas, viešas vardas ir neapdorotas adresas. Tada pakartokite juos atjungę ir vėl prijungę tunelį, ir po wsl --shutdown. Jei nepavyksta tik vidinis vardas, tai resolver politika; jei vidinis ir viešas vardai nepavyksta kartu su veikiančiu adresu, tai vis dar resolver politika; jei nepavyksta viskas, tai kelias.

Jei vienas vidinis pagrindinis kompiuteris sugenda, o kiti veikia, nustokite žiūrėti į resolver ir ieškokite trūkstamo maršruto tam priešdėliui. Jei viskas veikia iki kito prisijungimo, radote pataisą, kuri priklauso nuo vykdymo būsenos, ir ją reikia automatiškai taikyti iš naujo arba pakeisti vienu iš dviejų aukščiau nurodytų mechanizmų.

Susiję straipsniai