WSL2 + VPN: чому ламається (і як виправити)

Ментальна модель: чому WSL2 і VPN конфліктують

WSL2 — це не суміснісна оболонка в старому розумінні. Це легка віртуальна машина з реальним ядром Linux.
З погляду мережі вона поводиться як хост, що сидить за невеликим NAT‑шлюзом, реалізованим Windows.
Ваш дистрибутив Linux отримує адресу в приватному діапазоні (зазвичай 172.16.0.0/12 або приблизно 192.168.0.0/16),
а Windows робить трансляцію і форвардинг.

VPN‑клієнти, натомість, професійно нав’язливі. Вони встановлюють віртуальні адаптери, підключають маршрути,
змінюють DNS, застосовують політики і інколи навмисно блокують «не‑корпоративні» шляхи форвардингу.
VPN зазвичай виходить із припущення, що має справу з одним стеком мережі хоста. WSL2 — це другий стек за ним.
Отже маємо два домени маршрутизації й щонайменше три місця, де DNS можуть «допомагати»:
Windows, сам VPN‑клієнт і автогенерований /etc/resolv.conf у WSL.

Куди реально йдуть пакети

Коли процес у WSL2 підключається до git.internal.corp, відбувається так:

• Linux‑додаток питає локальний резолвер Linux про DNS.
• Резолвер Linux читає /etc/resolv.conf (часто вказує на IP‑резолвер на боці Windows).
• Трафік виходить із WSL VM до хоста Windows через віртуальний комутатор WSL.
• Windows вирішує, який інтерфейс/маршрут переможе: VPN‑адаптер, Wi‑Fi/Ethernet або «ні».
• VPN‑клієнт може виконувати NAT, шифрування або блокувати форвардинг залежно від політики.

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

Жарт №1: VPN‑клієнти схожі на котів — незалежні, територіальні й переконані, що вони єдині в домі, хто має значення.

Неприємна правда

Деякі VPN‑політики навмисно ускладнюють роботу WSL2. Не тому, що WSL2 — зло, а тому, що це фактично друга машина.
Команди безпеки переймаються про неманеджовані Linux‑середовища, що можуть повертатися у внутрішню мережу.
Тому «виправлення» може бути не в налаштуванні, а в «отримати дозвіл від VPN‑команди» або «використовувати санкціоновану VM для розробки».
Проте в багатьох компаніях це просто зіткнення налаштувань і значень за замовчуванням.

Швидка діагностика (перевірте 1/2/3)

Коли WSL2 + VPN ламаються, не починайте з перевстановлення WSL або одночасної зміни десяти налаштувань.
Робіть наступне в порядку. Кожен крок звужує домен помилки.

1) Це DNS чи маршрутизація?

• Якщо ping 10.x.x.x працює, а ping git.internal.corp — ні, це DNS.
• Якщо DNS резольвиться в правильний IP, але TCP не може встановити з’єднання, це маршрутизація/фаєрвол/MTU.
• Якщо працюють лише деякі внутрішні підмережі, це проблема інжекції маршрутів для split tunnel.

2) Порівняйте поведінку Windows і WSL

• Якщо Windows може дістатися внутрішніх ресурсів, а WSL — ні, проблема на межі NAT/форвардингу або в передачі DNS.
• Якщо Windows теж не може — перестаньте звинувачувати WSL. Спочатку виправте VPN‑з’єднання, маршрути або корпоративний DNS.

3) Визначте інтерфейс, який має перемогти

• Full tunnel: маршрут за замовчуванням має йти через VPN. DNS має бути корпоративним.
• Split tunnel: лише певні внутрішні префікси повинні йти через VPN; за замовчуванням має залишатися локальний інтернет.
• У будь‑якому випадку: трафік WSL має бути дозволено проходити через Windows до цього інтерфейсу.

4) MTU перевіряти в останню чергу (але не забувайте)

Проблеми з MTU виглядають як «DNS працює, ping працює, HTTPS зависає» або «малі запити проходять, великі — зависають».
Якщо бачите таку картину, спочатку перевірте MTU, перш ніж марнувати годину на таблиці маршрутів.

Факти та історія: чому це постійна плутанина

