SSTP за проксі, що перевіряє TLS: де обривається сеанс

Ваш браузер відкриває корпоративний інтранет, сертифікат проксі вважається довіреним, і все ж клієнт SSTP обривається ближче до кінця з’єднання. Ця картина вказує на різницю між веб-запитом і сеансом у тунелі, а не на неправильний пароль. Пройдіть з’єднання від TCP вгору й позначте перший етап, який не проходить. Саме етап, а не код помилки, каже, чи винне проксі.

Почніть там, де зупиняється клієнт

Клієнт проходить фіксовану послідовність: TCP-з’єднання з портом 443, рукостискання TLS, перевірка сертифіката, HTTP-обмін SSTP, узгодження й автентифікація PPP, потім налаштування IP. Збій на кожному етапі залишає інший слід, і їхнє змішування веде на неправильну сторінку налаштувань.

Збій TCP — це тайм-аут або скидання до появи бодай одного байта TLS. Збій TLS — це попередження або тайм-аут рукостискання. Збій сертифіката дає попередження про ланцюжок або ім’я. Збій HTTP настає після успішного рукостискання, часто як код стану або негайне закриття. Збій PPP настає після того, як тунель технічно встановлено, тому він виглядає як проблема автентифікації.

Читайте журнал клієнта в пошуку останнього успішного етапу, а не першого рядка помилки. Рядок помилки зазвичай повідомляє наслідок, тоді як межа етапу називає компонент, який відмовив.

Що SSTP вимагає від мережі нести

SSTP працює поверх TLS на TCP 443 і потім надсилає HTTP-запит SSTP_DUPLEX_POST, визначений у специфікації SSTP, на шлях вигляду /sra_{GUID}/. Запит оголошує практично необмежену довжину вмісту й тримає потік відкритим в обидва боки протягом усього сеансу. Кадри PPP подорожують усередині цього потоку.

Тому проксі, яке обслуговує звичайний перегляд, усе одно може зазнати збою. GET або POST із скінченним тілом можна буферизувати, перевірити й передати; дуплексний потік із тілом, яке ніколи не закінчується, — ні. Проксі, яке чекає завершення тіла, чекає вічно, і клієнт зрештою отримує тайм-аут.

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

Чому перевірка змінює ідентичність

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

Успішна перевірка не означає, що проксі здатне нести сеанс. Йому все ще треба передавати необмежений двосторонній POST без буферизації й тримати обидва з’єднання живими годинами. Багато продуктів перевірки створені для трафіку запит-відповідь і справляються з цим випадком погано або ніяк.

Тому додавання невідомого кореня або вимкнення перевірки — неправильне лікування. Це змінює те, який сертифікат приймає клієнт; на обробку потоку, яка насправді зламала сеанс, це не впливає.

Визначте видавця до зміни налаштувань

Запитайте в кінцевої точки, який сертифікат вона подає і хто його підписав. Команди нижче показують ланцюжок і видавця, не запускаючи сеанс VPN:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

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

Тест браузера до того ж хоста доводить лише те, що проксі приймає GET. Він нічого не каже про метод SSTP, URI запиту або час життя тіла, тож не вважайте робочу сторінку інтранету доказом підтримки шляху тунелю.

Виберіть підтримуваний шлях

Поставте власнику мережі одне конкретне питання: чи дозволяє проксі небуферизований дуплексний POST до цього шлюзу на порту 443? «Так» веде до винятку в проксі або документованого обходу для хоста VPN. «Ні» означає, що перевірений шлях не може нести SSTP, і підтримуване виправлення — інший шлях або протокол, а не доопрацювання клієнта.

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

Задокументуйте результат: видавець, збійний етап, правило проксі та обраний шлях. Наступна людина, яка побачить ту саму зупинку на 98 відсотках, зможе перевірити один факт замість повторення всього проходу.