WSL2 nemanto uzņēmuma VPN, un tā ir kļūda

Iekšējā viki ielādējas Edge, bet distribūcijas iekšienē git clone beidzas ar taimautu. Šis vienīgais novērojums parasti tiek lasīts kā «VPN bloķē WSL2», un nākamā stunda paiet, rediģējot /etc/resolv.conf. Noderīgāks lasījums ir tāds, ka WSL2 nekad nav bijis resursdatora tīkla ceļa: tas darbojas palīgVM ar savu adapteri, saviem maršrutiem un resolver failu, ko Windows tam ģenerē. Viss turpmākais ir atkarīgs no tā, kura no šīm trim jums patiešām trūkst.

VM ir savs steks, metrikas un resolver

Noklusējuma NAT režīmā distribūcija atrodas aiz virtuāla komutatora un sasniedz internetu caur resursdatoru, bet neredz tā adapterus. ip addr parāda vienu saskarni ar privātu adresi, ip route parāda noklusējuma maršrutu caur šo komutatoru, un /etc/resolv.conf ir ģenerēts fails, kas norāda uz Windows izvēlētu stub resolver. Nekas no tā nemainās tāpēc, ka Windows pusē startēja VPN klients.

Tāpēc «pārlūkprogramma darbojas» pierāda tik maz. Pārlūkprogramma izmanto resursdatora steku, tuneli un resursdatora resolver politiku. Jūsu čaula izmanto citu steku, kas nejauši dala fizisku tīkla karti. Tie sakrīt labajā gadījumā un atšķiras tieši tad, kad VPN instalē filtru, pārraksta DNS sarakstu vai pievieno maršrutu virtuālā komutatora apakštīklam.

Divi testi izšķir, kurā pasaulē jūs esat, un tiem jādarbojas distribūcijas iekšienē:

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

Ja nosaukumi cieš neveiksmi, bet burtiskā adrese atbild, tā ir resolver problēma. Ja nosaukumi un adreses cieš neveiksmi kopā, tā ir ceļa problēma, un nekāda resolver rediģēšana to neskars. Tālāk nāk pierādījumi no Windows puses: Get-NetAdapter | Get-DnsClientServerAddress un route print -4 parāda, vai tunelis ir pārņēmis apakštīklu, kurā dzīvo jūsu VM.

Pirmais mīts: uzņēmuma DNS serveri to atrisina

Resolver faila rediģēšana ir klasisks padoms, un tas ir pareizs apmēram pusi laika. Kad tas ir pareizs, tas ir pareizs konkrēta iemesla dēļ: ģenerētais fails norāda uz resolver, kas zina tikai publiskus nosaukumus, tāpēc vaicājums par intranet.example.internal atgriežas kā neesošs, lai gan ceļš ir kārtībā.

VPN serveru piespraušana nozīmē apturēt Windows faila atkārtotu ģenerēšanu, jo jebkurš ar roku rakstīts fails tiek aizstāts nākamajā startā:

[network]
generateResolvConf = false

Saglabājiet to kā /etc/wsl.conf, palaidiet wsl --shutdown no Windows, pēc tam startējiet distribūciju un ierakstiet /etc/resolv.conf ar tuneļa serveriem pirmajiem un publisku resolver tikai kā rezervi. Tās ir ilgstošas izmaiņas ar uzturēšanas izmaksām: fails vairs neseko resursdatoram, tāpēc, kad uzņēmuma DNS adreses mainās, distribūcija turpina jautāt vecās. Kādam ir jābūt šī faila īpašniekam.

Tas arī neko nedara, ja kļūme ir plašāka. Ja curl uz 1.1.1.1 beidzas ar taimautu, tuneļa klients filtrē virtuālo komutatoru vai novirza VM apakštīklu tunelī, un pareizs resolver dod tikai nosaukumus, kuriem joprojām nevar piekļūt.

Otrais mīts: metrikas izmaiņas paliek

