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, ведь учётные данные никогда не запрашивались.