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 вимкнено. Ціна — невеликий скрипт, який треба запускати при кожному підключенні.

Виберіть один і запишіть його. Змішування дзеркальної конфігурації з ручними маршрутами дає дистрибутив із двома шляхами до одного префікса і без чіткого власника жодного з них. Один задокументований метод налагоджувати легше, ніж два напівналаштовані.

Отримайте поточні параметри тунелю з хоста

Зіставляйте адаптер за 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, перш ніж змінювати скрипт, бо ще одна правка маршруту не виправить пакет, який уже доходить до хоста.

Схожі статті