VPN підключено, але немає інтернету в Windows: контрольний список маршрутів і метрик

December 5, 2025 • February 3, 2026 • Читання: 7 хв • Views: 26

Було корисно?

VPN показує статус Connected. Іконка в трей виглядає задоволено. І все ж кожна вкладка браузера зависає, немов бере участь у тренуванні з аварійного відновлення.
Цей режим відмови поширений, повторюваний і зазвичай це не «інтернет відключився». Це маршрутизація, метрики і DNS у Windows, які роблять те, що ви (або ваш VPN‑клієнт) випадково їм наказали.

Це польовий посібник для людей, які керують продуктивними системами і зрідка мають погоджувати платіжку через Wi‑Fi готелю.
Ми розглянемо симптоми як інцидент: підтвердити, ізолювати, вирішити, виправити й запобігти повторенню.

Швидка схема діагностики

Коли вам пишуть «VPN підключено, але немає інтернету», не потрібна філософська бесіда про тунелювання. Потрібне дерево рішень, що завершується фіксом або ескалованою кореневою причиною. Ось швидкий шлях.

По‑перше: підтвердьте, що саме означає «немає інтернету»

Можна пропінгувати IP? Якщо ping 1.1.1.1 працює, але сайти не відкриваються, у вас проблема з DNS, а не з інтернетом.
Можна розв’язати DNS? Якщо nslookup не вдається або повертає внутрішні відповіді, це питання вибору DNS‑серверів, NRPT або пошуку DNS‑суфіксів.
Можна дістатися внутрішніх ресурсів? Якщо внутрішнє працює, а зовнішнє ні, ймовірно, у вас примусовий тунель / default route через VPN без виходу в інтернет.
Все відмовляє? Якщо і внутрішнє, і зовнішнє недоступні, підозрюйте вибір маршрутів, проблеми з метрикою інтерфейсу або блокування брандмауером/WFP.

По‑друге: перевірте default routes і метрики

Більшість інцидентів «підключено, але мертво» у Windows зводяться до: неправильний default route (0.0.0.0/0) переміг, або він переміг з метрикою, яка машині здалася «розумною», а людині — божевільною.

Перегляньте маршрути: route print або Get-NetRoute.
Визначте, який інтерфейс володіє default route і яку має метрику.
Розв’яжіть, чи потрібен вам full tunnel (весь трафік через VPN), чи split tunnel (лише корпоративні підмережі через VPN).

По‑третє: перевірте шлях DNS і політики

Які DNS‑сервери використовуються? Get-DnsClientServerAddress.
Чи NRPT направляє певні домени на VPN DNS? Get-DnsClientNrptPolicy.
Чи досяжний VPN DNS‑сервер через обраний маршрут? Якщо ні, розв’язування імен вмирає першим.

По‑четверте: доведіть шлях за допомогою tracert та прив’язки інтерфейсу

tracert -d 1.1.1.1 покаже, яким шлюзом ви реально користуєтеся.
Test-NetConnection скаже, чи це питання маршрутизації, DNS або фільтрації портів.

По‑п’яте: вирішіть, де робити фікс

Якщо ви користувач: можна підправити метрики, переключити опції split tunneling або виправити DNS. Якщо ви оператор VPN: треба відправити розумну конфігурацію, яка не викрадає default routes без надання egress і DNS.

Модель пам’яті: маршрути, метрики, DNS і «Connected»

«Connected» означає, що тунель піднятий, а не те, що інтернет досяжний

VPN‑клієнти повідомляють «connected», коли контрольна площина щаслива: автентифікація пройшла, інтерфейс тунелю існує, ключі обміняні, keepalive відповіли.
Це не дата‑план. Дата‑план — це те, куди ваші пакети йдуть жити або вмирати.

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

Windows обирає маршрут за довжиною префікса, потім за метрикою

Вибір маршруту переважно детермініований:

Довший префікс перемагає. /32 перемагає /24, /24 перемагає /0. Якщо ваш VPN встановлює конкретні маршрути для корпоративних мереж, вони повинні перемагати над локальним default route.
Потім перемагає метрика. Якщо два маршрути мають однакову довжину префікса, Windows використовує найменшу route metric і враховує interface metric.
А потім починаються приємності. Windows може врахувати «automatic metric», швидкість інтерфейсу, і інколи оновлення або перебіндування можуть непередбачувано змінити порядок.

Саме тому «інтернет помирає, коли VPN підключається» часто означає: новий маршрут 0.0.0.0/0 прийшов через VPN з нижчою метрикою, ніж ваш Wi‑Fi default route,
але VPN‑хендэнд не надає загального інтернет‑виходу (або навмисно блокує його). Результат: full‑tunnel без робочого виходу.

DNS — окрема площина відмов, і вона відгукується гучніше

Люди сприймають інтернет через імена, а не IP. Проблеми з DNS виглядають як «немає інтернету», навіть коли маршрути в порядку. Windows додає складності:

