WSL2 корпоративдик VPNди мураска албайт, жана бул — ката

WSL2 өзүнүн виртуалдык тармагында иштейт жана хосттун VPN стектерин эч качан мураска албайт. resolv.conf файлын оңдоодон мурун ат каталарын жол каталарынан ажыратыңыз.

Ички вики Edge'те ачылат, ал эми дистрибутивдин ичинде git clone убакыт бүтүп калат. Ушул жалгыз байкоо адатта «VPN WSL2ни тосмолоп жатат» деп окулат, кийинки саат /etc/resolv.conf файлын оңдоого кетет. Пайдалуураак окуу — WSL2де хосттун тармак жолу башында эле жок болгон: ал өзүнүн адаптери, өзүнүн маршруттары жана Windows ага түзгөн resolver файлы бар жардамчы VMде иштейт. Кийинкинин баары ушул үчөөнүн кайсынысы сизге чындыгында жок экенине байланыштуу.

VMдин өз стеги, метрикалары жана resolverи бар

Демейки NAT режиминде дистрибутив виртуалдык коммутатордун артында отурат жана интернетке хост аркылуу чыгат, бирок хосттун адаптерлерин көрбөйт. ip addr жеке дареги бар бир интерфейсти көрсөтөт, ip route ошол коммутатор аркылуу демейки маршрутту көрсөтөт, ал эми /etc/resolv.conf Windows тандаган stub resolverге шилтеме кылган түзүлгөн файл. Windows тарапта VPN кардары ишке киргенинен улам булардын эч бири өзгөрбөйт.

Ошондуктан «браузер иштейт» ушунча аз нерсени далилдейт. Браузер хосттун стегин, туннелди жана хосттун resolver саясатын колдонот. Сиздин shell башка стекти колдонот, ал кокустан физикалык тармак картасын бөлүшөт. Алар жакшы учурда дал келишет жана VPN чыпка орноткондо, DNS тизмесин кайра жазганда же виртуалдык коммутатордун кошумча тармагына маршрут кошкондо так ошондо айырмаланышат.

Кайсы дүйнөдө экениңизди эки тест чечет, жана алар дистрибутивдин ичинде иштеши керек:

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

Сөзмө-сөз дарек жооп берип жатканда аттардын ишке ашпашы — resolver маселеси. Аттар менен даректердин чогуу ишке ашпашы — жол маселеси, жана resolverди канча оңдосоңуз да ага тийбейт. Андан кийин Windows тараптан далилдер келет: Get-NetAdapter | Get-DnsClientServerAddress жана route print -4 туннелдин VM жашаган кошумча тармакты ээлеп алганын көрсөтөт.

Биринчи уламыш: корпоративдик DNS серверлери маселени чечет

resolver файлын оңдоо — классикалык кеңеш жана ал болжол менен жарым учурда туура. Туура болгондо, белгилүү себептен улам туура: түзүлгөн файл элге ачык аттарды гана билген resolverге шилтеме кылат, ошондуктан intranet.example.internal жөнүндө суроо жол таза болсо да жок деп кайтат.

VPN серверлерин бекитүү Windowsду файлды кайра түзүүдөн токтотууну билдирет, анткени кол менен жазылган ар кандай файл кийинки баштоодо алмаштырылат:

[network]
generateResolvConf = false

Аны /etc/wsl.conf катары сактаңыз, Windowsдон wsl --shutdown иштетиңиз, андан кийин дистрибутивди баштап жана /etc/resolv.conf жазыңыз, туннелдин серверлери биринчи, ал эми коомдук resolver тек камдык катары. Бул — тейлөө чыгыны бар туруктуу өзгөрүү: файл эми хостту ээрчибейт, ошондуктан корпоративдик DNS даректери өзгөргөндө дистрибутив эскилерин сурай берет. Бирөө ошол файлдын ээси болушу керек.

Жагдай кеңири болгондо да эч нерсе кылбайт. Эгер curl 1.1.1.1 дарегине убакыт бүтсө, туннел кардары виртуалдык коммутаторду чыпкалап жатат же VMдин кошумча тармагын туннелге багыттап жатат, ал эми туура resolver сизге дагы эле жетүүгө болбой турган аттарды гана берет.

Экинчи уламыш: метрика өзгөрүүсү сакталат

