WSL2 VPN қосымша желісіне жетпейді: хост маршрутын оқыңыз

Дистрибутив өз NAT-ының артында отырады және Windows туннелін ешқашан көрмейді. Хосттан ағымдағы мекенжай мен префиксті оқып, оларды WSL ішіне қосыңыз.

Дистрибутивтің ішінен ішкі серверге ping уақыт бітімімен аяқталады, ал сол мекенжай Windows-тан жауап береді. VPN қосылған және Windows маршруты дұрыс, сондықтан алшақтық — WSL шекарасы. Сәтсіз пәрменнен хост интерфейсіне дейінгі жолды жүріп өтіңіз. Түзету конфигурация файлындағы тіркелген CIDR емес; ол — ағымдағы мекенжайды оқып, оны дистрибутив пайдалана алатын жерге қосу.

Жолдың қайда тоқтайтынын растаңыз

Екі жақта бірдей тестті орындаңыз: Windows-тан бір ішкі хостты шешіп, оған қосылыңыз, содан кейін оны дистрибутивте қайталаңыз. Windows-тағы сәттілік пен дистрибутивтегі уақыт бітімі ақауды екеуінің арасында анықтайды, VPN клиентінде немесе ішкі серверде емес. Мұны кез келген маршрутты өзгертуден бұрын жасаңыз, сонда екі нәтиже бірдей межелі орынды сипаттайды.

Дистрибутивтің ішінде ip -4 addr WSL NAT ауқымынан мекенжайы бар виртуалды адаптерді көрсетеді, ал ip route WSL қақпасына бағытталған әдепкі маршрутты көрсетеді. Корпоративтік префикс үшін маршрут жоқ, өйткені хосттың туннель адаптерінің дистрибутив ішінде баламасы жоқ. Әдепкі қақпа WSL NAT-қа апарады, корпоративтік желіге емес.

Корпоративтік маршрутты алдымен қолжетімді байланыста жергілікті мекенжай қоспай-ақ қосу уақыт бітімін немесе желіге қолжетімсіздік қатесін тудырады. Маршрутты пайдалы ететін бөлік — мекенжай, сондықтан оны бірінші оқыңыз, ал маршрутты екінші қадам деп санаңыз.

Айналанған желіні немесе скрипттік маршрутты таңдаңыз

Айналанған желі дистрибутивке хосттың өз интерфейстерін береді, сондықтан туннель мен оның маршруттары көшірусіз пайда болады. Функция жаңа Windows құрастырмасына және .wslconfig ішіндегі networkingMode=mirrored параметріне тәуелді, ал оны қосу localhost жіберілімі сияқты байланыссыз мінез-құлықты өзгертеді. Оны маршрутты реттеу емес, платформалық өзгеріс деп қараңыз. Құрастырма қолдаса және жанама әсерлер қолайлы болса, бұл ең қысқа жол.

Тар тәсіл әдепкі NAT-ты сақтайды және туннель көтерілген сайын туннельдің мекенжайы мен маршрутын дистрибутивке көшіреді. Ол көбірек құрастырмаларда жұмыс істейді, localhost мінез-құлқын өзгертпейді және VPN өшірулі болғанда көрінетін түрде сәтсіздікке ұшырайды. Бағасы — әр қосылымда іске қосылуы керек шағын скрипт.

Біреуін таңдап, жазып қойыңыз. Айналанған конфигурацияны қолмен жасалған маршруттармен араластыру бір префикске екі жолы бар және ешқайсысының нақты иесі жоқ дистрибутив жасайды. Бір құжатталған әдісті жөндеу екі жартылай конфигурацияланғаннан оңай.

Ағымдағы туннель мәліметтерін хосттан алыңыз

Адаптерді атауы бойынша емес, MAC мекенжайы бойынша сәйкестендіріңіз, өйткені атаулар VPN клиентімен және қосылу ретімен өзгереді. Адаптерлерді бір рет тізімдеп, туннель адаптерінің MAC-ын жазып алыңыз, содан кейін оның мекенжайы мен префиксін сұраңыз. MAC қайта қосылулар арасында виртуалды адаптермен бірге қалады, ал атау мен интерфейс индексі қалмайды:

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

Қақпа интерфейс конфигурациясынан шығады. Алдымен интерфейс индексін алыңыз, содан кейін келесі секірісті оқыңыз. Индекс қайта жүктеуден немесе адаптерді қалпына келтіруден кейін өзгеруі мүмкін, сондықтан скрипт оны сақтамай, оқуы керек:

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

Шығысты айнымалыға меншіктемес бұрын tr -d '\r' арқылы өткізіңіз. PowerShell жолдарды carriage return-мен аяқтайды, ал тазартпасаңыз соңғы өріс жасырын таңба тасымалдайды, ол маршрут пәрменін түсініксіз талдау қатесімен істен шығарады.

Мекенжай мен маршрутты дистрибутив ішінде қолданыңыз

Туннель мекенжайын дистрибутив интерфейсіне префиксті мекенжай ретінде орнатыңыз, содан кейін корпоративтік блокты хосттың қақпасы арқылы бағыттаңыз:

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

Қосылым циклге түскенде NetworkManager қолмен конфигурацияланған мекенжайды тастап кетеді, ал ешбір DHCP клиенті орынбасар сұрамайды. Әдісті автоматты етіп қойыңыз, сонда әр қайта қосылу мекенжайды жаңартады, содан кейін қосылымды қайта көтеріңіз. Қолмен әдіс бірінші қайта қосылуға дейін тұрақты көрінеді:

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

Екі қадамды да VPN-ді іске қосатын hook ішінен орындаңыз, интерактивті shell-ден емес. Мекенжайды оқып, оны қосып, маршрутты қосып, мәндерді логқа жазатын скрипт қайталанатын қолмен жөндеуді қайталауға болатын жөндеуге айналдырады, ал префикс өзгергенде бірінші оқылатын нәрсе — лог.

Атауды бекітіп, жолды дәлелдеңіз

Желі ауысқаннан кейін ядро дистрибутив интерфейсінің атауын eth1 мен eth2 арасында өзгертуі мүмкін, ал атауға қарап жазылған скрипт сонда қате құрылғыны өңдейді. MAC-қа байланған udev ережесі интерфейске тұрақты белгі береді:

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

Содан кейін мекенжаймен, маршрутпен және нақты TCP қосылымымен тексеріңіз: ip -4 addr show dev vpn, ip route get 172.20.4.10 және белгілі ішкі портқа қосылу. Маршрут іздеуі vpn құрылғысын және сіз қосқан бастау мекенжайын атауы керек.

Егер үшеуі де дистрибутив ішінде өтсе де қосылым әлі сәтсіз болса, пакет WSL-ден шығып, Windows жағында тасталады. Скриптті өзгертуден бұрын хосттың firewall-ын және VPN клиентінің өз сүзгісін тексеріңіз, өйткені тағы бір маршрутты өңдеу хостқа әлдеқашан жетіп жатқан пакетті түзетпейді.

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