WSL2 hairithi VPN ya shirika, na hilo ndilo hitilafu
WSL2 hufanya kazi katika mtandao wake pepe na kamwe hairithi tabaka la VPN la mwenyeji. Tenganisha kushindwa kwa majina na kushindwa kwa njia kabla ya kuhariri resolv.conf.
Wiki ya ndani hupakia katika Edge, wakati git clone ndani ya usambazaji unaishia kwa muda. Uchunguzi huo mmoja kwa kawaida husomwa kama «VPN inazuia WSL2», na saa inayofuata huenda kwenye kuhariri /etc/resolv.conf. Usomaji wenye faida zaidi ni kwamba WSL2 haikuwa na njia ya mtandao ya mwenyeji tangu mwanzo: inafanya kazi katika VM msaidizi yenye adapta yake, njia zake na faili ya resolver ambayo Windows huizalisha kwa ajili yake. Kila kitu kinachofuata kinategemea ni kipi kati ya hivyo vitatu ambacho kinakosekana kwako.
VM ina tabaka, vipimo na resolver vyake
Katika hali ya kawaida ya NAT, usambazaji unakaa nyuma ya swichi pepe na kufikia intaneti kupitia mwenyeji, lakini hauoni adapta za mwenyeji. ip addr huonyesha kiolesura kimoja chenye anwani ya faragha, ip route huonyesha njia ya kawaida kupitia swichi hiyo, na /etc/resolv.conf ni faili iliyozalishwa inayoelekeza kwa stub resolver iliyochaguliwa na Windows. Hakuna kati ya hivi hubadilika kwa sababu mteja wa VPN ulianzishwa upande wa Windows.
Ndiyo sababu «kivinjari kinafanya kazi» huthibitisha kidogo sana. Kivinjari hutumia tabaka la mwenyeji, handaki na sera ya resolver ya mwenyeji. Shell yako hutumia tabaka lingine ambalo kwa bahati linashiriki kadi ya mtandao halisi. Zinakubaliana katika hali nzuri na hutofautiana hasa wakati VPN inasakinisha kichujio, inaandika upya orodha ya DNS au inaongeza njia kwa subnet ya swichi pepe.
Majaribio mawili huamua uko katika ulimwengu upi, na lazima yaendeshwe ndani ya usambazaji:
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
Majina kushindwa wakati anwani halisi inajibu ni tatizo la resolver. Majina na anwani kushindwa pamoja ni tatizo la njia, na hakuna uhariri wa resolver utakaogusa. Kisha huja ushahidi wa upande wa Windows: Get-NetAdapter | Get-DnsClientServerAddress na route print -4 huonyesha kama handaki limechukua subnet ambayo VM yako inaishi.
Imani potofu ya kwanza: seva za DNS za shirika hulirekebisha
Kuhariri faili ya resolver ni ushauri wa kawaida, na ni sahihi takriban nusu ya wakati. Inapokuwa sahihi, ni kwa sababu mahususi: faili iliyozalishwa inaelekeza kwa resolver inayojua majina ya umma pekee, kwa hivyo swali la intranet.example.internal hurudi kama halipo ingawa njia iko sawa.
Kubandika seva za VPN kunamaanisha kusimamisha Windows kuzalisha upya faili, kwa sababu faili yoyote unayoandika kwa mkono hubadilishwa wakati wa kuanza unaofuata:
[network]
generateResolvConf = false
Hifadhi hiyo kama /etc/wsl.conf, endesha wsl --shutdown kutoka Windows, kisha anzisha usambazaji na uandike /etc/resolv.conf ukiwa na seva za handaki kwanza na resolver ya umma kama chelezo pekee. Hii ni mabadiliko ya kudumu yenye gharama ya matengenezo: faili haifuati mwenyeji tena, kwa hivyo anwani za DNS za shirika zinapobadilika usambazaji unaendelea kuuliza zile za zamani. Mtu lazima amiliki faili hiyo.
Pia haifanyi chochote wakati hitilafu ni pana. Ikiwa curl hadi 1.1.1.1 inaishia kwa muda, mteja wa handaki anachuja swichi pepe au anaelekeza subnet ya VM kwenye handaki, na resolver sahihi inakupa majina ambayo bado hayawezi kufikiwa.
Imani potofu ya pili: mabadiliko ya kipimo yanadumu
Wakati majina yanatatuliwa lakini trafiki inatoka kupitia adapta halisi, vipimo vya kiolesura ndio kianzio. Ipe adapta ya VPN gharama kubwa na swichi ya WSL gharama ndogo:
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1
Kisha kumbuka kwamba katika miundo mingi ya mteja adapta ya handaki huundwa upya kwa kila muunganisho na kipimo hurudi kwa chaguo-msingi. Amri ya mara moja ni marekebisho yanayoisha kimya, kwa kawaida mwishoni mwa wiki, na tiketi hurudi na «ilifanya kazi wiki iliyopita». Kazi iliyoratibiwa inayochochewa na tukio la VPN, au script ambayo mtumiaji huendesha baada ya kuunganisha, ni toleo la uaminifu la marekebisho haya.
Muda huo huo wa kuisha unatumika kwa njia za mwenyeji zilizoongezwa kwa kiambishi kimoja kichwa-ngumu. Zina thamani kama uchunguzi, kwa sababu huonyesha kama tatizo ni lengo moja au njia yote, lakini si usanifu.
Imani potofu ya tatu: marekebisho moja hufunika kila muundo wa Windows
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit ni mtindo wa sidecar: usambazaji mdogo unamiliki njia upande wa mwenyeji na husambaza kwa usambazaji wengine kupitia soketi pepe, kwa hivyo trafiki ya programu inaacha kutegemea swichi iliyochujwa. Inahitaji njia ya kawaida ifanye kazi, yaani kuondoa ubatilishaji networkingMode na dnsTunneling kutoka %UserProfile%\.wslconfig, kurejesha generateResolvConf = true katika kila usambazaji unaofanya kazi na kuanzisha huduma wakati wa kuingia.
Hali ya kioo ni mbadala iliyojengwa ndani katika Windows 11 22H2 na baadaye, na ni mpangilio mmoja pamoja na kuzima moja:
[wsl2]
networkingMode=mirrored
Ndani ya usambazaji ip addr kisha huorodhesha adapta za mwenyeji, handaki linaweza kuonekana kati yao, na handaki la DNS husambaza maulizo kupitia resolver ya Windows hata wakati mteja anaandika upya orodha ya DNS. Si kwa wote: baadhi ya viendeshi vya kichujio bado hukataa njia ya kioo, na sheria za ngome za Hyper-V zinaweza kuhitaji idhini ya wazi. Mwongozo wa mtandao wa WSL wa Microsoft ni ukurasa wa kulinganisha na muundo wako kabla ya kutumia mapishi yaliyoandikwa kwa mpya zaidi.
Jaribu mambo matatu baada ya kila mabadiliko
Chagua utaratibu mmoja kwa kila mashine na uandike, kwa sababu zote mbili huchanganyika vibaya. Sidecar juu ya hali ya kioo huongeza mara mbili usambazaji, na mwenyeji wa kioo aliye na ingizo la sidecar lililopitwa na wakati katika .wslconfig huelekea kushindwa baada ya uboreshaji, si kabla.
Chochote ulichochagua, jaribio la kukubalika ni maombi hayo matatu ndani ya usambazaji: jina la ndani, jina la umma na anwani mbichi. Kisha yarudie baada ya kukatisha na kuunganisha tena handaki, na baada ya wsl --shutdown. Jina la ndani pekee kushindwa ni sera ya resolver; majina ya ndani na ya umma kushindwa pamoja na anwani inayofanya kazi bado ni sera ya resolver; kila kitu kushindwa ni njia.
Ikiwa mwenyeji mmoja wa ndani anashindwa wakati wengine wanafanya kazi, acha kuangalia resolver na utafute njia inayokosekana kwa kiambishi hicho. Ikiwa kila kitu kinafanya kazi hadi muunganisho unaofuata, umepata marekebisho yanayotegemea hali ya wakati wa utekelezaji, na lazima yatumike tena kiotomatiki au yabadilishwe na moja ya taratibu mbili hapo juu.