Кілька інтерфейсів можуть мати DNS‑сервери; Windows обирає на основі метрик інтерфейсів і політик суфіксів.
VPN‑клієнти можуть штовхати внутрішні DNS‑сервери і search suffixes.
NRPT (Name Resolution Policy Table) може примусово направляти певні домени (або всі домени) на конкретні DNS‑сервери.
DNS over HTTPS може обминати вашу VPN‑політику DNS і створити плутану поведінку split‑brain.

Split tunneling — це політичне рішення, а не трюк для налагодження

Люди вмикають/вимикають split tunneling, наче це «вимкни/увімкни». Іноді це допомагає, але це не магія. Це змінює таблицю маршрутів і модель загрози.
Якщо ваша політика безпеки вимагає full tunnel, то «виправлення» означає зробити full tunnel функціональним (включно з інтернет‑егресом або явними блокуваннями з повідомленням користувачу),
а не тихо вмикати split tunnel, бо так приємніше.

Жарт №1: маршрутизація VPN — як офісна політика: перемагає той, у кого найменша метрика, і ніхто не визнає, хто її поставив.

Факти та історія, які варто знати (бо Windows не винайшов хаос)

Спадок PPP і dial‑up досі має значення. Поведінка VPN у Windows успадкувала припущення від PPP‑лінків, де «віддалена мережа» часто означала «використовувати її як default gateway».
Дебати про split tunneling старі. Підприємства сперечалися про це десятиліттями щодо dial‑up і раннього IPSec: безпека хоче full tunnel; операції хочуть передбачуваний egress.
Automatic metric було зроблено щоб допомагати. Windows ввів автоматичні метрики інтерфейсів, щоб віддавати перевагу «швидшим» лінкам, але віртуальні адаптери можуть збити цей евристичний підхід.
NRPT походить з потреб DirectAccess‑ера. Microsoft створив спосіб розв’язувати корпоративні домени через корпоративні DNS, лишаючи публічні домени окремими — політично‑орієнтована маршрутизація DNS.
IPv6 не «зламав» VPN; часткове впровадження — так. Багато VPN тільки для IPv4, тоді як Windows віддає перевагу IPv6, якщо доступний; невідповідність створює дивні часткові з’єднання.
Пошук суфіксу DNS старіший за веб. Він розроблявся для корпоративного наймінгу і все ще відповідальний за багато інцидентів «чому це розв’язується неправильно?».
WFP зробив фільтрацію потужнішою. Windows Filtering Platform дозволяє VPN‑клієнтам і агентам кінцевих точок застосовувати мережеву політику; вона також може мовчки блокувати трафік.
NCSI — це не інтернет. Статус «No internet access» у Windows базується на перевірках і евристиках; ваші пакети можуть бути в порядку, а іконка скаржиться, або навпаки.

Практичні завдання: команди, що означає вивід і яке рішення прийняти

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

Завдання 1: Підтвердити інвентар інтерфейсів і статус

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object -Property Status,Name | Format-Table -Auto Name,Status,LinkSpeed,InterfaceDescription"
Name                      Status LinkSpeed  InterfaceDescription
Wi-Fi                     Up     866.7 Mbps Intel(R) Wi-Fi 6 AX201 160MHz
Ethernet                  Down   0 bps      Realtek PCIe GbE Family Controller
Wintun Userspace Tunnel   Up     1 Gbps     WireGuard Tunnel
TAP-Windows Adapter V9    Down   0 bps      TAP-Windows Adapter V9

Значення: У вас щонайменше два «Up» адаптери: Wi‑Fi і VPN‑тунель.
Це нормально. Важливо, який з них володіє default route і DNS.

Рішення: Якщо VPN‑адаптер Down, зупиніться тут: у вас проблема встановлення тунелю/автентифікації, а не «немає інтернету». Якщо він Up, продовжуйте до маршрутів.

Завдання 2: Показати таблицю маршрутів у зрозумілому вигляді

cr0x@server:~$ powershell -NoProfile -Command "route print"
===========================================================================
Interface List
 12...18 56 80 1a 2b 3c ......Intel(R) Wi-Fi 6 AX201 160MHz
 34...00 ff 12 34 56 78 ......Wintun Userspace Tunnel
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.8.0.1        10.8.0.2       5
          0.0.0.0          0.0.0.0   192.168.1.1    192.168.1.123    25
        10.8.0.0    255.255.255.0         On-link       10.8.0.2     261
     192.168.1.0    255.255.255.0         On-link   192.168.1.123    281
===========================================================================

Значення: Є два default routes. Default route від VPN має метрику 5, тому він перемагає. Це означає full tunnel.
Якщо VPN‑сервер не робить NAT/egress в інтернет, ваш інтернет фактично зник.

Рішення: Вирішіть політику: якщо потрібен full tunnel, перевірте, чи VPN‑шлюз надає інтернет‑вихід і дозволяє його. Якщо потрібен split tunnel, видаліть VPN default route і додайте лише корпоративні маршрути.

