WSL2 nuk e trashëgon VPN-në e korporatës, dhe pikërisht ky është bug-u

Wiki-ja e brendshme ngarkohet në Edge, ndërsa git clone brenda distribucionit skadon. Ky vëzhgim i vetëm lexohet zakonisht si «VPN-ja po bllokon WSL2», dhe ora tjetër shkon në editimin e /etc/resolv.conf. Leximi më i dobishëm është se WSL2 nuk e kishte kurrë rrugën e rrjetit të hostit: punon në një VM ndihmëse me adapterin e vet, rrugët e veta dhe një skedar resolver që Windows gjeneron për të. Gjithçka që vijon varet nga cila prej atyre treve të mungon vërtet.

VM-ja ka stekun, metrikat dhe resolverin e vet

Në modalitetin e parazgjedhur NAT, distribucioni qëndron pas një switch virtual dhe arrin internetin përmes hostit, por nuk i sheh adapterët e hostit. ip addr shfaq një ndërfaqe me adresë private, ip route shfaq një rrugë të parazgjedhur përmes atij switch, dhe /etc/resolv.conf është një skedar i gjeneruar që tregon një stub resolver të zgjedhur nga Windows. Asgjë nga kjo nuk ndryshon sepse një klient VPN u nis në anën e Windows.

Prandaj «shfletuesi funksionon» provon kaq pak. Shfletuesi përdor stekun e hostit, tunelin dhe politikën e resolverit të hostit. Shell-i juaj përdor një stek tjetër që rastësisht ndan një kartë rrjeti fizike. Ato përputhen në rastin e mirë dhe ndryshojnë pikërisht kur VPN-ja instalon një filtër, rishkruan listën DNS ose shton një rrugë për nënrrjetin e switch-it virtual.

Dy teste vendosin në cilin botë jeni, dhe ato duhet të ekzekutohen brenda distribucionit:

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

Dështimi i emrave ndërsa një adresë fjalëpërfjalë përgjigjet është problem resolveri. Dështimi i emrave dhe adresave së bashku është problem rruge, dhe asnjë editim resolveri nuk do ta prekë. Më pas vijnë provat nga ana e Windows: Get-NetAdapter | Get-DnsClientServerAddress dhe route print -4 tregojnë nëse tuneli e ka marrë nënrrjetin ku jeton VM-ja juaj.

Miti i parë: serverët DNS të korporatës e rregullojnë

Editimi i skedarit resolver është këshilla klasike, dhe është i saktë rreth gjysmës së kohës. Kur është i saktë, është për një arsye të caktuar: skedari i gjeneruar tregon një resolver që njeh vetëm emra publikë, kështu që një kërkesë për intranet.example.internal kthehet si e pavlefshme edhe kur rruga është në rregull.

Fiksimi i serverëve të VPN-së do të thotë të ndalosh Windows që të rigjenerojë skedarin, sepse çdo skedar i shkruar me dorë zëvendësohet në nisjen tjetër:

[network]
generateResolvConf = false

Ruajeni atë si /etc/wsl.conf, ekzekutoni wsl --shutdown nga Windows, pastaj nisni distribucionin dhe shkruani /etc/resolv.conf me serverët e tunelit të parët dhe një resolver publik vetëm si rezervë. Ky është një ndryshim i qëndrueshëm me kosto mirëmbajtjeje: skedari nuk e ndjek më hostin, kështu që kur adresat DNS të korporatës ndryshojnë distribucioni vazhdon të pyesë ato të vjetrat. Dikush duhet të zotërojë atë skedar.

As nuk bën asgjë kur dështimi është më i gjerë. Nëse curl drejt 1.1.1.1 skadon, klienti i tunelit po filtron switch-in virtual ose po e drejton nënrrjetin e VM-së në tunel, dhe një resolver i saktë ju jep vetëm emra që ende nuk mund të arrihen.