• WSL1 і WSL2 мають принципово різні мережі. WSL1 ділив мережевий стек Windows; WSL2 NAT‑иться за VM.
• WSL2 використовує в основі Hyper‑V virtual switch. Навіть на Windows Home каналізація поводиться як міні‑Hyper‑V.
• Багато VPN‑клієнтів досі постачають ядрові драйвери. Вони глибоко інтегруються в мережу Windows, щоб застосовувати політику й маршрути.
• DNS з «поділом горизонту» (split horizon) поширений у підприємствах. Той самий хостнейм резольвиться по‑різному всередині і зовні VPN, і застарілі резолвери — катастрофа.
• NRPT і DNS за інтерфейсом — це Windows‑фінт. Windows може відправляти різні DNS‑запити до різних серверів залежно від доменних правил; Linux за замовчуванням так не робить.
• MTU‑болі старіші за WSL. VPN‑инкапсуляція зменшує ефективний MTU, і PMTUD досі крихкий у реальних мережах.
• Пріоритети маршрутів за замовчуванням не універсальні. Метрики маршрутів Windows і налаштування «force tunnel» VPN часто дивують людей з Linux.
• Корпоративні політики безпеки часто блокують IP‑форвардинг. Навіть якщо Windows досягає VPN, він може відмовитися форвардити трафік із «віртуального» NIC.
• Доступ до localhost у WSL2 змінювався з часом. Останні збірки Windows покращили форвардинг localhost між Windows і WSL, але VPN все ще може заважати.

Режими відмов, зіставлені з кореневими причинами

Режим відмов A: «DNS у WSL зламаний, але Windows працює»

Найпоширеніший випадок. WSL автогенерує /etc/resolv.conf, вказуючи на резолвер на боці Windows.
Коли ви підключаєте VPN, DNS‑сервери Windows змінюються. WSL не завжди оновлюється коректно або оновлюється на резолвер, який не може дістатися корпоративного DNS через прив’язку інтерфейсу.

Режим відмов B: «Внутрішні IP‑адреси таймаутяться з WSL, але резольвляться правильно»

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

Режим відмов C: «Split tunnel: одна підмережа працює, інша — ні»

Split tunneling залежить від того, які внутрішні маршрути підхоплюються клієнтом. Деякі VPN‑клієнти встановлюють маршрути лише в Windows і припускають, що локальні процеси є єдиним джерелом.
Трафік WSL може виходити з іншої адресної підмережі (WSL NAT), і корпоративна сторона не матиме зворотного маршруту.

Режим відмов D: «HTTPS зависає, git clone висить, але ping працює»

MTU / фрагментація. Інаккапсуляція зменшує MTU; деякі ділянки мережі відкидають ICMP «fragmentation needed»; TCP потрапляє в чорну діру.
Це нудно, це давня проблема, і вона все ще щотижня підпалює команди.

Режим відмов E: «Усе працює до сну/резюму»

Повернення з сну часто змінює порядок інтерфейсів, метрики маршрутів або внутрішній стан VPN‑клієнта.
WSL продовжує працювати й тримає старі DNS або маршрути, поки Windows вже змінив стан.

Практичні завдання: команди, виводи та рішення (12+)

Ці завдання призначені для запуску у момент, коли щось ламається. Кожне дає конкретну інформацію
і підказує, що робити далі. Запускайте перевірки як на боці Windows, так і в WSL; дельта — це підказка.

Завдання 1 (WSL): Яка IP‑адреса і шлюз за замовчуванням?

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             172.26.112.45/20

cr0x@server:~$ ip route show
default via 172.26.112.1 dev eth0
172.26.112.0/20 dev eth0 proto kernel scope link src 172.26.112.45

Що це означає: WSL знаходиться в 172.26.112.0/20 і використовує 172.26.112.1 як шлюз (NAT Windows).
Рішення: Якщо шлюз відсутній або інтерфейс DOWN — мережа WSL вже зламана до входу VPN.
Перезапустіть WSL (wsl --shutdown з Windows) і перевірте знову.

Завдання 2 (WSL): Куди вказує DNS — адекватно?

cr0x@server:~$ cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.26.112.1

Що це означає: WSL використовує шлюз Windows як DNS‑проксі/резолвер.
Рішення: Якщо корпоративний DNS дає збій, це перший підозрюваний. Або резолвер Windows некоректний для стану VPN,
або WSL застряг зі старим DNS. Перейдіть до Завдання 3 і 4.

Завдання 3 (WSL): Чи резольвиться внутрішнє ім’я, і хто відповів?

cr0x@server:~$ resolvectl status 2>/dev/null | sed -n '1,120p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
Current DNS Server: 172.26.112.1
       DNS Servers: 172.26.112.1

Що це означає: Ваш резолвер — шлюз WSL. Це може працювати, але лише якщо Windows коректно форвардить запити.
Рішення: Якщо внутрішні домени не резольвляться, протестуйте прямі DNS‑запити до корпоративних серверів (Завдання 4),
щоб відділити «резолвер WSL» від «досяжності DNS».

Завдання 4 (WSL): Опитайте корпоративний DNS напряму (обхід проксі)

cr0x@server:~$ dig @10.20.30.40 git.internal.corp +time=2 +tries=1

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> @10.20.30.40 git.internal.corp +time=2 +tries=1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Що це означає: WSL не може напряму дістатися до корпоративного DNS‑сервера.
Рішення: Це маршрутизація/політика, а не проблема файлу резолвера. Йдіть до Завдання 6 (маршрути) і Завдання 10 (підказки щодо фаєрволу/політик).