Завдання 3: Точно визначити переможний default route (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Sort-Object -Property RouteMetric,InterfaceMetric | Format-Table -Auto ifIndex,InterfaceAlias,NextHop,RouteMetric,InterfaceMetric,PolicyStore"
ifIndex InterfaceAlias           NextHop      RouteMetric InterfaceMetric PolicyStore
34      Wintun Userspace Tunnel  10.8.0.1              5             10 ActiveStore
12      Wi-Fi                    192.168.1.1          25             25 ActiveStore

Значення: VPN‑інтерфейс (ifIndex 34) — переважний default route.
InterfaceMetric теж важлива; Windows підсумовує/порівнює в способах, що все ще дивують людей.

Рішення: Якщо вам потрібен локальний інтернет під час підключеного VPN, або підніміть метрики VPN, вимкніть «use default gateway on remote network», або налаштуйте split tunneling правильно.

Завдання 4: Підтвердити фактичний egress IP до/після VPN

cr0x@server:~$ powershell -NoProfile -Command "curl.exe -s ifconfig.me; echo"
203.0.113.44

Значення: Це ваш публічний egress IP. Запустіть команду знову після підключення VPN. Якщо він зміниться на корпоративний діапазон — active full tunnel і egress працює.
Якщо команда зависає, маршрутизация відправляє трафік у тунель без виходу.

Рішення: Якщо команда зависає лише коли VPN підключено, зосередьтеся на default route і політиках egress/NAT VPN.

Завдання 5: Доведіть, чи проблема — DNS чи маршрутизація (ping IP vs name)

cr0x@server:~$ powershell -NoProfile -Command "ping -n 2 1.1.1.1"
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=17ms TTL=57
Reply from 1.1.1.1: bytes=32 time=16ms TTL=57

Ping statistics for 1.1.1.1:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),

cr0x@server:~$ powershell -NoProfile -Command "ping -n 2 www.microsoft.com"
Ping request could not find host www.microsoft.com. Please check the name and try again.

Значення: IP‑з’єднання є; розв’язування DNS не працює. Це не «немає інтернету», це «немає доступного резольвера» або «політика спрямовує DNS не туди».

Рішення: Тимчасово припиніть чіпати маршрути. Перевірте DNS‑сервери, NRPT‑правила і чи DNS‑запити виходять через очікуваний інтерфейс.

Завдання 6: Перевірити DNS‑сервери по інтерфейсу

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,ServerAddresses"
InterfaceAlias           ServerAddresses
Wi-Fi                    {192.168.1.1}
Wintun Userspace Tunnel  {10.8.0.53, 10.8.0.54}

Значення: Wi‑Fi використовує домашній роутер DNS. VPN штовхає внутрішні резольвери. Залежно від політики, Windows може віддавати перевагу VPN DNS для всього,
або застосовувати розумну мультихомінгову поведінку, яка не завжди така розумна.

Рішення: Якщо VPN DNS — внутрішній і ви в full‑tunnel без egress, публічні імена не працюватимуть. Або забезпечте egress, або налаштуйте DNS‑split (NRPT), щоб публічні імена йшли на публічні резольвери.

Завдання 7: Перевірити NRPT‑політики (маршрутизація DNS за доменом)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptPolicy | Select-Object -First 5 | Format-List"
NameSpace : .corp.example
NameServers : 10.8.0.53,10.8.0.54
DirectAccessDnsServers :
DnsSecValidationRequired : False
Comment : VPN policy

NameSpace : .
NameServers : 10.8.0.53

Значення: Якщо ви бачите правило для NameSpace : ., це означає «всі домени». Воно примусово направляє всі DNS‑запити до VPN‑резольвера.
Це може бути правильним для full tunnel; це катастрофа для split tunnel, якщо VPN DNS не розв’язує публічні домени або недосяжний.

Рішення: Якщо передбачений split tunnel, видаліть catch‑all NRPT‑правило і залиште лише корпоративні простори імен.

Завдання 8: Явно перевірити DNS‑розв’язування і який сервер відповідає

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName www.microsoft.com -Type A | Select-Object -First 3"
Name                                     Type TTL   Section IPAddress
----                                     ---- ---   ------- ---------
www.microsoft.com                        A    20    Answer  184.25.56.101

cr0x@server:~$ powershell -NoProfile -Command "nslookup www.microsoft.com 10.8.0.53"
Server:  vpn-dns-1
Address:  10.8.0.53

*** vpn-dns-1 can't find www.microsoft.com: Non-existent domain

Значення: Внутрішній DNS‑сервер не розв’язує публічні домени (за дизайном або помилкою). Якщо Windows віддає всі DNS‑запити йому, веб‑перегляд помирає.

Рішення: Або налаштуйте VPN DNS на форвардинг публічних запитів, або припиніть примусово спрямовувати публічні DNS через нього.

Завдання 9: Доведіть, яким шляхом ідуть ваші пакети (tracert без DNS)

cr0x@server:~$ powershell -NoProfile -Command "tracert -d 1.1.1.1"
Tracing route to 1.1.1.1 over a maximum of 30 hops

  1    35 ms    34 ms    36 ms  10.8.0.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.

Trace complete.

Значення: Хоп 1 — VPN‑шлюз, а далі нічого. Класичний випадок «default route через VPN, але VPN не пересилає в інтернет»
(або блокує ICMP далі за шлюзом, але зазвичай ви також побачите збої для TCP).

