SSTP — це PPP поверх HTTPS, а не вебсторінка на порту 443

SSTP передає PPP усередині з'єднання HTTPS, тому для всього посередині воно виглядає як вебтрафік. TLS і HTTP створюють зовнішній канал, далі керівні повідомлення SSTP готують тунель, а PPP забезпечує поведінку сеансу. Браузер, який завантажує сторінку за тією самою адресою завершив лише частину першого етапу. Вважати це перевіркою VPN — це спосіб звинуватити робочий проксі в невідповідності протоколу.

Пройдіть чотири етапи по порядку, і збій, який ви бачите, потрапить до одного з них.

Етап 1: TCP і TLS

Клієнт відкриває TCP-з'єднання до порту 443 і виконує рукостискання TLS. Ланцюжок сертифікатів має відповідати імені хоста, з яким було налаштовано клієнт. Невідповідність імені тут дає збій ще до обміну будь-яким повідомленням SSTP, а специфікація SSTP припускає, що цей зовнішній канал HTTPS уже існує. Ніщо на пізніших етапах не компенсує збій довіри тут.

Звичайний вебсервер може бездоганно пройти цей етап і все одно зазнати невдачі на наступному. Успіх TLS — це доказ про сертифікат, а не про протокол за ним.

Етап 2: запит HTTPS

SSTP надсилає свій запит особливим методом SSTP_DUPLEX_POST і тримає обмін відкритим замість повернення документа. Сервер або проксі, налаштовані на звичайні запити сторінок, можуть прийняти з'єднання, а потім відхилити метод. Саме це відхилення люди зазвичай описують як блокування порту 443.

Прочитайте код відповіді та метод у журналі сервера. Відхилення на цьому етапі — інша проблема, ніж тайм-аут TCP, і обидві ведуть до різних виправлень.

Етап 3: керівні повідомлення

Після прийняття запиту SSTP обмінюється керівними повідомленнями, які узгоджують і готують тунель. Це протокольні повідомлення всередині тіла HTTPS, а не запити HTTP, тож проксі, який перевіряє й переписує тіла, може їх зламати, залишивши запити сторінок недоторканими.

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

Етап 4: PPP бере керування

Далі PPP забезпечує поведінку сеансу: узгодження з'єднання, автентифікацію та наступне налаштування мережевого рівня. Автентифікація PPP відокремлена від перевірки TLS, яку клієнт уже пройшов. Сертифікат сервера, який клієнт приймає, нічого не каже про те, чи чинні облікові дані користувача і чи авторизовано обліковий запис.

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

Автентифікація має кілька ролей

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

Запишіть, який етап повідомив про збій. Сертифікат, метод, керівне повідомлення, автентифікація PPP, далі маршрути: п'ять місць, п'ять виправлень.

Що перевірка в браузері може і чого не може показати

Завантаження сторінки за адресою доводить розв'язання DNS, доступність TCP і те, що щось слухає та говорить HTTP. Воно не доводить, що метод приймається, обмін керівними повідомленнями виживає або автентифікація PPP налаштована. Використовуйте клієнт, який реалізує SSTP, замість перетворення іншого профілю зміною порту.

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