Завдання 5 (Windows з WSL‑шела): Чи можна швидко порівняти з Windows DNS?

cr0x@server:~$ powershell.exe -NoProfile -Command "Resolve-DnsName git.internal.corp | Select-Object -First 1"
Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
git.internal.corp                              A      60    Answer     10.50.12.34

Що це означає: Windows може резольвити ім’я.
Рішення: Тепер ви знаєте: DNS працює у Windows, але WSL не може ним скористатися. Зазвичай виправлення — інтеграція DNS у WSL
(див. розділ виправлень: «закріпити resolv.conf» або «коректно налаштувати systemd-resolved»).

Завдання 6 (WSL): Який маршрут буде використано для внутрішнього IP?

cr0x@server:~$ ip route get 10.50.12.34
10.50.12.34 via 172.26.112.1 dev eth0 src 172.26.112.45 uid 1000

Що це означає: WSL відправить внутрішній трафік до шлюзу Windows. Це очікувано.
Рішення: Якщо Windows не форвардить його в VPN, ви маєте справу з маршрутизацією/політикою/фаєрволом Windows або VPN‑клієнтом, що блокує форвардинг з vNIC WSL.

Завдання 7 (WSL): Чи досяжний внутрішній IP взагалі?

cr0x@server:~$ ping -c 2 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 56(84) bytes of data.

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1027ms

Що це означає: Немає ICMP‑доступності. Не остаточно (ICMP може бути заблокований), але це сильний сигнал.
Рішення: Спробуйте TCP. Якщо TCP теж падає — це маршрутизація/політика. Якщо TCP працює, а ping — ні, це лише політика щодо ICMP.

Завдання 8 (WSL): Перевірте TCP на відомому внутрішньому порті

cr0x@server:~$ nc -vz -w 2 10.50.12.34 443
nc: connect to 10.50.12.34 port 443 (tcp) timed out: Operation now in progress

Що це означає: TCP не проходить.
Рішення: Підніміться рівнем вище: перевірте маршрути Windows і поведінку VPN‑адаптера. Якщо Windows може, а WSL — ні, підозрюйте обмеження VPN‑клієнта щодо форвардингу/NAT.

Завдання 9 (Windows через WSL): Що Windows думає про маршрути?

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetRoute -AddressFamily IPv4 | Sort-Object -Property RouteMetric | Select-Object -First 8"
ifIndex DestinationPrefix NextHop     RouteMetric ifMetric PolicyStore
------- ----------------- -------     ----------- -------- -----------
19      0.0.0.0/0         10.8.0.1    5           25       ActiveStore
3       0.0.0.0/0         192.168.1.1 35          25       ActiveStore
19      10.0.0.0/8        0.0.0.0     5           25       ActiveStore
19      172.16.0.0/12     0.0.0.0     5           25       ActiveStore
19      192.168.0.0/16    0.0.0.0     5           25       ActiveStore
1       127.0.0.0/8       0.0.0.0     256         75       ActiveStore

Що це означає: VPN (ifIndex 19) перемагає для маршруту за замовчуванням і внутрішніх RFC1918 діапазонів.
Рішення: У full tunnel це очікувано. У split tunnel це може бути некоректно і ламати локальний доступ.
У будь‑якому випадку, якщо WSL не може пройти через це, VPN‑клієнт може блокувати форвардинг або Windows‑фаєрвол фільтрує WSL vEthernet.

Завдання 10 (Windows через WSL): Чи ворожий профіль/фаєрвол vEthernet (WSL)?

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetAdapter -Name 'vEthernet (WSL)' | Format-List -Property Name,Status,MacAddress,LinkSpeed"
Name       : vEthernet (WSL)
Status     : Up
MacAddress : 00-15-5D-4A-2B-1C
LinkSpeed  : 10 Gbps

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetConnectionProfile -InterfaceAlias 'vEthernet (WSL)' | Format-List"
Name             : Network
InterfaceAlias   : vEthernet (WSL)
NetworkCategory  : Public
IPv4Connectivity : Internet

Що це означає: Віртуальний NIC WSL має категорію Public. Багато корпоративних фаєрволів жорстко обмежують Public‑профілі.
Рішення: Якщо політика дозволяє — змініть на Private. Якщо не дозволяє — додавайте вузькі правила фаєрволу замість широкого перемикання профілю.

Завдання 11 (WSL): Перевірте MTU і можливі чорні діри

cr0x@server:~$ ip link show dev eth0 | sed -n '1,3p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:4a:2b:1c brd ff:ff:ff:ff:ff:ff

cr0x@server:~$ ping -c 2 -M do -s 1472 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1500

cr0x@server:~$ ping -c 2 -M do -s 1360 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 1360(1388) bytes of data.

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1018ms