Рішення: Підтвердіть, чи VPN має надавати інтернет‑вихід. Якщо ні — видаліть default route і налаштуйте split tunnel.

Завдання 10: Перевірити TCP‑зв’язок до відомої кінцевої точки і зафіксувати, який інтерфейс використано

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 8.8.8.8 -Port 53 -InformationLevel Detailed"
ComputerName           : 8.8.8.8
RemoteAddress          : 8.8.8.8
RemotePort             : 53
InterfaceAlias         : Wintun Userspace Tunnel
SourceAddress          : 10.8.0.2
TcpTestSucceeded       : False
PingSucceeded          : True

Значення: ICMP пінг працює, але TCP/53 не встановлюється. Це може бути політика на VPN (блокування вихідних портів), проблеми з stateful фаєрволом або MTU/фрагментацією.

Рішення: Якщо інтерфейс — VPN‑тунель і вихідні порти заблоковані, потрібна зміна політики VPN (або split tunnel), а не маніпуляції на клієнті.

Завдання 11: Перевірити MTU на VPN‑інтерфейсі (тихий вбивця)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceAlias | Format-Table -Auto InterfaceAlias,NlMtu,InterfaceMetric,Dhcp"
InterfaceAlias           NlMtu InterfaceMetric Dhcp
Wi-Fi                    1500              25 Enabled
Wintun Userspace Tunnel  1420              10 Disabled

Значення: MTU 1420 звично для WireGuard; IPSec і деякі SSL VPN йдуть нижче. Якщо MTU неправильний, ви отримаєте «деякі сайти працюють, інші зависають»,
особливо HTTPS з більшими пакетами.

Рішення: Якщо симптоми часткові (малі пінги працюють; великі передачі зависають), тестуйте з меншою MTU або обмежте MSS на VPN‑шлюзі.

Завдання 12: Підтвердити IPv6‑маршрути і чи IPv6 «краде» трафік

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv6 -DestinationPrefix '::/0' | Format-Table -Auto InterfaceAlias,NextHop,RouteMetric,InterfaceMetric"
InterfaceAlias           NextHop              RouteMetric InterfaceMetric
Wi-Fi                    fe80::1                     10             25
Wintun Userspace Tunnel  ::                          256             10

Значення: IPv6 default route через Wi‑Fi існує і переважний. Якщо «немає інтернету» трапляється лише для деяких додатків, вони можуть пробувати IPv6 спочатку.
Тим часом VPN підтримує лише IPv4 і корпоративний DNS може повертати AAAA записи, що не проходять.

Рішення: Якщо корпоративний доступ ламається через те, що клієнти віддають перевагу IPv6, який не проходить через VPN, або надайте IPv6 через VPN, або контролюйте DNS‑відповіді / вимикайте IPv6 на дизайні тунелю (не як рефлекс).

Завдання 13: Перевірити параметри WinHTTP проксі (так, ще є)

cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp show proxy"
Current WinHTTP proxy settings:

    Proxy Server(s) : 10.8.0.20:8080
    Bypass List     : (none)

Значення: Деякі корпоративні post‑connect скрипти VPN ставлять проксі. Якщо цей проксі доступний лише через VPN, а маршрути VPN зламані, браузери можуть падати дивними способами.
Деякі додатки використовують WinHTTP; інші — WinINET; вони можуть не збігатися.

Рішення: Якщо інтернет мертвий лише для деяких додатків (або лише для системних служб), виправте доступність проксі або очистіть WinHTTP проксі, якщо він застарів.

Завдання 14: Перевірити налаштування Windows «use default gateway on remote network» (RAS/VPN)

cr0x@server:~$ powershell -NoProfile -Command "Get-VpnConnection -AllUserConnection | Select-Object Name,SplitTunneling,RememberCredential | Format-Table -Auto"
Name              SplitTunneling RememberCredential
----              -------------- ------------------
Corp-VPN          False          True

Значення: SplitTunneling False зазвичай означає full tunnel (default route через VPN). Це нормально, якщо ваш VPN для цього побудований.
Це катастрофа, якщо хендэнд «внутрішній лише».

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

Завдання 15: Налаштувати метрику інтерфейсу (важливо, але інколи необхідно)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetIPInterface -InterfaceAlias 'Wi-Fi' -InterfaceMetric 10; Set-NetIPInterface -InterfaceAlias 'Wintun Userspace Tunnel' -InterfaceMetric 50"

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Where-Object {$_.InterfaceAlias -in @('Wi-Fi','Wintun Userspace Tunnel')} | Format-Table -Auto InterfaceAlias,InterfaceMetric"
InterfaceAlias           InterfaceMetric
Wi-Fi                                10
Wintun Userspace Tunnel              50

Значення: Ви сказали Windows віддавати перевагу Wi‑Fi, коли маршрути конкурують.
Це грубий інструмент і може порушити політику full tunnel, якщо не обережно.

Рішення: Використовуйте метрики для вирішення конфліктів пріоритетів маршрутів, а не щоб «обійти безпеку». Якщо ваше підприємство вимагає full tunnel, не розповсюджуйте «метричні хаки» як підтримувальний хід.

