WSL2 не достига до VPN подмрежата: прочетете маршрута на хоста

Отвътре в дистрибуцията ping към вътрешен сървър изтича, докато същият адрес отговаря от Windows. VPN е свързан и маршрутът на Windows е правилен, значи разликата е границата на WSL. Проследете пътя от неуспешната команда обратно до интерфейса на хоста. Поправката не е фиксиран CIDR в конфигурационен файл; тя е да прочетете текущия адрес и да го добавите там, където дистрибуцията може да го използва.

Потвърдете къде спира пътят

Изпълнете същия тест от двете страни: решете и се свържете с един вътрешен хост от Windows, после го повторете в дистрибуцията. Успех в Windows плюс изтичане в дистрибуцията локализира повредата между двете, а не в VPN клиента или вътрешния сървър. Направете това преди да промените който и да е маршрут, за да описват двата резултата една и съща дестинация.

Вътре в дистрибуцията ip -4 addr показва виртуален адаптер с адрес от диапазона на WSL NAT, а ip route показва маршрут по подразбиране към шлюза на WSL. Няма маршрут за корпоративния префикс, защото тунелният адаптер на хоста няма съответствие вътре в дистрибуцията. Шлюзът по подразбиране води към WSL NAT, не към корпоративната мрежа.

Добавянето на корпоративния маршрут без предварително добавяне на локален адрес на достъпна връзка дава изтичане или грешка за недостъпна мрежа. Адресът е частта, която прави маршрута използваем, затова го прочетете първо и третирайте маршрута като втора стъпка.

Изберете огледална мрежа или маршрут със скрипт

Огледалната мрежа дава на дистрибуцията собствените интерфейси на хоста, така че тунелът и маршрутите му се появяват без копиране. Функцията зависи от скорошна компилация на Windows и от networkingMode=mirrored в .wslconfig, а включването ѝ променя несвързано поведение като пренасочването на 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 завършва редовете с връщане на каретка и без изчистването последното поле носи скрит знак, който кара команда за маршрут да се провали със объркваща грешка при анализ.

Приложете адреса и маршрута вътре в дистрибуцията

Инсталирайте адреса на тунела като адрес с префикс на интерфейса на дистрибуцията, после насочете корпоративния блок през шлюза на хоста:

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, а не от интерактивна обвивка. Скрипт, който чете адреса, добавя го, добавя маршрута и записва стойностите в журнал, превръща повтаряща се ръчна поправка в повтаряема, а журналът е първото нещо, което да прочетете, когато префиксът се промени.

Фиксирайте името и докажете пътя

Ядрото може да преименува интерфейса на дистрибуцията между eth1 и eth2 след превключване на мрежата и тогава скрипт, писан срещу име, редактира грешното устройство. Правило на udev, вързано към MAC, дава на интерфейса стабилен етикет:

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. Проверете защитната стена на хоста и собствената филтрация на VPN клиента, преди да промените скрипта, защото още една поправка на маршрут няма да оправи пакет, който вече достига до хоста.