Вградената VPN в Windows не достига до SSL шлюз на доставчик: защо

Windows се доставя с четири типа тунели, а шлюзът на доставчика не е един от тях. Насочете вграден профил към такъв и връзката се проваля още преди подканата за идентификационни данни, обикновено със съобщение, че връзката е прекратена от локалната система. Този текст е сигнал за несъответствие, а не диагноза. Типът на профила и клиентът, който притежава протокола, трябва да съвпадат, а един от тях липсва.

Четири типа и един диалог

Всеки запазен профил носи тип тунел. Вграденият клиент приема 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

Проследяванията попадат в директорията за проследяване и остават там, докато не ги изчистите, затова го изключете след това, вместо да го оставите да работи със седмици.

Свързан профил все още може да разбие всичко

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

Това се решава от две настройки. Едната е свойството за разделен тунел в профила. Другата е опцията за всеки адаптер да използва шлюза по подразбиране в отдалечената мрежа, която се намира в разширените настройки на IPv4.

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

Включването на разделен тунел без добавяне на маршрути дава тунел, който се свързва и не достига до нищо. Изключването му без проверка на 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 не работи”.