Завдання 16: Додати конкретний маршрут для split tunneling (приклад для корпоративної підмережі)

cr0x@server:~$ powershell -NoProfile -Command "New-NetRoute -DestinationPrefix '10.20.0.0/16' -InterfaceAlias 'Wintun Userspace Tunnel' -NextHop '0.0.0.0' -RouteMetric 5"

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix '10.20.0.0/16' | Format-Table -Auto DestinationPrefix,InterfaceAlias,NextHop,RouteMetric"
DestinationPrefix InterfaceAlias           NextHop  RouteMetric
10.20.0.0/16       Wintun Userspace Tunnel  0.0.0.0          5

Значення: Ви явно направили лише корпоративну підмережу в тунель.
Для багатьох VPN‑технологій «on-link» next hop (0.0.0.0) коректний, бо сам інтерфейс тунелю — це шлях.

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

Завдання 17: Перевірити активні з’єднання і прив’язку адрес джерела

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Established | Select-Object -First 5 LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess | Format-Table -Auto"
LocalAddress    LocalPort RemoteAddress   RemotePort OwningProcess
10.8.0.2        50214     10.8.0.53       53         1240
192.168.1.123   50215     93.184.216.34   443        8916
192.168.1.123   50216     142.250.72.14   443        8916

Значення: Ви маєте одночасні з’єднання з джерелами як з VPN, так і з Wi‑Fi. Це нормально для split tunnel. Але це може ламає додатки, які очікують один стабільний source IP.

Рішення: Якщо конкретний додаток падає, поки інші працюють, він може чутливо ставитися до змін source IP. Прокладіть маршрути для цього додатка або застосуйте послідовну політику full tunnel.

Завдання 18: Перевірити профіль підключення Windows і чи VPN позначився як «Public» зі строгими правилами

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table -Auto Name,InterfaceAlias,NetworkCategory,IPv4Connectivity"
Name          InterfaceAlias           NetworkCategory IPv4Connectivity
HomeNetwork   Wi-Fi                    Private         Internet
Corp-VPN      Wintun Userspace Tunnel  Public          LocalNetwork

Значення: Профіль VPN позначений як Public і показує лише LocalNetwork відповідність. Деякі політики кінцевої точки застосовують суворіші правила для Public мереж,
а деякі VPN‑клієнти невірно позначають профіль.

Рішення: Якщо трафік блокується лише коли VPN підключено, а маршрути виглядають нормально, перевірте політики firewall/WFP і тегування профілю, замість того щоб хаотично змінювати маршрути.

Жарт №2: Таблиці маршрутів — єдине місце, де «нижче число перемагає» — це політика, яку ви можете застосувати без звернень у HR.

Одна цитата, яку варто тримати на столі

“Hope is not a strategy.” — James Cameron

Це болісно добре підходить до налагодження VPN: не сподівайтеся, що пакети пішли туди, куди ви хотіли; доведіть, куди вони пішли.

Типові помилки: симптом → корінь проблеми → виправлення

Цей розділ навмисно конкретний. Якщо вашого симптому тут немає, це або рідкісніша проблема, або інший шар (автентифікація, безпека кінцевої точки, ISP).

1) «VPN підключається, внутрішні сайти працюють, публічний інтернет помирає»

Корінь проблеми: Full tunnel default route встановлений через VPN, але егрегес/NAT інтернету на VPN‑шлюзі відключено або заблоковано.
Виправлення: Або (a) увімкнути egress на VPN‑шлюзі (NAT + політика фаєрволу + логування), або (b) видалити default route і використовувати split tunneling з явними корпоративними префіксами.

2) «Пінг публічного IP працює, сайти не завантажуються»

Корінь проблеми: DNS‑запити відправляються до недосяжного DNS‑сервера або до внутрішнього DNS, який не форвардить публічні домени.
Виправлення: Налаштуйте порядок DNS‑серверів, видаліть catch‑all NRPT, або налаштуйте внутрішній резольвер на форвардинг/розв’язування публічних доменів; переконайтеся, що існують маршрути до DNS‑серверів.

3) «Деякі сайти завантажуються, інші зависають назавжди (особливо HTTPS)»

Корінь проблеми: MTU/MSS проблеми через тунель (фрагментація заблокована, PMTUD чорна діра), або селективні блокування фаєрволом.
Виправлення: Зменшити MTU тунелю, обмежити MSS на VPN‑шлюзі, перевірити поведінку ICMP fragmentation‑needed, або відрегулювати політику фаєрволу для вихідних TCP.

4) «VPN працює по Wi‑Fi, але не по Ethernet (або навпаки)»

Корінь проблеми: Різниця метрик інтерфейсів призводить до різного вибору default route; корпоративна LAN використовує інші DHCP‑опції або проксі; політики VLAN відрізняються.
Виправлення: Порівняйте Get-NetRoute в різних умовах; при необхідності встановіть явні метрики; переконайтеся, що VPN‑маршрути не конфліктують із локальними підмережами.

