SSTP в Linux не работает до входа? Проверьте компоненты выполнения

Вы устанавливаете плагин SSTP, переключатель появляется в редакторе сети, вы вводите шлюз и имя пользователя, и профиль отказывает с общей ошибкой ещё до запроса пароля. В этой последовательности нет ничего необычного, и ничто в ней не доказывает, что ПО туннеля установлено. Соединение SSTP собирается из частей, которые поставляются отдельно: плагин VPN, который NetworkManager может запустить, клиентская программа SSTP, владеющая сеансом TLS и PPP, демон PPP под ней и хранилище секретов, которое соединению разрешено читать.

Что добавляет пункт меню, а что нет

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

Затем клиенту нужен PPP, потому что SSTP переносит сеанс PPP внутри соединения TLS. Без pppd туннель может завершить рукопожатие TLS и всё равно умереть на первом управляющем кадре, что выглядит как проблема учётных данных и ею не является. В Debian и Ubuntu части приходят как network-manager-sstp, sstp-client и ppp, и установка только первой — самая частая причина того, что форма принимает все поля, а соединение так и не устанавливается.

Выбор рабочего стола добавляет ещё одно разделение. Plasma редактирует профили через plasma-nm, которому нужен собственный компонент SSTP и который читает то же описание службы, поэтому редактор без пункта SSTP и CLI, который прекрасно создаёт профили, — это отсутствующая половина редактора, а не сломанная среда выполнения.

Прочитайте первый неудачный этап, прежде чем что-либо переустанавливать

Неудачная попытка SSTP проходит этапы в фиксированном порядке, и тот этап, который не удался, подсказывает, на какой компонент смотреть.

Запуск плагина — первый, и сбой там даёт сообщение о службе VPN, а не о сервере. Затем идёт TCP-соединение к порту 443; отказ или тайм-аут здесь — проблема доступности, а не TLS. Потом рукопожатие TLS и проверка подлинности сервера, затем согласование PPP и аутентификация учётной записи, и наконец назначение адресов и маршруты. Наблюдайте за journalctl -f -u NetworkManager, когда активируете профиль один раз, и читайте первую конкретную строку, а не последнюю общую.

Этот порядок объясняет распространённое неверное прочтение. Жалоба на сертификат появляется до отправки любых учётных данных, поэтому смена пароля не может помочь; отказ аутентификации PPP приходит после успешного рукопожатия, поэтому замена сертификата тоже не поможет. Сохраните первую ошибку и её этап, и у вас будет диагноз, а не симптом.

Доверие к сертификату и вход в учётную запись — разные ворота

Рукопожатие проверяет, что сервер — тот, к которому вы хотели попасть, по настроенным издателю и имени. Только после этого слой PPP предлагает имя пользователя и пароль методу аутентификации шлюза. Две независимые проверки, значит, оцениваются в фиксированном порядке, с отдельными настройками для каждой. Ничто введённое в поле пароля не может повлиять на первую.

Профиль, доверяющий неверному издателю, отказывает на первых воротах с ошибкой идентичности. Профиль, доверяющий ему правильно, но хранящий устаревший пароль, отказывает на вторых с отказом аутентификации. Оба выглядят как VPN, которая не подключится, и ни один не исправляется средством другого.

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

Пусть один владелец держит профиль и секреты

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

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

Проверьте туннель, маршруты и резолвер по отдельности

Индикатор «подключено» утверждает лишь, что соединение поднялось. Проверьте цель, которая вам действительно нужна, маршрут, который её несёт, и используемый резолвер, по одному; каждый может быть неверным, пока два других в порядке.

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

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