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 пред да ја смените скриптата, бидејќи уште едно уредување на рута нема да го поправи пакетот што веќе стигнува до домаќинот.