Kad nosaukumi tiek atrisināti, bet trafiks iziet caur fizisko adapteri, svira ir saskarnes metrikas. Piešķiriet VPN adapterim augstas izmaksas un WSL komutatoram zemas:

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

Pēc tam atcerieties, ka daudzās klienta versijās tuneļa adapteris tiek atjaunots katrā savienojumā un metrika atgriežas pie noklusējuma. Vienreizēja komanda ir labojums, kas klusi beidzas, parasti nedēļas nogalē, un biļete atgriežas ar «pagājušajā nedēļā strādāja». Plānots uzdevums, ko iedarbina VPN notikums, vai skripts, ko lietotājs palaiž pēc savienojuma, ir godīgā šī labojuma versija.

Tas pats derīguma termiņš attiecas uz resursdatora maršrutiem, kas pievienoti vienam spītīgam prefiksam. Tie ir vērtīgi kā diagnostika, jo pasaka, vai problēma ir viens galamērķis vai viss ceļš, bet tie nav arhitektūra.

Trešais mīts: viens labojums aptver katru Windows versiju

wsl-vpnkit ir sidecar modelis: maza distribūcija pārvalda ceļu resursdatora pusē un pārsūta citām distribūcijām caur virtuālu ligzdu, tāpēc lietotņu trafiks pārstāj būt atkarīgs no filtrētā komutatora. Nepieciešams, lai standarta ceļš darbotos, tas nozīmē noņemt networkingMode un dnsTunneling pārrakstus no %UserProfile%\.wslconfig, atjaunot generateResolvConf = true katrā strādājošā distribūcijā un startēt pakalpojumu pieteikšanās laikā.

Spoguļrežīms ir iebūvētā alternatīva Windows 11 22H2 un jaunākās versijās, un tas ir viens iestatījums plus izslēgšana:

[wsl2]
networkingMode=mirrored

Distribūcijas iekšienē ip addr tad uzskaita resursdatora adapterus, tunelis var parādīties starp tiem, un DNS tunelēšana pārsūta vaicājumus caur Windows resolver pat tad, kad klients pārraksta DNS sarakstu. Tas nav universāls: daži filtrēšanas draiveri joprojām atmet spoguļceļu, un Hyper-V ugunsmūra noteikumiem var būt nepieciešama skaidra atļauja. Microsoft WSL tīklu rokasgrāmata ir lapa, kas jāsaskaņo ar savu versiju pirms receptes, kas rakstīta jaunākai, piemērošanas.

Pēc katras izmaiņas pārbaudiet trīs lietas

Izvēlieties vienu mehānismu vienai mašīnai un pierakstiet to, jo abi slikti kombinējas. Sidecar virs spoguļrežīma dubulto pārsūtīšanu, un spoguļa resursdators ar novecojušu sidecar ierakstu .wslconfig parasti sabojājas pēc jaunināšanas, nevis pirms tās.

Lai ko jūs izvēlētos, pieņemšanas tests ir tie paši trīs pieprasījumi distribūcijas iekšienē: iekšējs nosaukums, publisks nosaukums un neapstrādāta adrese. Pēc tam atkārtojiet tos pēc tuneļa atvienošanas un atkārtotas pievienošanas, un pēc wsl --shutdown. Ja neizdodas tikai iekšējam nosaukumam, tā ir resolver politika; ja iekšējais un publiskais nosaukums neizdodas kopā ar strādājošu adresi, tā joprojām ir resolver politika; ja neizdodas visam, tas ir ceļš.

Ja viens iekšējs resursdators neizdodas, kamēr pārējie strādā, pārtrauciet skatīties uz resolver un meklējiet trūkstošu maršrutu šim prefiksam. Ja viss strādā līdz nākamajai atkārtotajai pievienošanai, jūs esat atraduši labojumu, kas atkarīgs no izpildlaika stāvokļa, un tas automātiski jāpiemēro atkārtoti vai jāaizstāj ar vienu no diviem iepriekš minētajiem mehānismiem.