Як перевірити, що VPN у Windows насправді маршрутизує, у PowerShell
Підключена плитка VPN не доводить покриття. Прочитайте збережений прапорець профілю, актуальну таблицю маршрутів і правила NRPT у цьому порядку.
Я підключив клієнт VPN на ноутбуці з Windows 11, плитка перейшла в стан Connected, відкрилася внутрішня файлова папка, а публічний сайт досі завантажувався напряму через Wi-Fi офісу. Ця суміш виглядає як зламаний тунель. Насправді це звичайний результат профілю, який частину трафіку надсилає через VPN, а решту залишає на фізичному адаптері. Примусове тунелювання змінює те, якому маршруту за замовчуванням Windows надає перевагу; воно не видаляє конкретніші маршрути й не обіцяє, що трафік зупиниться після обриву з'єднання. Далі — порядок, якого я дотримуюся, коли клієнт заявляє про покриття: стан клієнта, збережений профіль, застосовані маршрути, розпізнавач і потім реальні потоки.
Почніть із клієнта, а потім перестаньте йому довіряти
Клієнт — правильне місце для початку лише тому, що він повідомляє, який профіль активний. Відкрийте властивості з'єднання й запишіть точну назву профілю, для кого він створений — для поточного користувача чи для всіх на машині, — і який адаптер з'являється в ncpa.cpl після підключення. На моєму тестовому ноутбуці адаптер носив назву профілю, і це робило вивід маршрутів зручним для читання. На інших машинах він відображається як запис WAN Miniport, і назва вам нічого не говорить.
Чого клієнт не може вам сказати — це покриття. Підключена плитка описує стан тунелю, а не перелік призначень. Сторонні клієнти також тримають власну конфігурацію, тому штатний профіль Windows і кожна його властивість, яку ви прочитаєте, можуть не мати нічого спільного з тим, що встановив цей клієнт. Якщо VPN прийшов через AnyConnect, OpenVPN GUI, WireGuard або агент постачальника, перевірки PowerShell нижче переважно не застосовуються, і замість них слід читати власні налаштування роздільного тунелю та маршрутизації цього клієнта.
Читайте збережений профіль, а не плитку
Для штатного профілю Windows (IKEv2, L2TP, SSTP або профілю, який просуває MDM) збережене рішення про роздільний тунель — це одна властивість:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixДодайте -AllUserConnection, коли профіль створено для всіх на пристрої. Без цього ви читаєте список поточного користувача, який може бути порожнім або містити інший запис із схожою назвою. Значення False у SplitTunneling означає, що профіль збережено як повний тунель: Windows встановлює маршрут за замовчуванням через адаптер VPN. True означає роздільний тунель, і покриття тоді повністю залежить від маршрутів і правил розв'язання імен, які просуває цей профіль.
Ставтеся до цього значення як до конфігурації, а не як до спостереження. Воно фіксує, що профіль запросив у момент підключення. Windows може залишитися з іншими застосованими маршрутами — через конкретніший маршрут іншого інтерфейсу, параметр політики або залишок від попереднього підключення, — тож логічне значення саме собою питання не вирішує.
Порівняйте збережене значення із застосованою таблицею маршрутів
Після підключення перелічіть маршрути на адаптері тунелю замість прокручування всієї таблиці:
$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1Find-NetRoute — корисна половина. Він відповідає на питання, на яке клієнт ніколи не відповідає: для цього призначення який інтерфейс і яка адреса джерела насправді будуть використані Windows? Запустіть його для внутрішнього вузла, публічного вузла й усього, що ви вважаєте навмисним винятком. Профіль повного тунелю має показати інтерфейс тунелю для публічної адреси. Профіль роздільного тунелю зазвичай показує там фізичний адаптер, тоді як внутрішні префікси все ще розв'язуються через VPN.
Дві пастки пояснюють більшість повідомлень «маршрутизує не туди». Найконкретніший префікс завжди перемагає, тому /24 на фізичному адаптері б'є маршрут за замовчуванням на VPN, хоч би якою низькою була метрика тунелю. Метрика лише вирішує рівність між маршрутами для одного префікса. А IPv4 і IPv6 вирішуються окремо: профіль, що покриває 0.0.0.0/0, може залишити IPv6 на локальному каналі, через що двокостковий сайт виглядає наполовину тунельованим. Перевірте Get-NetRoute -AddressFamily IPv6, перш ніж зробити висновок, що тунель гаразд.
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
Перевірте розв'язання імен окремо за допомогою NRPT
Внутрішні імена, які не працюють, тоді як внутрішні IP-адреси працюють, указують на політику розпізнавача, а не на маршрутизацію. Windows вирішує DNS для кожного простору імен через таблицю політики розв'язання імен, незалежну від таблиці маршрутів:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexКоли правило збігається з *.corp.example, запити для цього простору імен ідуть на DNS-сервери тунелю, навіть якщо шлях даних до цих серверів у режимі роздільного тунелю залишається на фізичному адаптері. Такий задум, і саме тому тест у браузері, що відкриває публічний сайт, нічого не каже про внутрішні імена. Якщо адаптер перелічує очікувані сервери, але пошук усе одно йде в інше місце, порівняйте порядок правил NRPT і перевірте, чи не збігається першим конкретніший простір імен.
Перевірте потоки, а потім вирішіть, що ви насправді просили
Пройдіть призначення у фіксованому порядку, щоб результати були порівнюваними між машинами: публічна адреса, внутрішня адреса, внутрішнє ім'я й один навмисний виняток, наприклад локальний принтер або відеовиклик. Запишіть інтерфейс і адресу джерела, які Find-NetRoute повертає для кожного. Після будь-якої зміни політики підключіться знову й повторіть ті самі чотири перевірки; таблиця маршрутів після повторного підключення — єдиний доказ, що новий профіль набув чинності.
Потім відокремте маршрутизацію від примусу. Примусове тунелювання надає перевагу тунелю для покритого трафіку, поки він піднятий. Це не kill switch. Якщо вимога полягає в тому, щоб нічого не залишало машину при падінні тунелю, це має походити з блокувального рішення: профіль брандмауера, прив'язаний до стану тунелю, постійно ввімкнений профіль із фільтрами трафіку або власна опція закриття при збої в клієнті постачальника. Примусове тунелювання також має залишати адресу самого VPN-сервера доступною поза тунелем, а блокування її в ім'я «примусити все» — надійний спосіб замкнутися ззовні з'єднання, яке ви намагаєтеся забезпечити.
Перш ніж щось змінювати, пройдіть цей список. Кожен невиконаний пункт звужує, де справжня проблема.
- Назву й обсяг профілю підтверджено, для профілів на рівні машини використано
-AllUserConnection. SplitTunnelingпрочитано й сприйнято як конфігурацію, а не як доказ покриття.- Маршрути адаптера тунелю перелічено окремо для IPv4 і IPv6.
Find-NetRouteзапущено для одного публічного, одного внутрішнього й одного виняткового призначення.- Правила NRPT перевірено, перш ніж звинувачувати маршрути у збої імені.
- Вимогу блокування перечитано: бажана маршрутизація — не те саме, що забезпечене блокування.
Рішення про повний чи роздільний тунель належить власнику профілю, а нотатки Microsoft про маршрутизацію описують поведінку, яку Windows реалізує, коли профіль її задає. Microsoft: примусове та роздільне тунелювання — джерело, яке я тримаю відкритим, читаючи вивід.