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 і ад networkingMode=mirrored у .wslconfig, а яе ўключэнне змяняе незвязаныя паводзіны, напрыклад перанакіраванне localhost. Разглядайце гэта як змену платформы, а не як наладу маршруту. Калі зборка падтрымлівае яе і пабочныя эфекты прымальныя, гэта самы кароткі шлях.

Больш вузкі падыход захоўвае стандартны NAT і капіруе адрас і маршрут тунеля ў дыстрыбутыў пры кожным узняцці тунеля. Ён працуе на большай колькасці зборак, не змяняе паводзіны localhost і бачна падае, калі VPN выключаны. Кошт — невялікі скрыпт, які трэба запускаць пры кожным падключэнні.

Выберыце адзін і запішыце яго. Змешванне люстраванай канфігурацыі з ручнымі маршрутамі стварае дыстрыбутыў з двума шляхамі да аднаго прэфікса і без яснага ўласніка любога з іх. Адзін дакументаваны метад лягчэй адладжваць, чым два паўналаджаныя.

Выміце бягучыя параметры тунеля з хоста

Супacтаўляйце адаптар па 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 перад змяненнем скрыпта, бо яшчэ адно выпраўленне маршруту не выратуе пакет, які ўжо дасягае хоста.

Падобныя артыкулы