Що це означає: Перший ping показує логіку MTU інтерфейсу. Другий показує, що шлях все ще падає — отже проблема не лише в «занадто великих пакетах».
Рішення: Якщо менші пакети проходять, а більші зависають — зменшіть MTU (або MSS) на боці WSL або виправте PMTUD. Якщо обидва не працюють — поверніться до маршрутизації/політики.

Завдання 12 (WSL): Прослідкуйте, де пакети зникають (базово)

cr0x@server:~$ traceroute -n -w 1 -q 1 10.50.12.34
traceroute to 10.50.12.34 (10.50.12.34), 30 hops max, 60 byte packets
 1  172.26.112.1  0.240 ms
 2  * 
 3  * 
 4  *

Що це означає: Трафік доходить до шлюзу Windows, а потім зникає. Це межа.
Рішення: Припиніть крутити Linux‑маршрути. Потрібно налаштувати Windows+VPN так, щоб форвардити трафік коректно, або змінити налаштування VPN для підтримки WSL.

Завдання 13 (WSL): Чи очікується проксі (поширено в корпоративних VPN)?

cr0x@server:~$ env | grep -iE 'http_proxy|https_proxy|no_proxy'
https_proxy=http://proxy.internal.corp:8080
http_proxy=http://proxy.internal.corp:8080
no_proxy=localhost,127.0.0.1,.internal.corp

Що це означає: Середовище очікує HTTP‑проксі.
Рішення: Якщо прямий TCP до внутрішніх кінцівок падає, а доступ через проксі у Windows працює, вам потрібні узгоджені проксі‑змінні в WSL (або PAC‑рішення через Windows). Також переконайтесь, що no_proxy включає внутрішні домени, які не мають проксуватися.

Завдання 14 (WSL): Підтвердьте, що саме робить git

cr0x@server:~$ GIT_CURL_VERBOSE=1 GIT_TRACE=1 git ls-remote https://git.internal.corp/team/repo 2>&1 | sed -n '1,40p'
20:17:14.123456 git.c:460               trace: built-in: git ls-remote https://git.internal.corp/team/repo
20:17:14.130000 http.c:725              == Info:   Trying 10.50.12.34:443...
20:17:14.132000 http.c:725              == Info: connect to 10.50.12.34 port 443 failed: Connection timed out
fatal: unable to access 'https://git.internal.corp/team/repo/': Failed to connect to git.internal.corp port 443 after 2002 ms: Timeout was reached

Що це означає: Резольв пройшов; підключення таймаутиться.
Рішення: Не чіпайте DNS. Виправляйте маршрути/форвардинг/політику або використовуйте корпоративний проксі, якщо це потрібно.

Шаблони виправлень, що дійсно працюють

Існує десятки форумних «рішень» для WSL2+VPN. Половина — це cargo‑культ. Чверть — порушення політик безпеки.
Решта можуть бути надійними, якщо вибрати правильний шаблон для вашого середовища: full tunnel, split tunnel, proxy‑only або «VPN забороняє це».

Шаблон виправлення 1: Стабілізувати DNS у WSL (припинити гнатися за рухомою метою)

Якщо Windows резольвить внутрішні імена, а WSL — ні, зазвичай хочуть, щоб WSL використовував корпоративні DNS‑сервери напряму,
або використовував стабільний локальний форвардер, що реально слідує за станом VPN.

Опція A: Закріпити resolv.conf (просто, грубо, ефективно)

Вимкніть автогенерацію і вкажіть явні DNS‑сервери.
Це найкраще працює, коли IP корпоративних DNS‑серверів стабільні під час роботи в VPN.

cr0x@server:~$ sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[network]
generateResolvConf = false
EOF

cr0x@server:~$ sudo rm -f /etc/resolv.conf
cr0x@server:~$ sudo tee /etc/resolv.conf >/dev/null <<'EOF'
nameserver 10.20.30.40
nameserver 10.20.30.41
search internal.corp
options timeout:2 attempts:2
EOF

Що означає вивід: Відсутність виводу — нормально; ви пишете файли.
Рішення: Перезапустіть WSL (wsl --shutdown), щоб він перечитав конфігурацію. Якщо це виправляє внутрішнє резольвування, але ламає публічний DNS поза VPN,
вам потрібен умовний DNS або резолвер, що переключається разом із VPN.

Опція B: Використовувати systemd-resolved коректно (менш грубо, правильніше)

У новіших збірках WSL можна увімкнути systemd. Коли це працює, ви отримуєте справжній демона‑резолвер,
і можете спрямувати його на DNS‑сервери з кешуванням і коректною поведінкою відкату.
Але: треба, щоб Windows/VPN DNS‑історія була послідовною, інакше ви просто швидше впадете в помилки.

