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-ге қарауды тоқтатып, сол префикс үшін жетіспейтін маршрутты іздеңіз. Барлығы келесі қайта қосылуға дейін жұмыс істесе, сіз орындалу уақытының күйіне тәуелді түзету таптыңыз, және оны автоматты түрде қайта қолдану керек немесе жоғарыдағы екі механизмнің бірімен ауыстыру керек.

Қатысты мақалалар