WSL2k ez du enpresako VPN-a heredatzen, eta hori da akatsa

Barneko wikia Edge-n kargatzen da, baina git clone banaketaren barruan denbora-mugara iristen da. Behaketa bakarra hori «VPN-ak WSL2 blokeatzen du» gisa irakurtzen da normalean, eta hurrengo ordua /etc/resolv.conf editatzen igarotzen da. Irakurketa erabilgarriagoa da WSL2k ez zuela inoiz hostaren sare-bidea izan: VM lagungarri batean exekutatzen da, bere egokitzailea, bere ibilbideak eta Windows-ek berarentzat sortzen duen resolver fitxategia dituela. Ondorengo guztia hiru horietatik zein falta zaizun araberakoa da.

VM-ak bere pila, metrika eta resolver propioa ditu

NAT modu lehenetsian, banaketa switch birtual baten atzean dago eta internetera hostaren bidez iristen da, baina ez ditu hostaren egokitzaileak ikusten. ip addr interfaze bat erakusten du helbide pribatuarekin, ip route switch horren bidezko ibilbide lehenetsia erakusten du, eta /etc/resolv.conf Windows-ek aukeratutako stub resolver batera bideratzen duen sortutako fitxategia da. Horietako ezerk ez du aldatzen Windows aldean VPN bezero bat abiatu delako.

Horregatik frogatzen du hain gutxi «nabigatzaileak funtzionatzen du» esateak. Nabigatzaileak hostaren pila, tunela eta hostaren resolver politika erabiltzen ditu. Zure shellak beste pila bat erabiltzen du, fisikoki sare-txartel bat partekatzen duena kasualitatez. Kasu zoriontsuan bat datoz, eta zehazki orduan dibergitzen dute VPN-ak iragazki bat instalatzen duenean, DNS zerrenda berridazten duenean edo switch birtualaren azpisarearentzako ibilbide bat gehitzen duenean.

Bi probak erabakitzen dute zein mundutan zauden, eta banaketaren barruan exekutatu behar dira:

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

Izenek huts egitea helbide literal batek erantzuten duen bitartean resolver arazoa da. Izenek eta helbideek elkarrekin huts egitea bide arazoa da, eta resolver editatzeak ez du hura ukittuko. Windows aldeko frogak datoz ondoren: Get-NetAdapter | Get-DnsClientServerAddress eta route print -4 erakusten dute tuneleak zure VM bizi den azpisarea hartu duen.

Lehen mitoa: enpresako DNS zerbitzariek konpontzen dute

Resolver fitxategia editatzea da aholku klasikoa, eta denboraren erdian asmatzen du gutxi gorabehera. Asmatzen duenean, arrazoi zehatz batengatik asmatzen du: sortutako fitxategiak izen publikoak soilik ezagutzen dituen resolver batera bideratzen du, beraz intranet.example.internal-ren kontsulta existitzen ez den gisa itzultzen da bidea ondo egon arren.

VPN-aren zerbitzariak finkatzeak Windows fitxategia birsortzeari uztea esan nahi du, eskuz idazten duzun edozein fitxategi hurrengo abioan ordezkatzen delako:

[network]
generateResolvConf = false

Gorde hori /etc/wsl.conf gisa, exekutatu wsl --shutdown Windows-etik, gero abiatu banaketa eta idatzi /etc/resolv.conf tuneleko zerbitzariak lehenengo eta resolver publiko bat erreserba gisa soilik. Mantentze-kostua duen aldaketa iraunkorra da: fitxategiak ez du hosta gehiago jarraitzen, beraz enpresako DNS helbideak aldatzen direnean banaketak zaharrak galdetzen jarraitzen du. Norbaitek fitxategi horren jabe izan behar du.

Ez du ezer egiten huts egitea zabalagoa denean ere. curl 1.1.1.1-ra denbora-mugara iristen bada, tuneleko bezeroak switch birtuala iragazten ari da edo VM-aren azpisarea tunelean bideratzen, eta resolver zuzen batek iristeko modurik ez duten izenak ematen dizkizu soilik.