Якщо ви не використовуєте systemd у WSL, не вмикайте його тільки щоб «полагодити» VPN DNS, якщо не можете підтримувати зміну.
Це корисно, але додає ще одну рухому частину. Правило виробництва: додавайте складність лише коли вона приносить стабільність.

Шаблон виправлення 2: Реальність split tunnel (маршрути мають існувати в обидві сторони)

Split tunnel — місце, де помирає оптимізм. Ваш Windows‑комп’ютер отримує маршрути до 10.0.0.0/8 і подібних через VPN.
WSL відправляє пакети до шлюзу Windows. Windows форвардить у VPN. Чудово.
Потім корпоративна сторона отримує пакети з джерелом 172.26.112.45 (NAT‑діапазон WSL) і не знає, як відповісти.

У full tunnel це часто «випадково» працює, бо VPN‑клієнт робить NAT вихідного трафіку і ніби приховує його як трафік Windows‑хоста.
У split tunnel поведінка NAT варіюється. Деякі клієнти роблять NAT, деякі — ні, деякі — тільки для процесів Windows, а деякі відмовляються для «віртуальних адаптерів».

Ваші опції виправлення:

• Найкраще: VPN‑клієнт підтримує NAT/форвардинг для трафіку WSL (або це налаштовано).
• Також валідно: Корпоративна мережа має маршрути назад до WSL NAT‑підмережі (рідко; потребує згоди мережевої команди).
• Обхідний шлях: Використовуйте проксі/джамп‑хост/бастіон, до якого може дістатися Windows, і тунелюйте з WSL через цей дозволений шлях.

Шаблон виправлення 3: Зупиніть саботаж Windows‑фаєрволу щодо vEthernet (WSL)

Якщо WSL‑адаптер має профіль «Public» і корпоративний фаєрвол жорсткий, трафік WSL може бути заблокований від доступу до VPN‑адаптера.
Це поширено на захищених ноутбуках.

Якщо дозволено — встановіть профіль віртуального NIC у Private. Якщо не дозволено — додавайте вузькі правила фаєрволу, а не масові зміни профілів.
Команда безпеки віддасть перевагу «вузьким і аудитовим» змінам перед «я щось перемкнув, поки працювало».

Шаблон виправлення 4: Виправте MTU (або MSS), коли TCP зависає

Інкапсуляція VPN з’їдає MTU. Якщо у вас підкладка з MTU 1500, а VPN додає оверхед,
ефективний MTU шляху може бути близько 1400 або менше. Якщо PMTUD ламається (бо ICMP фільтрується десь),
великі TCP‑сегменти зникають і з’єднання зависають.

Практичне виправлення — зменшити MTU на інтерфейсі WSL або обмежити TCP MSS.
Ви віддаєте трохи швидкості заради стабільності. У корпоративних мережах стабільність має більшу цінність.

cr0x@server:~$ sudo ip link set dev eth0 mtu 1400
cr0x@server:~$ ip link show dev eth0 | sed -n '1,2p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:4a:2b:1c brd ff:ff:ff:ff:ff:ff

Що це означає: MTU тепер 1400.
Рішення: Перепробуйте завислий робочий процес (git clone, curl тощо). Якщо це вирішує проблему — зробіть налаштування постійним (через конфіг мережі дистрибутива)
і задокументуйте причину. Якщо нічого не змінює — відкотіть і продовжуйте діагностику.

Шаблон виправлення 5: Ставтеся до проксі як до першокласних громадян

Багато корпоративних VPN‑середовищ — це не «маршруй куди хочеш». Це «маршруй до проксі, потім через нього».
Якщо Windows має автоконфігурацію проксі, а WSL — ні, WSL зламається, навіть якщо ноутбук «працює».

У такому середовищі правильне виправлення — налаштувати проксі‑змінні в WSL узгоджено і підтримувати no_proxy.
Не хардкодьте це в довільних скриптах запуску шелу з таємничими умовами; використовуйте керований підхід (скрипти профілю),
а секрети тримайте в сховищах облікових даних, а не в .bashrc.

Жарт №2: Налагодження VPN‑мережі — як перегляд магічного шоу, тільки кролик — ваш пакет, і він ніколи не повертається.

Шаблон виправлення 6: Коли VPN‑клієнт забороняє WSL — припиніть боротися

Деякі VPN‑клієнти застосовують політику «ні трафіку з віртуальних адаптерів» або щось подібне. Іноді це явна політика, інколи — артефакт реалізації.
Якщо діагностика постійно показує, що пакети гинуть на шлюзі Windows, і відомо, що VPN‑клієнт блокує форвардинг,
у вас є три розумні опції:

• Використовувати WSL1 (якщо підходить для вашого навантаження), бо він ділить мережевий стек Windows і часто уникає NAT‑межі.
• Використовувати санкціоновану VM для розробки на VPN (керовану IT) або віддалений хост у внутрішній мережі.
• Використовувати SSH‑бастіон доступний з Windows і підключатися через нього з WSL (порт‑форвардинг); трактувати це як контрольований еґрес.

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

