SSTP сначала аутентифицирует сервер, а затем пользователя

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

Доверенный сертификат доказывает конечную точку; об учётной записи он ничего не говорит.

Что устанавливает рукопожатие TLS

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

Поэтому удалять проверки сертификата, чтобы добраться до приглашения входа, — неправильное исправление. Вы получаете приглашение входа на соединении, которое не можете проверить. Ошибка сертификата относится к имени хоста, часам, цепочке или конфигурации доверия.

Что добавляют SSTP и PPP

SSTP работает поверх HTTPS и несёт внутри PPP, со своим обменом управления вокруг соединения. Затем PPP выполняет свои этапы установки связи и аутентификации, а метод аутентификации зависит от политики сервера и возможностей клиента. PAP, CHAP, MS-CHAPv2 и EAP — все это варианты аутентификации PPP с очень разными свойствами. Проверка пользователя в VPN — это именно этап PPP, а не слой TLS под ним.

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

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

Соотнесите ошибку с этапом

Проверьте, доходит ли соединение до TLS, затем до обмена HTTP SSTP, затем до этапа PPP. Держите метки времени в журналах выровненными между попытками, чтобы более ранний сбой не путали с более поздним успехом. Клиент, который записывает две попытки в одном окне, иначе будет выглядеть так, будто он потерпел неудачу на последнем достигнутом этапе. Читайте первую значимую ошибку, а не последнюю строку.

То же выравнивание важно на стороне сервера, где запись аутентификации и журнал транспорта часто представляют собой отдельные файлы с отдельными часами. Двух минут расхождения достаточно, чтобы очевидная причина выглядела невозможной.

После входа авторизация по-прежнему отдельная

Успешный вход не даёт доступа ко всем частным ресурсам. Маршруты определяют, что доступно, DNS определяет, что разрешается, и каждая служба по-прежнему применяет свои права. Сеанс, показанный как подключённый, — это утверждение о туннеле, а не о файловом ресурсе. Когда пользователь может подключиться и не может достичь одного хоста, этап туннеля уже завершён.

Это та же слоистость, которую показало рукопожатие, на уровень выше.

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