SSTP не працює там, де HTTPS у браузері працює: чому
SSTP працює всередині TLS на порту 443, але це не веб-запит. Перевіряйте TCP, ідентичність TLS, обмін SSTP і автентифікацію PPP як окремі етапи.
Браузер відкриває ім'я вузла VPN через HTTPS без нарікань, а клієнт SSTP усе одно відмовляється підключатися. У цій парі немає нічого суперечливого. SSTP використовує TLS як зовнішній транспорт, а потім виконує свій запит і корисне навантаження PPP усередині цього з'єднання, тож успішне завантаження сторінки доводить лише одну вузьку річ: вузол відповідає на GET на порту 443. Клієнт ставить інше запитання, і сервер може відповісти на нього погано.
Сторінка завантажується, а тунель ні
Люди вдаються до тесту в браузері, бо він швидкий, а потім сприймають результат як доказ того, що сервер доступний і налаштований. Це доказ про GET до шляху, який відкрив рядок адреси, і не більше. Розмова VPN починається після того ж рукостискання TLS, але надсилає метод і шлях, які вебсторінка ніколи не використовує. Тому відповідь 200 для браузера нічого не говорить про те, чи існує кінцева точка SSTP.
Розділіть два спостереження, і пошук стане коротшим. Транспорт і ланцюжок сертифікатів працюють, а щось в обміні протоколу над ними — ні. Це інше розслідування, ніж зламаний порт або прострочений сертифікат, і воно потребує інших доказів.
Що насправді надсилає клієнт SSTP
Клієнт надсилає HTTP-запит методом SSTP_DUPLEX_POST на шлях /sra_{GUID}/, а потім тримає тіло з'єднання відкритим як двобічний потік, що несе кадри PPP. Відповідний сервер відповідає HTTP/1.1 200 і перестає поводитися як вебсервер. Усе інше — це підпис: 405 або 404 означає, що кінцевої точки немає, 301 або 302 означає, що щось перенаправляє запит, а негайний FIN означає, що проксі або сервер закрив потік.
Тому ціллю має бути сервер SSTP, а не вебсервер із прикрученим сертифікатом TLS. Метод, шлях і довготривале тіло — вимоги протоколу, тому зворотний проксі не може додати їх самою конфігурацією. Проксі, який бездоганно пересилає звичайний HTTPS, усе одно може відхилити невідомий йому метод.
Де проксі або вебсервер ламає потік
Посередник перевіряє рядок HTTP-запиту, перш ніж щось переслати, і нестандартний метод із незвичним шляхом може не пройти його правила. Деякі пристрої віддають звичайну сторінку, але відхиляють або переривають тунель, тому клієнт повідомляє про з'єднання, яке починається й потім помирає, а не про чисту відмову. Інші приймають запит, а потім застосовують тайм-аут тіла або простою, якого PPP-keepalive не переживають. Обидва виглядають однаково з боку клієнта, тому етап, що не пройшов, важливіший за текст помилки.
Спільне використання порту 443 вебсайтом і SSTP — це вибір маршрутизації, а не обіцянка, що кожен перехід обробить обидві розмови однаково. Якщо на шляху стоїть балансувальник навантаження, брандмауер або термінатор TLS, додайте його до списку підозрюваних, перш ніж торкатися конфігурації VPN.
Перевіряйте етапи окремо
Виконуйте перевірки по порядку й зупиняйтеся на першій невдачі, бо кожен етап виключає інший рівень. TLS-зонд нижче відокремлює ідентичність сертифіката від усього, що робить SSTP. Замініть ім'я вузла своєю кінцевою точкою і прочитайте subject і ланцюжок, які він друкує.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comПотім зіставте решту доказів з етапами, замість вгадувати з помилки клієнта. Таблиця нижче — це контрольний список для цитування в тікеті, з підписом, що відокремлює одну невдачу від наступної.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Запишіть у тікет останній успішний етап замість того, щоб писати "неможливо підключитися". Специфікація MS-SSTP документує запит і обмін PPP, що йдуть після рукостискання TLS, і є посиланням на те, чому тест у браузері не може замінити жодного з них.
Спочатку ідентичність, потім PPP
Ідентичність TLS та автентифікація PPP послідовні, а не альтернативні, і їх плутанина веде людей до неправильного налаштування сервера. Клієнт спершу перевіряє сертифікат сервера та його призначення, потім PPP узгоджує свій стан і автентифікує користувача методом виклик-відповідь або EAP. Проблема із сертифікатом дає іншу помилку, ніж відхилений пароль, і жодна з помилок не описує етап, який покриває інша.
Заміна імені вузла адресою або перехід через попередження про сертифікат прибирає перевірку, яка виявила б збійний етап, замість того щоб виправити його. Залиште попередження і прочитайте його. Не скидайте й пароль PPP, коли обмін HTTP так і не дійшов до поведінки SSTP, адже облікові дані ніколи не запитувалися.