Принцип надійності, який варто пам’ятати

Надія — не стратегія. — Джеймс Кемерон

Застосуйте це тут: припиніть сподіватися, що таблиця маршрутів «виглядає нормально», і доведіть кожний шар тестами.

Поширені помилки: симптом → причина → виправлення

1) Симптом: «WSL не може резольвити внутрішні домени; Windows може»

Коренева причина: WSL /etc/resolv.conf вказує на резолвер, що не слідує за змінами DNS при підключенні VPN, або DNS Windows прив’язаний до інтерфейсу і шлях проксі WSL не враховує NRPT‑правила.

Виправлення: Закріпіть DNS у WSL (вимкніть generateResolvConf) на корпоративні DNS під час VPN або реалізуйте резолвер, який надійно слідує за станом VPN.

2) Симптом: «DNS резольвиться, але TCP до внутрішнього IP таймаутиться з WSL»

Коренева причина: VPN‑клієнт блокує форвардинг з WSL vEthernet адаптера, або Windows‑фаєрвол блокує його.

Виправлення: Перевірте категорію мережі адаптера WSL; додайте вузькі правила фаєрволу; якщо політика VPN забороняє — використовуйте WSL1 або санкціонований dev‑хост.

3) Симптом: «Split tunnel: деякі внутрішні підмережі працюють, інші — ні»

Коренева причина: Відсутні маршрути, перекриття локальних мереж або відсутній зворотний шлях для WSL NAT‑діапазону.

Виправлення: Перевірте маршрути Windows для кожного префіксу; уникайте локальних LAN‑діапазонів, що перекриваються з корпоративними RFC1918; пропишіть коректні маршрути в профілі VPN; забезпечте узгоджену NAT‑поведінку.

4) Симптом: «Після сну/резюму WSL втрачає зв’язок до перезапуску»

Коренева причина: Зміна метрик інтерфейсів або застарілий стан резолвера в WSL; VPN повторно підключається і змінює порядок DNS/маршрутів.

Виправлення: Автоматизуйте wsl --shutdown після перепідключення VPN (або принаймні задокументуйте). Віддавайте перевагу стабільній конфігурації DNS замість автогенерації.

5) Симптом: «HTTPS зависає; малі запити працюють; ping працює»

Коренева причина: MTU‑чорна діра через інкапсуляцію VPN і зламаний PMTUD.

Виправлення: Зменшіть MTU на інтерфейсі WSL (або обмежте MSS) і повторно протестуйте. Якщо це допомагає — зробіть налаштування постійним.

6) Симптом: «Локальні сервіси у Windows недоступні з WSL під VPN»

Коренева причина: VPN нав’язує маршрути або політики фаєрволу, які заважають локальній підмережі/форвардингу localhost; іноді VPN агресивно змінює правила фаєрволу.

Виправлення: Використовуйте явні IP‑адреси хоста, перевірте Windows‑фаєрвол, і подумайте про прив’язку сервісів до правильного інтерфейсу. Для розробки віддавайте перевагу підключенню через localhost, якщо підтримується, але перевіряйте після підключення VPN.

Чеклісти / покроковий план

Чекліст A: Потрібні внутрішні DNS + внутрішній TCP з WSL (full tunnel VPN)

1. Підтвердьте, що Windows може резольвити і підключатися до внутрішнього сервісу.
2. У WSL перевірте /etc/resolv.conf; протестуйте dig до корпоративного DNS напряму.
3. Якщо Windows працює, а WSL — ні, закріпіть DNS у WSL на корпоративні резолвери або виправте шлях DNS‑проксі.
4. Перевірте маршрути Windows: маршрут за замовчуванням і внутрішні префікси мають йти через VPN‑адаптер.
5. Перевірте профіль фаєрволу адаптера WSL; змініть на Private, якщо дозволено, або додайте вузькі правила.
6. Якщо TCP зависає дивно — тестуйте MTU і, за потреби, обмежте його.
7. Задокументуйте фінальний стан: DNS‑сервери, MTU і що ламається поза VPN.

Чекліст B: Потрібен split tunnel (локальний інтернет, корпоративні префікси через VPN)