Аттар чечилип, бирок трафик физикалык адаптерден чыкса, тутка — интерфейс метрикалары. VPN адаптерине жогорку чыгым, WSL коммутаторуна төмөн чыгым бериңиз:

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

Андан кийин көптөгөн кардар курулуштарында туннел адаптери ар бир туташууда кайра түзүлөрүн жана метрика демейки маанисине кайтарын унутпаңыз. Бир жолку буйрук — үнсүз бүтүүчү оңдоо, адатта дем алыш күндөрү, жана билет «өткөн жумада иштеп жаткан» деген сөз менен кайтат. VPN окуясы менен ишке кирүүчү пландаштырылган тапшырма же колдонуучу туташкандан кийин иштетүүчү скрипт — бул оңдоонун чынчыл версиясы.

Ошол эле мөөнөт бир кежир префикс үчүн кошулган хост маршруттарына да тиешелүү. Диагностика катары алар баалуу, анткени маселе бир багытпы же бүт жолбу экенин айтышат, бирок алар архитектура эмес.

Үчүнчү уламыш: бир оңдоо ар бир Windows курулушун камтыйт

ApproachWhat it actually does
Resolver pinFixes private names only; no effect on path failures
Sidecar distributionForwards traffic over a socket to a helper VM, so the switch's filter no longer matters
Mirrored networkingGives the distribution the host's interface set; also enables DNS tunnelling

wsl-vpnkit — sidecar үлгүсү: кичине дистрибутив хост жагындагы жолду ээлейт жана башка дистрибутивдер үчүн виртуалдык сокет аркылуу өткөрүп берет, ошондуктан колдонмо трафиги чыпкаланган коммутаторго көз каранды болууну токтотот. Стандарттык жол иштеши керек, башкача айтканда networkingMode жана dnsTunneling кайра аныктоолорун %UserProfile%\.wslconfig файлынан алып салуу, ар бир иштеген дистрибутивде generateResolvConf = true параметрин калыбына келтирүү жана кирүүдө кызматты баштоо.

Күзгү режим Windows 11 22H2 жана андан кийинкилердеги курулган альтернатива, жана ал бир жөндөө плюс бир өчүрүү:

[wsl2]
networkingMode=mirrored

Дистрибутивдин ичинде ip addr андан кийин хосттун адаптерлерин тизмелейт, туннел алардын арасында көрүнүшү мүмкүн, жана DNS туннелдөө сурамдарды Windows resolverи аркылуу өткөрөт кардар DNS тизмесин кайра жазса да. Бул универсалдуу эмес: кээ бир чыпка драйверлери күзгү жолун дагы эле ташташат, ал эми Hyper-V файрвол эрежелерине ачык уруксат керек болушу мүмкүн. Microsoftтун WSL тармак жетекчилиги — жаңыраак үчүн жазылган рецептти колдонуудан мурун өз курулушуңуз менен салыштыра турган барак.

Ар бир өзгөртүүдөн кийин үч нерсени текшериңиз

Ар бир машинага бир механизм тандап жазып коюңуз, анткени экөө начар айкалышат. Күзгү режимдин үстүндөгү sidecar өткөрүүнү эки эсе көбөйтөт, ал эми .wslconfig файлында эскирген sidecar жазуусу бар күзгү хост жаңыртуудан кийин ишке ашпайт, мурун эмес.

Эмнени тандасаңыз да, кабыл алуу тести — дистрибутивдин ичиндеги ошол эле үч сурам: ички ат, коомдук ат жана чийки дарек. Андан кийин аларды туннелди ажыратып кайра туташтыргандан кийин жана wsl --shutdown буйругунан кийин кайталаңыз. Ички ат гана ишке ашпаса — resolver саясаты; ички жана коомдук аттар чогуу ишке ашпай, дарек иштесе — дагы эле resolver саясаты; баары ишке ашпаса — жол.

Бир ички хост ишке ашпай, калганы иштеп жатса, resolverге кароону токтотуп, ошол префикс үчүн жок маршрутту издеңиз. Баары кийинки кайра туташууга чейин иштесе, сиз аткаруу убактысынын абалына көз каранды оңдоону таптыңыз, жана аны автоматтык түрдө кайра колдонуу же жогорудагы эки механизмдин бири менен алмаштыруу керек.

Тектеш макалалар