Порт 443 отвечает, а SSTP всё равно не работает: какой этап сломался?

Завершение TCP-рукопожатия с портом 443 при том, что туннель так и не строится, доказывает одну вещь, и это мелочь. Что-то слушает и готово принять соединение на этом адресе. Это не определяет службу, сертификат, который будет предъявлен, и то, что произойдёт после первых байтов.

Между этим рукопожатием и работающим туннелем стоят четыре этапа, и каждый даёт разную ошибку.

Открытый порт описывает только один уровень

Принять TCP-соединение означает, что процесс владеет сокетом, а путь допускает рукопожатие. Это ничего не говорит о том, является ли процесс сервером SSTP, есть ли у него сертификат, действительный для имени в вашем профиле, и авторизует ли он вашу учётную запись. Веб-сервер на том же адресе безупречно отвечает на рукопожатие, а затем отвечает на ваш запрос SSTP ошибкой HTTP. Всё выше этого рукопожатия остаётся непроверенным.

Относитесь к проверке порта как к самому дешёвому фильтру, а не как к приговору. Её ценность в том, что она исключает целую категорию отказов, а не в том, что подтверждает всё выше себя.

Путаница между этими двумя вещами — причина, по которой люди переустанавливают клиенты после теста, который так и не проверил настоящую проблему клиента.

Отделите четыре этапа доказательствами

Этапы — это достижимость транспорта, проверка TLS, обмен SSTP поверх HTTPS и аутентификация PPP внутри туннеля. Пути, который проходит первый и отказывает на четвёртом, нужна правка учётных данных; тому, что отказывает на втором, нужна правка сертификата или имени. Эти исправления не имеют ничего общего, и выбор неверного тратит время простоя.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

Третью команду стоит прочитать внимательно. Ответ 200 от обычной веб-страницы говорит, что веб-служба существует; он не говорит, что запрос SSTP будет понят. Ответ 404 с того же адреса столь же малоинформативен насчёт VPN. Только журнал клиента сообщает, какого из четырёх этапов он достиг.

Обратите внимание, какое имя использовала каждая команда. Сертификат выбирается по имени, которое вы отправляете, поэтому расхождение между профилем и тестом — это расхождение, которое внесли вы сами. Запись этого имени рядом с результатом предотвращает путаницу позже.

Читайте частичный успех в правильном направлении

Посредник может разрешать обычный просмотр и отказывать в последующем обмене, поэтому прокси, работающий для сайтов, всё ещё может не работать для туннеля. Та же картина возникает, когда сертификат действителен для имени браузера, но не для имени, настроенного в профиле: браузер доволен, а клиент нет, и оба правы в том, что проверили.

Оставляйте проверку сервера включённой, пока диагностируете это. Отключение превращает расхождение сертификата в успешное рукопожатие и скрывает единственное доказательство, которое объяснило бы отказ.

Если тот же профиль работает из другой сети, разница зависит от пути. Это сужает поиск до посредников, не указывая какого, и всё же это полезный шаг вперёд. Запишите использованную сеть, потому что сравнение без неё ничего не стоит.

Затем проверьте приложение, а не только сеанс

Когда сеанс существует, проверьте предполагаемый маршрут, разрешение имён и разрешение на службу с того клиента, которому они нужны. Подключённый туннель всё ещё может не иметь переадресации на дальней стороне или иметь обратный маршрут, которого никогда не было, и эти отказы выглядят для ожидающего человека точно как проблема приложения.

Держите каждый вывод привязанным к этапу, который его дал. Назвать открытый порт работающим VPN — это способ, которым пятиминутная проверка сертификата превращается в день переустановки программного обеспечения.