1. Перелічіть точні внутрішні префікси, які вам потрібні (не вгадуйте; отримайте з профілю VPN або від мережевої команди).
2. На Windows підтвердьте, що ці префікси мають маршрути через VPN‑адаптер (підхід як у Завданні 9).
3. У WSL перевірте, що трафік до кожного префіксу йде до шлюзу Windows (Завдання 6) і не відхиляється.
4. Протестуйте досяжність внутрішніх IP для кожного префіксу (Завдання 8).
5. Якщо не працює — підозрюйте зворотний шлях/NAT: перевірте, чи очікує корпоративна сторона трафік лише від IP VPN‑хоста.
6. Прийміть рішення: (a) VPN‑клієнт підтримує форвардинг/NAT для WSL; (b) корпоративна мережа має маршрути назад до WSL NAT; або (c) використовуйте проксі/бастіон.
7. Стабілізуйте DNS: внутрішні домени мають резольвитися у внутрішні IP лише під час VPN; уникайте мішання публічних і приватних резолверів.

Чекліст C: Ви на зачиненому корпоративному ендпоінті

1. Припускайте, що не можете змінювати профіль фаєрволу, встановлювати драйвери або додавати маршрути постійно.
2. Доведіть, де пакети гинуть (Завдання 12 traceroute до внутрішнього IP).
3. Якщо падіння на шлюзі Windows, а Windows сам може дістатися цілі — швидше за все політика проти форвардингу з віртуальних адаптерів.
4. Перестаньте боротися зі своїм ноутбуком. Змініть стратегію: WSL1, віддалений dev‑хост або бастіон з порт‑форвардингом.
5. Отримайте документоване виняток, якщо WSL2 — бізнес‑потреба; «це незручно» — не аргумент для винятку.

Три корпоративні міні‑історії (аніонімізовано, правдоподібно та болісно знайоме)

Міні‑історія 1: Інцидент через неправильне припущення

Команда розгорнула новий внутрішній пакетний mirror під час міграції. Розробники використовували WSL2 для збірок.
Mirror знаходився у внутрішній підмережі, доступній лише через VPN.
Windows‑ноутбуки до нього діставалися. Команда припустила, що «розробники теж можуть дістатися», і на цьому завершили думку.

Перший понеділок після розгортання час збірки виріс катастрофічно. Не тому, що mirror був недоступний.
Бо WSL2 не діставався до нього, тож інструменти падали на публічні mirror‑сервери й ретраї. Деякі збірки повільно пройшли, деякі впали; усі звинувачували mirror.
На чергового дежурного впала тривога про «відмову реєстру», якої не було.

В режимі ретроспективи причина була очевидна: Windows мав маршрути VPN; трафік WSL помирав на межі хоста.
VPN‑клієнт застосував політику, що не дозволяла форвард з віртуальних адаптерів. Windows‑процеси були в порядку; WSL2 — ні.
Ніхто раніше не перевірив припущення, бо «в мене на машині працює» було правдою — просто не в тій самій мережевій підсистемі.

Виправлення не було хитрим маршрутом. Це було рішення: у цій політиці безпеки WSL2 не буде мати прямого доступу до VPN.
Вони випустили санкціонований образ Linux VM для збірок і залишили WSL2 для локальних сценаріїв. Це було менш зручно,
але припинило щотижневі розкопки «чому apt не працює».

Міні‑історія 2: Оптимізація, що відкотилась

Інша організація намагалася «прискорити VPN», впровадивши агресивний split tunneling. Інтернет трафік залишався локальним; лише внутрішні префікси ішли в VPN.
Це зменшило навантаження на концентратори і зробило відеодзвінки приємнішими. Усім сподобалося.

Потім інструменти розробки почали падати дивними способами. Контейнеризовані сервіси в WSL2 дісталися деяких внутрішніх сервісів, але не інших.
DNS іноді повертав внутрішні IP, іноді — публічні. Git по HTTPS інколи зависав.
Не було хаосу — був детермінізм.

Оптимізація внесла два точки зв’язку: повноту маршрутів і узгодженість DNS.
Їхні split tunnel маршрути не включали усі внутрішні залежності, особливо нові. DNS‑стратегія покладалася на NRPT Windows,
що WSL2 ігнорував, якщо використовував загальний шлях резолвера.
Результат: резолюція пройшла, але маршруту не було — з’єднання таймаутилось. Розробники «лікували» це hosts‑файлами.
Це працювало до наступного перенумерування.

Відкат був частковим. Команда зберегла split tunnel для більшості співробітників, але створила «розробницький» профіль VPN:
або full tunnel, або значно ширший набір префіксів плюс стабільний DNS. Менше елегантності, більше пропускної здатності, менше містичних відмов.
Також заборонили правки hosts для внутрішніх сервісів — не з фанатизму, а тому що це борг операційного обслуговування з гострими зубами.

Міні‑історія 3: Нудна, але правильна практика, що виручила

Платформ‑команда мала звичку, що нагадувала бюрократію: коли розробник повідомляв «VPN зламав WSL»,
перша реакція не була порадою — це був маленький чекліст виходів команд для вставлення у повідомлення.
WSL: ip route, cat /etc/resolv.conf, dig внутрішній домен.
Windows: фрагмент таблиці маршрутів і список DNS‑серверів. Та сама форма, кожного разу.