5) «VPN каже підключено, але DNS повертає дивні внутрішні IP для публічних імен»

Корінь проблеми: Split‑brain DNS або внутрішнє підміщення DNS (навіть навмисне), інколи через NRPT «.» правило.
Виправлення: Обмежте NRPT до корпоративних просторів імен; переконайтеся, що внутрішній DNS не перекриває публічні зони, якщо це не заплановано (і якщо заплановано — майте план).

6) «Інтернет помирає лише для одного додатка (Teams, Outlook, браузер, пакетний менеджер)»

Корінь проблеми: Налаштування проксі (WinHTTP vs WinINET), додаток використовує IPv6 першим, або додаток прив’язаний до конкретного інтерфейсу і не любить змін source IP.
Виправлення: Перевірте netsh winhttp show proxy, перевірте IPv6‑маршрути і протестуйте через Test-NetConnection використовуючи потрібне ім’я/порт.

7) «VPN підключається, але ні до внутрішнього, ні до зовнішнього не дістатися; таблиця маршрутів виглядає нормально»

Корінь проблеми: WFP/фаєрвол блокує, антивірус або endpoint security заважає, або тунель піднятий, але дата‑план не працює (не ті ключі, невірні AllowedIPs, невірні SA‑селектори).
Виправлення: Перевірте через Test-NetConnection доступ до внутрішніх IP; перевірте профіль фаєрволу; для WireGuard перевірте AllowedIPs; для IPSec — трафік‑селектори.

8) «Після відключення VPN інтернет залишається зламаним до перезавантаження»

Корінь проблеми: Застарілі маршрути, застарілі DNS‑адреси або застарілі параметри проксі, що лишилися від VPN‑клієнта.
Виправлення: Видаліть персистентні маршрути, скиньте DNS до DHCP, очистіть WinHTTP проксі або перезапустіть мережевий стек (менш драматично, ніж повний перезавантаження).

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

Чекліст A: 5‑хвилинна «це маршрутизація чи DNS?» триаж

Запустіть ping 1.1.1.1. Якщо не вдається — ймовірно маршрути/фаєрвол.
Запустіть ping www.microsoft.com. Якщо IP‑ping працює, а ім’я — ні, зосередьтеся на DNS.
Запустіть route print і визначте переможний 0.0.0.0/0 маршрут.
Запустіть Get-DnsClientServerAddress і підтвердьте, що DNS‑сервери досяжні по обраному шляху.
Запустіть tracert -d 1.1.1.1, щоб побачити, чи трафік виходить через VPN‑шлюз чи локальний роутер.

Чекліст B: Санітарна перевірка full tunnel (для операторів і on‑call)

Якщо ваша організація вимагає full tunnel — прийміть це і зробіть так, щоб воно працювало. Напів‑full tunnel породжує інциденти.

Підтвердіть, що VPN штовхає default route з очікуваною метрикою.
Підтвердіть, що VPN‑шлюз надає інтернет‑егрес (NAT) і має правила фаєрволу, що дозволяють вихідний трафік за політикою.
Підтвердіть, що DNS‑сервери, передані через VPN, можуть розв’язувати як внутрішні зони, так і публічні домени (безпосередньо або через форвардинг).
Підтвердіть налаштування MTU/MSS для типу тунелю, щоб уникнути чорних дір пакетів.
Журналюйте відкидання egress на VPN‑шлюзі. Якщо ви не бачите відкидань, ви сперечатиметесь з примарами.
Перевірте позицію IPv6: або підтримуйте її наскрізь, або свідомо обмежуйте, щоб клієнти не обирали мертвий шлях.

Чекліст C: Санітарна перевірка split tunnel (для людей, що люблять передбачувані мережі)

Не штовхайте 0.0.0.0/0 через VPN. Штовхайте лише корпоративні префікси.
Уникайте накладання адресних просторів із домашніми мережами (колізії 192.168.0.0/16 реальні). Якщо неможливо уникнути — використайте NAT на клієнті або перерахуйте корпоративні підмережі.
Використовуйте NRPT лише для корпоративних просторів, а не для ., якщо ви не навмисне не змушуєте весь DNS через VPN.
Переконайтеся, що корпоративні DNS‑сервери досяжні через тунельні маршрути (очевидно, але часто ігнорують).
Будьте послідовні в політиці проксі: або проксі через VPN для внутрішніх додатків, або ні. Змішані сигнали викликають змішані відмови.
Документуйте, який трафік має проходити через VPN (source control, CI/CD, внутрішні репозиторії артефактів) і додайте ці префікси/маршрути явно.

Чекліст D: Дії на стороні клієнта, щоб вийти з глухого кута без порушення політики

Відключіть і підключіть VPN раз (так, раз). Якщо таблиця маршрутів змінюється щоразу по‑іншому — це баг, який треба репортнути.
Очистіть кеш DNS (ipconfig /flushdns) після змін DNS‑політики.
Оновіть DHCP на фізичному інтерфейсі (ipconfig /renew), якщо локальна маршрутизація виглядає неправильно.
Перевірте й очистіть застарілий WinHTTP проксі, якщо він явно неправильний (netsh winhttp reset proxy) — але лише якщо ваша середа цього не потребує.
Зберіть докази перед ескалацією: таблицю маршрутів, DNS‑сервери, NRPT‑політики і кілька невдалих тестів з мітками часу.

