Вбудований VPN Windows не доходить до SSL-шлюзу постачальника: чому

Windows має чотири типи тунелів, і шлюзу SSL постачальника серед них немає. Усе одно спрямуйте вбудований профіль на такий шлюз, і з’єднання обірветься ще до запиту облікових даних, зазвичай із повідомленням про те, що з’єднання розірвано локальною системою. Цей текст — ознака незбігу, а не діагноз. Тип профілю й клієнт, що володіє протоколом, мають збігатися, а одного з них бракує.

Чотири типи й одне вікно

Кожен збережений профіль має тип тунелю. Вбудований клієнт приймає PPTP, L2TP, IKEv2 і SSTP, а також автоматичний режим, який пробує їх по черзі. Загального запису SSL VPN немає, і додати його через діалог неможливо. Шлюз постачальника говорить власним прикладним протоколом поверх TLS, який реалізує лише клієнт цього постачальника.

Список за одну команду, і його варто виконати перед будь-яким іншим розбором, бо він займає секунду й прибирає цілий клас хибних припущень:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

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

SSTP і TLS постачальника виглядають однаково на порту 443

SSTP загортає сеанс PPP у TLS і йде через TCP 443. У стеку Microsoft його завершує RRAS, який пред’являє сертифікат сервера, що його перевіряє клієнт. Пристрій Fortinet, Citrix або Pulse теж завершує TLS на 443, і його портал відкривається в будь-якому браузері без скарг.

Ця перевірка в браузері доводить доступність, а не сумісність. Протокол сеансу за порталом належить постачальнику, і вбудований клієнт не має його реалізації. Чи постачає постачальник власний клієнт — це підказує, з якою половиною незбігу ви маєте справу.

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

Помилки, що з’являються до створення тунелю

Коди серії 800 повідомляються до встановлення будь-якого тунелю, тому правила брандмауера рідко їх зсувають. Помилка 812 — це серверна політика, що відхиляє запропонований клієнтом метод автентифікації. Інші в цьому діапазоні походять від локального диспетчера підключень, а не від мережі.

Увімкніть трасування, перш ніж щось перебудовувати. Трасування називає етап, що зазнає невдачі, а назва етапу цінніша за текст у діалозі:

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

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

Підключений профіль усе одно може все зламати

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

Це вирішують два налаштування. Одне — властивість split tunneling у профілі. Друге — опція для кожного адаптера використовувати шлюз за замовчуванням у віддаленій мережі, що міститься в додаткових параметрах IPv4.

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

Увімкнення split tunneling без додавання маршрутів дає тунель, який підключається і нічого не досягає. Вимкнення без перевірки DNS дає внутрішні імена, що розв’язуються в публічні відповіді, бо власний суфікс і сервери адаптера не використовуються.

Перевірте обв’язку, потім тип

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

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

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

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