Люди скаржилися: «Навіщо стільки інформації? Це ж очевидно DNS.» Це не завжди було DNS.
Чекліст змусив припинити сперечатися з інтуїцією.
За місяць з’явилися закономірності: одна версія VPN‑клієнта ламала форвардинг; один апдейт драйвера Wi‑Fi змінював метрики; одне оновлення політики на ендпоінті перекваліфіковувало NIC WSL.

Коли стався реальний інцидент — внутрішній репозиторій недоступний з WSL у відділі — ті стандартні виводи прискорили триаж.
Вони могли сказати: Windows резольвить і підключається, WSL резольвить, але не підключається, traceroute помирає на шлюзі, а NIC WSL — Public.
Це звузило поле від «мережа впала» до «регресія політики на ендпоінті».

Остаточне виправлення було нудним: корекція політики, щоб дозволити конкретні вихідні потоки з адаптера WSL до VPN‑адаптера,
плюс задокументований обхід для MTU при певному ISP. Ніхто не писав про це блог‑пост.
Але наступного разу того, хто відповідав за інцидент, не турбували ночі.

FAQ

1) Чому WSL2 ламається під VPN, коли WSL1 працював?

WSL1 ділив мережевий стек Windows. WSL2 — VM за NAT‑межою. VPN‑клієнти і фаєрволи, що працюють із Windows‑стеком,
не завжди форвардять трафік для другого стеку автоматично.

2) Чи варто перейти на WSL1 тільки через сумісність з VPN?

Якщо ваші робочі навантаження терплять WSL1 (продуктивність файлової системи і можливості ядра можуть бути обмежені), це легітимне рішення.
Воно уникає NAT‑межі і часто поводиться як «звичайна Windows‑мережа».

3) Чи проблема завжди в DNS?

Ні. DNS — поширена причина, але багато відмов витікають із маршрутизації/політик: трафік доходить до шлюзу Windows і помирає, бо VPN‑клієнт блокує форвардинг
або профіль фаєрволу ворожий.

4) Чому все працює до повторного підключення VPN або виходу зі сну?

Повторне підключення VPN і повернення з сну можуть змінити порядок інтерфейсів, DNS‑сервери й метрики маршрутів.
WSL може зберігати стару конфігурацію резолвера, а Windows/VPN змінює стан під ним.

5) Як зрозуміти, чи це MTU?

Якщо імена резольвяться і малі запити проходять, але HTTPS‑завантаження, git‑clone або API‑виклики зависають чи стопоряться — підозрівайте MTU/PMTUD.
Тимчасово зменшіть MTU у WSL і повторно протестуйте.

6) Чи можна просто додати маршрути в WSL для виправлення split tunnel?

Зазвичай ні. Маршрути WSL і так йдуть через шлюз Windows. Якщо Windows/VPN не форвардить — Linux‑маршрути не змінять політику.
Сфокусуйтеся спочатку на Windows‑маршрутах і поведінці VPN.

7) Чому Windows дістається внутрішніх IP, а WSL — ні?

Процеси Windows виходять з Windows‑інтерфейсів і обробляються VPN‑клієнтом як очікується.
Трафік WSL походить із підмережі WSL vEthernet/NAT; деякі VPN‑клієнти трактують це як «форвардований трафік» і блокують його.

8) Яке найчистіше корпоративно‑дружнє рішення?

Санкціоноване середовище розробки всередині корпоративної мережі: керована VM, VDI або віддалений dev‑хост.
Якщо локальний WSL2 має використовуватися, погодьте документоване виняток і реалізуйте вузькі правила фаєрволу, а не широкі зміни профілів.

9) Чи вирішує увімкнення systemd у WSL проблеми з VPN?

Іноді це допомагає з DNS, бо з’являється справжній резолвер. Але це не зніме обмежень VPN‑політик чи правил фаєрволу.
Використовуйте systemd, коли можете підтримувати його операційно, а не як магічний засіб.

Практичні кроки

Зробіть три речі, у такому порядку:

1. Класифікуйте відмову: DNS чи маршрутизація/політика чи MTU. Використайте швидку діагностику та завдання вище.
2. Виберіть стабільний шаблон виправлення: закріпіть DNS, скоригуйте фаєрвол/профіль, обмежте MTU, прийміть проксі або змініть стратегію (WSL1/віддалений dev‑хост).
3. Зробіть це повторюваним: задокументуйте очікуваний стан (DNS‑сервери, режим VPN, MTU) і збережіть чекліст для наступного інциденту.

Мета не «запрацювати на вашому ноутбуку сьогодні». Мета — «зробити це нудним наступного місяця».
WSL2 — відмінний інструмент. VPN — необхідність. Змусити їх співпрацювати — це не кількість хитрих команд, а визнання, де саме проходить межа.