WSL2 не успадковує корпоративний VPN, і саме в цьому помилка

Внутрішня вікі відкривається в Edge, а git clone усередині дистрибутива завершується тайм-аутом. Це єдине спостереження зазвичай читають як «VPN блокує WSL2», і наступна година йде на редагування /etc/resolv.conf. Корисніше читання: WSL2 ніколи не мав мережевого шляху хоста — він працює в допоміжній ВМ із власним адаптером, власними маршрутами та файлом resolver, який Windows створює для нього. Усе подальше залежить від того, чого з цих трьох вам справді бракує.

ВМ має власний стек, метрики й resolver

У стандартному режимі NAT дистрибутив стоїть за віртуальним комутатором і виходить в інтернет через хост, але не бачить його адаптерів. ip addr показує один інтерфейс із приватною адресою, ip route показує маршрут за замовчуванням через цей комутатор, а /etc/resolv.conf — згенерований файл, що вказує на stub resolver, який вибрав Windows. Ніщо з цього не змінюється від того, що на боці Windows запустився VPN-клієнт.

Тому «браузер працює» доводить так мало. Браузер використовує стек хоста, тунель і resolver-політику хоста. Ваша оболонка використовує інший стек, який випадково ділить фізичну мережеву карту. Вони збігаються у сприятливому випадку й розходяться рівно тоді, коли VPN ставить фільтр, переписує список DNS або додає маршрут до підмережі віртуального комутатора.

Два тести вирішують, у якому світі ви перебуваєте, і вони мають виконуватися всередині дистрибутива:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Якщо імена не розв'язуються, а буквальна адреса відповідає, це проблема resolver. Якщо імена й адреси падають разом, це проблема шляху, і жодне редагування resolver її не зачепить. Далі йдуть докази з боку Windows: Get-NetAdapter | Get-DnsClientServerAddress і route print -4 показують, чи тунель зайняв підмережу, у якій живе ваша ВМ.

Перший міф: корпоративні DNS-сервери це виправляють

Редагування файлу resolver — класична порада, і вона правильна приблизно в половині випадків. Коли вона правильна, причина конкретна: згенерований файл указує на resolver, який знає лише публічні імена, тому запит intranet.example.internal повертається як неіснуючий, хоча шлях гаразд.

Закріпити сервери VPN означає зупинити повторну генерацію файлу Windows, бо будь-який файл, написаний вручну, замінюється під час наступного запуску:

[network]
generateResolvConf = false

Збережіть це як /etc/wsl.conf, виконайте wsl --shutdown з Windows, потім запустіть дистрибутив і запишіть /etc/resolv.conf із серверами тунелю першими й публічним resolver лише як запасним. Це тривала зміна з ціною обслуговування: файл більше не йде за хостом, тому коли корпоративні адреси DNS змінюються, дистрибутив продовжує питати старі. Хтось має володіти цим файлом.

Він також нічого не робить, коли збій ширший. Якщо curl до 1.1.1.1 завершується тайм-аутом, клієнт тунелю фільтрує віртуальний комутатор або спрямовує підмережу ВМ у тунель, і правильний resolver дає лише імена, до яких усе ще не можна дістатися.

Другий міф: зміна метрики тримається

Коли імена розв'язуються, але трафік виходить через фізичний адаптер, важіль — метрики інтерфейсів. Дайте адаптеру VPN високу вартість, а комутатору WSL низьку:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Потім пам'ятайте, що в багатьох збірках клієнта адаптер тунелю створюється заново при кожному підключенні, і метрика повертається до типового значення. Одноразова команда — це виправлення, яке тихо спливає, зазвичай за вихідні, і заявка повертається з «минулого тижня працювало». Заплановане завдання, яке запускає подія VPN, або скрипт, який користувач виконує після підключення, — чесна версія цього виправлення.

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

Третій міф: одне виправлення покриває кожну збірку Windows

wsl-vpnkit — це шаблон sidecar: невеликий дистрибутив володіє шляхом на боці хоста й пересилає за інші дистрибутиви через віртуальний сокет, тож трафік застосунків перестає залежати від відфільтрованого комутатора. Потрібен робочий стандартний шлях, тобто прибрати перевизначення networkingMode і dnsTunneling з %UserProfile%\.wslconfig, відновити generateResolvConf = true у кожному робочому дистрибутиві й запускати службу під час входу.

Дзеркальний режим — вбудована альтернатива в Windows 11 22H2 і новіших, і це одне налаштування плюс вимкнення:

[wsl2]
networkingMode=mirrored

Усередині дистрибутива ip addr тоді перелічує адаптери хоста, тунель може з'явитися серед них, а DNS-тунелювання пересилає запити через resolver Windows навіть коли клієнт переписує список DNS. Це не універсально: деякі драйвери фільтрації досі відкидають дзеркальний шлях, а правилам брандмауера Hyper-V може знадобитися явний дозвіл. Посібник із мереж WSL від Microsoft — це сторінка, яку слід звірити зі своєю збіркою, перш ніж застосовувати рецепт, написаний для новішої.

Після кожної зміни перевіряйте три речі

Виберіть один механізм на машину й запишіть його, бо два поєднуються погано. Sidecar поверх дзеркального режиму подвоює пересилання, а дзеркальний хост із застарілим записом sidecar у .wslconfig зазвичай падає після оновлення, а не до нього.

Що б ви не вибрали, приймальний тест — ті самі три запити всередині дистрибутива: внутрішнє ім'я, публічне ім'я й сира адреса. Потім повторіть їх після від'єднання й повторного підключення тунелю та після wsl --shutdown. Якщо падає лише внутрішнє ім'я, це resolver-політика; якщо внутрішнє й публічне імена падають разом із робочою адресою, це все ще resolver-політика; якщо падає все, це шлях.

Якщо один внутрішній хост падає, а решта працює, перестаньте дивитися на resolver і пошукайте відсутній маршрут для цього префікса. Якщо все працює до наступного перепідключення, ви знайшли виправлення, що залежить від стану часу виконання, і його треба застосовувати повторно автоматично або замінити одним із двох механізмів вище.