Bigarren mitoa: metrika-aldaketak irauten du

Izenak ebazten direnean baina trafikoak egokitzaile fisikoetatik irteten duenean, interfaze-metrikak dira palanka. Eman kostu altua VPN egokitzaileari eta baxua WSL switchari:

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

Gero gogoratu bezeroaren bertsio askotan tuneleko egokitzailea konexio bakoitzean berriz sortzen dela eta metrika bere lehenespenera itzultzen dela. Behin-behineko komando bat isil-isilik iraungitzen den konponketa da, normalean asteburu batean, eta txartela «iazko astean funtzionatzen zuen» esanez itzultzen da. VPN gertaerak abiarazitako zeregin programatu bat, edo erabiltzaileak konektatu ondoren exekutatzen duen script bat, konponketa honen bertsio zintzoa da.

Iraungitze berbera aplikatzen zaie prefixu temati baterako gehitutako host ibilbideei. Diagnostiko gisa balio dute, problemak helmuga bat edo bide osoa den esaten dizutelako, baina ez dira arkitektura.

Hirugarren mitoa: konponketa bakarrak Windows bertsio guztiak estaltzen ditu

wsl-vpnkit sidecar eredua da: banaketa txiki batek host aldeko bidea dauka eta beste banaketentzat birbideratzen du socket birtual baten bidez, aplikazioen trafikoak iragazitako switcharen mende egoteari uzten diola. Bide estandarra funtzionatzea behar du, hau da, networkingMode eta dnsTunneling gainidazketak %UserProfile%\.wslconfig-tik kentzea, generateResolvConf = true banaketa funtzional bakoitzean berrezartzea eta zerbitzua saioa hastean abiaraztea.

Ispilu modua Windows 11 22H2 eta berriagoetan integratutako alternatiba da, eta ezarpen bat gehi itzaltze bat da:

[wsl2]
networkingMode=mirrored

Banaketaren barruan ip addr-k hostaren egokitzaileak zerrendatzen ditu orduan, tunela haien artean ager daiteke, eta DNS tunelak Windows resolveraren bidez birbideratzen ditu kontsultak bezeroak DNS zerrenda berridatzi arren. Ez da unibertsala: iragazki kontrolatzaile batzuek ispilu bidea baztertzen dute oraindik, eta Hyper-V suebakiko arauek baimen esplizitua behar izan dezakete. Microsoften WSL sare gida zure bertsioarekin alderatzeko orria da, berriago batentzat idatzitako errezeta aplikatu aurretik.

Probatu hiru gauza aldaketa bakoitzaren ondoren

Aukeratu mekanismo bat makinako eta idatzi, biak gaizki konbinatzen direlako. Ispilu moduaren gaineko sidecar batek birbideratzea bikoizten du, eta .wslconfig-n sidecar sarrera zaharkitua duen ispilu host batek huts egiten du normalean bertsio-berritzearen ondoren, ez aurretik.

Edozer aukeratu baduzu ere, onarpen proba banaketaren barruko hiru eskaera berberak dira: barne izen bat, izen publiko bat eta helbide gordin bat. Gero errepikatu tunela deskonektatu eta berriz konektatu ondoren, eta wsl --shutdown ondoren. Barne izenak bakarrik huts egiteak resolver politika esan nahi du; barne eta izen publikoek elkarrekin huts egiteak helbide batek funtzionatzen duenean resolver politika esan nahi du oraindik; denek huts egiteak bidea esan nahi du.

Barne host batek huts egiten badu gainerakoek funtzionatzen duten bitartean, utzi resolverrari begiratzeari eta bilatu prefixu horretarako falta den ibilbide bat. Denak hurrengo berriz konexiora arte funtzionatzen badu, exekuzio-denborako egoeraren mende dagoen konponketa bat aurkitu duzu, eta automatikoki berriro aplikatu behar da edo goiko bi mekanismoetako batekin ordezkatu.