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 и пересылка на стороне сервера всё ещё определяют, чего пользователь может достичь. Туннель — это путь, а не разрешение.