Корисний набір команд «пакета доказів» (копіювати/вставити для ескалацій)

cr0x@server:~$ powershell -NoProfile -Command "Get-Date; hostname; Get-NetAdapter | ? Status -eq 'Up' | ft -Auto Name,ifIndex,LinkSpeed; Get-NetRoute -DestinationPrefix '0.0.0.0/0' | ft -Auto; Get-DnsClientServerAddress -AddressFamily IPv4 | ft -Auto; Get-DnsClientNrptPolicy | ft -Auto NameSpace,NameServers; Test-NetConnection 1.1.1.1 -InformationLevel Detailed; Resolve-DnsName www.microsoft.com -ErrorAction SilentlyContinue"

Значення: Це фіксує час, хостнейм, активні інтерфейси, default routes, конфігурацію DNS, NRPT, базову перевірку з’єднання і спробу розв’язування DNS.
Це різниця між ескалацією та криком про допомогу.

Рішення: Якщо не можете виправити локально, відправте цей пакет команд команді VPN/мережі. Вони все одно зададуть ще одне питання, але принаймні не спитають «яка у вас таблиця маршрутів?».

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

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

Середня компанія розгорнула новий VPN‑профіль для підрядників. Ідея була проста: підрядники повинні мати доступ лише до кількох внутрішніх веб‑додатків.
Концентратор VPN налаштований лише для внутрішньої маршрутизації — без інтернет‑егресу, без NAT, суворі вихідні ACL. Безпека підписала. Усім здавалося, що відповідальність розподілена.

Неправильне припущення проявилося як лавина звернень у helpdesk: «VPN підключено, але немає інтернету». Helpdesk думав, що це проблема ISP, бо це починалося в один і той же час щоранку.
Насправді це починалося, коли люди відкривали ноутбуки, підключали VPN і намагалися пройти MFA на публічних доменах.
Їхні браузери не могли розв’язати або дістатися зовнішніх endpoint‑ів ідентифікації, бо VPN штовхав default route.

Команда VPN наполягала, що вони ніколи не мали наміру тунелювати інтернет. Команда кінцевих точок наполягала, що вони ніколи не планували міняти default routes. Обидві були праві, але обидві пропустили третю ланку: шаблон профілю, який вони клонували, мав за замовчуванням «send all traffic», бо походив з старого full‑tunnel розгортання.

Виправлення не було героїчним. Вони видалили default route з профілю підрядників, штовхнули явні корпоративні префікси для двох додатків і додали NRPT‑правило лише для корпоративного домену. Наступного дня черга в helpdesk затихла. Потім хтось запитав, чому це зайняло три дні. Відповідь була болісно проста: «бо ніхто не глянув route print».

Міні‑історія 2: Оптимізація, що відбилася бумерангом

IT‑команда хотіла швидший VPN, тож вони налаштували метрики інтерфейсів, щоб агресивно віддавати перевагу VPN‑адаптеру. Нижча метрика — вищий пріоритет, менше неоднозначності.
В лабораторії і на корпоративному Wi‑Fi це працювало. Графіки стали кращими. Вони розгорнули зміну.

Потім віддалені працівники на нестабільних домашніх мережах почали скаржитися на періодичні «підключено, але немає інтернету» і «деякі сайти зависають». VPN‑адаптер тепер вигравав маршрути навіть коли тунель був підключений, але деградований. Тим часом Wi‑Fi мав здоровий default route, який міг би нести публічний трафік під час падінь тунелю.
Але метрики були «оптимізовані», щоб прибрати цей fallback.

Найнеприємніше: контрольна площина тунелю була стабільною достатньо, щоб показувати «Connected», а дата‑план страждав від MTU‑чорних дір і втрат пакетів.
Отже користувачі тримали VPN увімкненим і звинувачували «інтернет». Насправді їхня маршрутизація була зафіксована в поганому шляху без плавного fallback.

Відкат відразу покращив ситуацію. Довгострокове рішення було більш дорослим: зберігати full tunnel для керованих пристроїв, що його потребують, але додати health checks і краще налаштування MTU; для split‑tunnel популяцій уникати примусових default routes через метричні хаки. Оптимізація метрики дала локальну вигоду, що перетворилася на глобальний інцидент.

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

Фінансова компанія мала VPN‑середовище, яке всі називали «старим», що у корпоративній мові означає «стабільним, але немодним». Їхній секрет не в магічному обладнанні.
Це операційна дисципліна: кожна зміна VPN‑профілю вимагала фіксації before/after маршрутів, DNS‑серверів, NRPT‑правил і скриптованого набору тестів з чистої Windows VM.

Одного вівторка ротація сертифікатів збіглася з оновленням клієнта. Користувачі почали повідомляти про проблеми з переглядом після підключення VPN. Шлюзи VPN виглядали нормально.
Автентифікація була в порядку. Тунель піднятий. Класична пастка.