Miti i dytë: ndryshimi i metrikës mbetet

Kur emrat zgjidhen por trafiku del përmes adapterit fizik, metrikat e ndërfaqes janë levë. Jepini adapterit VPN kosto të lartë dhe switch-it WSL kosto të ulët:

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

Më pas mbani mend se në shumë ndërtime të klientit adapteri i tunelit rikrijohet në çdo lidhje dhe metrika kthehet në parazgjedhjen e saj. Një komandë e vetme është një rregullim që skadon në heshtje, zakonisht gjatë një fundjave, dhe tiketa kthehet me «javën e kaluar funksiononte». Një detyrë e planifikuar që aktivizohet nga ngjarja e VPN-së, ose një skript që përdoruesi ekzekuton pas lidhjes, është versioni i ndershëm i këtij rregullimi.

E njëjta skadencë vlen për rrugët e hostit të shtuara për një prefiks kokëfortë. Ato vlejnë si diagnostikim, sepse tregojnë nëse problemi është një destinacion apo e gjithë rruga, por nuk janë arkitekturë.

Miti i tretë: një rregullim mbulon çdo ndërtim të Windows

wsl-vpnkit është modeli sidecar: një distribucion i vogël zotëron rrugën në anën e hostit dhe përcjell për distribucione të tjera përmes një soketi virtual, kështu që trafiku i aplikacioneve nuk varet më nga switch-i i filtruar. Kërkon që rruga standarde të funksionojë, që do të thotë të heqësh mbivendosjet networkingMode dhe dnsTunneling nga %UserProfile%\.wslconfig, të rivendosësh generateResolvConf = true në çdo distribucion që funksionon dhe të nisësh shërbimin në hyrje.

Modaliteti pasqyrë është alternativa e integruar në Windows 11 22H2 dhe më vonë, dhe është një cilësim plus një mbyllje:

[wsl2]
networkingMode=mirrored

Brenda distribucionit ip addr më pas liston adapterët e hostit, tuneli mund të shfaqet midis tyre, dhe tunelimi DNS i përcjell kërkesat përmes resolverit të Windows edhe kur klienti rishkruan listën DNS. Nuk është universale: disa drejtues filtrimi ende e hedhin poshtë rrugën pasqyrë, dhe rregullat e firewall-it të Hyper-V mund të kërkojnë leje të qartë. Udhëzuesi i rrjeteve WSL i Microsoft është faqja që duhet krahasuar me ndërtimin tuaj përpara se të aplikoni një recetë të shkruar për një më të re.

Testoni tri gjëra pas çdo ndryshimi

Zgjidhni një mekanizëm për makinë dhe shkruajeni, sepse të dy kombinohen keq. Një sidecar mbi modalitetin pasqyrë dyfishon përcjelljen, dhe një host pasqyrë me një zë sidecar të vjetëruar në .wslconfig tenton të dështojë pas një përmirësimi, jo para tij.

Çfarëdo që zgjidhët, testi i pranimit janë të njëjtat tre kërkesa brenda distribucionit: një emër i brendshëm, një emër publik dhe një adresë e papërpunuar. Pastaj përsëritni ato pas shkëputjes dhe rilidhjes së tunelit, dhe pas wsl --shutdown. Vetëm emri i brendshëm që dështon do të thotë politikë resolveri; emri i brendshëm dhe ai publik që dështojnë së bashku me një adresë që funksionon ende do të thotë politikë resolveri; gjithçka dështon do të thotë rruga.

Nëse një host i brendshëm dështon ndërsa pjesa tjetër funksionon, ndaloni së shikuari resolverin dhe kërkoni një rrugë që mungon për atë prefiks. Nëse gjithçka funksionon deri në rilidhjen tjetër, keni gjetur një rregullim që varet nga gjendja në kohën e ekzekutimit, dhe ai duhet rizbatuar automatikisht ose zëvendësuar me një nga dy mekanizmat më sipër.