WSL2 ne nasljeđuje korporativni VPN i upravo je to greška

Interna wiki se učitava u Edgeu, a git clone unutar distribucije istječe. To jedno zapažanje obično se čita kao «VPN blokira WSL2», a sljedeći sat odlazi na uređivanje /etc/resolv.conf. Korisnije čitanje je da WSL2 nikada nije imao mrežni put hosta: radi u pomoćnom VM-u s vlastitim adapterom, vlastitim rutama i datotekom resolvera koju Windows generira za njega. Sve što slijedi ovisi o tome koje od tih troje zapravo nedostaje.

VM ima vlastiti stog, metrike i resolver

U zadanom NAT načinu rada distribucija stoji iza virtualnog preklopnika i do interneta dolazi preko hosta, ali ne vidi adaptere hosta. ip addr prikazuje jedno sučelje s privatnom adresom, ip route prikazuje zadanu rutu kroz taj preklopnik, a /etc/resolv.conf je generirana datoteka koja pokazuje na stub resolver koji je Windows odabrao. Ništa se od toga ne mijenja zato što je na strani Windowsa pokrenut VPN klijent.

Zato «preglednik radi» dokazuje tako malo. Preglednik koristi stog hosta, tunel i resolver politiku hosta. Vaša ljuska koristi drugi stog koji slučajno dijeli fizičku mrežnu karticu. Slažu se u sretnom slučaju, a razilaze se upravo kada VPN instalira filtar, prepiše DNS popis ili doda rutu za podmrežu virtualnog preklopnika.

Dva testa odlučuju u kojem ste svijetu i moraju se izvesti unutar distribucije:

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

Ako imena ne uspijevaju, a doslovna adresa odgovara, to je problem resolvera. Ako imena i adrese padaju zajedno, to je problem puta i nikakvo uređivanje resolvera ga neće dotaknuti. Slijede dokazi sa strane Windowsa: Get-NetAdapter | Get-DnsClientServerAddress i route print -4 pokazuju je li tunel preuzeo podmrežu u kojoj živi vaš VM.

Mit prvi: korporativni DNS poslužitelji to rješavaju

Uređivanje datoteke resolvera klasičan je savjet i točan je otprilike pola vremena. Kada je točan, točan je zbog određenog razloga: generirana datoteka pokazuje na resolver koji poznaje samo javna imena, pa se upit za intranet.example.internal vraća kao nepostojeći iako je put u redu.

Prikvačiti VPN poslužitelje znači zaustaviti Windows da ponovno generira datoteku, jer svaka datoteka koju napišete ručno biva zamijenjena pri sljedećem pokretanju:

[network]
generateResolvConf = false

Spremite to kao /etc/wsl.conf, pokrenite wsl --shutdown iz Windowsa, zatim pokrenite distribuciju i napišite /etc/resolv.conf s poslužiteljima tunela prvima i javnim resolverom samo kao pričuvom. To je trajna promjena s troškom održavanja: datoteka više ne slijedi host, pa kada se korporativne DNS adrese promijene, distribucija nastavlja pitati stare. Netko mora posjedovati tu datoteku.

Također ne čini ništa kada je kvar širi. Ako curl na 1.1.1.1 istječe, klijent tunela filtrira virtualni preklopnik ili usmjerava podmrežu VM-a u tunel, a ispravan resolver daje vam samo imena do kojih se još uvijek ne može doći.

Mit drugi: promjena metrike se zadržava

Kada se imena razrješavaju, ali promet izlazi kroz fizički adapter, poluga su metrike sučelja. Dajte VPN adapteru visok trošak, a WSL preklopniku nizak:

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

Zatim zapamtite da se u mnogim verzijama klijenta tunelski adapter ponovno stvara pri svakom spajanju i metrika se vraća na zadanu vrijednost. Jednokratna naredba popravak je koji tiho istječe, obično tijekom vikenda, a zahtjev se vraća s «radilo je prošli tjedan». Zakazani zadatak koji pokreće VPN događaj ili skripta koju korisnik pokrene nakon spajanja poštena je verzija tog popravka.

Isti rok vrijedi za rute hosta dodane za jedan tvrdoglavi prefiks. Vrijedne su kao dijagnostika jer vam kažu je li problem jedna destinacija ili cijeli put, ali nisu arhitektura.

Mit treći: jedan popravak pokriva svaku verziju Windowsa

wsl-vpnkit je sidecar uzorak: mala distribucija posjeduje put na strani hosta i prosljeđuje za druge distribucije preko virtualnog socketa, pa promet aplikacija prestaje ovisiti o filtriranom preklopniku. Potreban je standardni put da radi, što znači ukloniti nadjačavanja networkingMode i dnsTunneling iz %UserProfile%\.wslconfig, vratiti generateResolvConf = true u svakoj radnoj distribuciji i pokrenuti uslugu pri prijavi.

Zrcalni način rada ugrađena je alternativa u Windowsu 11 22H2 i novijima, a to je jedna postavka plus gašenje:

[wsl2]
networkingMode=mirrored

Unutar distribucije ip addr tada ispisuje adaptere hosta, tunel se može pojaviti među njima, a DNS tuneliranje prosljeđuje upite kroz Windows resolver čak i kada klijent prepiše DNS popis. To nije univerzalno: neki filtrirajući upravljački programi još uvijek odbacuju zrcalni put, a Hyper-V pravila vatrozida mogu zahtijevati izričito dopuštenje. Microsoftov vodič za WSL mreže stranica je koju treba provjeriti prema svojoj verziji prije primjene recepta napisanog za noviju.

Testirajte tri stvari nakon svake promjene

Odaberite jedan mehanizam po stroju i zapišite ga, jer se dva loše kombiniraju. Sidecar povrh zrcalnog načina udvostručuje prosljeđivanje, a zrcalni host sa zastarjelim sidecar zapisom u .wslconfig obično pada nakon nadogradnje, a ne prije nje.

Što god odabrali, prihvatni test ista su tri zahtjeva unutar distribucije: interno ime, javno ime i sirova adresa. Zatim ih ponovite nakon odspajanja i ponovnog spajanja tunela te nakon wsl --shutdown. Ako samo interno ime pada, to je resolver politika; ako interno i javno ime padaju zajedno uz adresu koja radi, to je još uvijek resolver politika; ako sve pada, to je put.

Ako jedan interni host pada dok ostali rade, prestanite gledati resolver i potražite rutu koja nedostaje za taj prefiks. Ako sve radi do sljedećeg ponovnog spajanja, pronašli ste popravak koji ovisi o stanju u vrijeme izvođenja i mora se ponovno primjenjivati automatski ili zamijeniti jednim od dvaju mehanizama gore.