Завдяки нудній практиці, інженер на чергуванні порівняв пакети доказів до/після і помітив, що нове оновлення клієнта додало NRPT catch‑all правило для ., що змушувало весь DNS йти до внутрішніх резольверів. Внутрішні резольвери були досяжні, але вони були налаштовані не форвардити публічні домени — знову ж таки, за політикою.

Вони не «пробували випадково». Вони видалили catch‑all правило в профілі, залишили NRPT для внутрішніх просторів і штовхнули виправлену конфігурацію.
Інцидент швидко локалізували. Ніхто не писав героїчний пост. Ось у чому суть: нудні практики запобігають захопливим аваріям.

FAQ

1) Чому Windows показує «Connected», якщо я не можу відкрити сайти?

Бо контрольна площина VPN підключена. Ваші маршрути і налаштування DNS можуть бути неправильними, і Windows не назвуть це «disconnected».
Думайте про це як «тунель встановлено», а не «пакети доставлено».

2) Яка найпоширеніша причина «VPN підключено, але немає інтернету»?

Default route (0.0.0.0/0) відданий на VPN, коли VPN‑шлюз не забезпечує інтернет‑егрес (або блокує його).
Це конфлікт маршрутизації й політики, а не містика.

3) Як визначити, де DNS чи маршрутизація?

Пропінгуйте IP (наприклад, 1.1.1.1) і потім ім’я (наприклад, www.microsoft.com). Якщо IP працює, а ім’я ні — це DNS.
Якщо обидва не працюють — це маршрутизація/фаєрвол або дата‑план тунелю.

4) Чи варто просто ввімкнути split tunneling, щоб виправити?

Тільки якщо політика безпеки дозволяє і ваш VPN призначений для split tunneling. Інакше ви «виправляєте» змінюючи політику.
Правильне виправлення для full tunnel — зробити full tunnel функціональним: egress, форвардинг DNS, MTU‑тонування і чітка політика фаєрволу.

5) Чому у мене два default routes і чому це має значення?

Може бути кілька default routes (Wi‑Fi і VPN). Windows обирає за метриками. Менше число перемагає, і ваш трафік іде за ним.
Якщо переможець — тупик, ваш інтернет піде туди в прірву.

6) Що таке NRPT і чому воно ламає перегляд?

NRPT — це політика Windows для DNS‑маршрутизації за доменом. Якщо правило змушує всі домени йти до VPN DNS (правило для .),
і цей DNS не може розв’язувати публічні домени або недосяжний, перегляд вебу падає, навіть якщо маршрути IP в порядку.

7) Чому після відключення VPN інтернет іноді не відновлюється?

Деякі VPN‑клієнти залишають застарілі маршрути, DNS‑налаштування або проксі. Windows буде використовувати їх, поки їх не видалять або не перезапишуть.
Перевірте персистентні маршрути і списки DNS‑серверів, і скиньте застарілі проксі, якщо потрібно.

8) Чи може IPv6 бути причиною?

Так. Windows віддає перевагу IPv6, якщо може. Якщо ваш VPN не несе IPv6, але DNS повертає AAAA записи для внутрішніх або зовнішніх сервісів,
деякі додатки спробують IPv6 спочатку і виглядатимуть зламаними. Перевірте IPv6 default routes і чи підтримує дизайн VPN IPv6 навмисно.

9) Чи добре змінювати метрику інтерфейсу як довгострокове рішення?

Це інструмент, а не стратегія. Метрики можуть вирішити tie‑break маршруту, але використовувати їх щоб переграти невдалий VPN‑профіль створює дрейф між машинами.
Краще виправити штовхувані маршрути і політику DNS централізовано.

10) Які докази надсилати команді VPN?

Default routes і метрики, DNS‑сервери, NRPT‑політики і кілька невдалих тестів (Test-NetConnection і Resolve-DnsName).
Додавайте мітки часу і вказуйте, чи проблема відбувається тільки в певних мережах (домашній Wi‑Fi, tethering, готель).

Висновок: кроки, що запобігають повторенню

«Підключено, але немає інтернету» рідко буває випадковим. Зазвичай це одна з трьох речей: неправильний default route переміг, DNS примусово направлений у непридатне місце, або тунель підключений, але дата‑план зламаний
(часто MTU/фаєрвол). Ви не виправите це методом здогадок. Ви виправляєте це, читаючи таблицю маршрутів, як лог‑файл.

Практичні наступні кроки:

Пройдіть 5‑хвилинний триаж: IP ping vs name ping, потім визначте власника default route.
Прийміть рішення full tunnel vs split tunnel і узгодьте маршрути + DNS‑політику з цим рішенням.
Якщо ви керуєте VPN: не штовхайте профілі, які ставлять default route без забезпечення egress і DNS, що розв’язує те, що користувачі потребують.
Стандартизуйте набір команд «пакета доказів» і вимагайте його при ескалаціях. Не тому, що ви злий — тому що це скорочує час відновлення.

Перемога — це не просто повернути один ноутбук в онлайн. Це зробити наступний інцидент настільки нудним, щоб ніхто не пам’ятав, що він взагалі був.