Почему VPN-служба, запущенная при загрузке, не может прочитать вашу связку ключей

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

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

Что на самом деле запрашивает путь загрузки

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

Сбой записан в самом подключении, а не спрятан в связке ключей.

Чтение флагов секретов на подключении

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

Начните со списка профилей, затем подтвердите, какое подключение настроено подниматься само. Затем выведите одно подключение и прочитайте флаги пароля:

nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show
nmcli connection show "Work VPN" | grep -i -E "password|secret|key"
journalctl -b -u NetworkManager --grep "secret"

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

Почему перенос подключения в системную область меняет ответ

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

Этот перенос — законный дизайн, и он несёт требование: секрет должен быть доступен системной службе. Хранить его в профиле, предоставлять через учётные данные системной области или принимать интерактивный запрос в нужный момент — всё это допустимые ответы. Оставить флаг 1 и надеяться — нет.

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

Чего не делать и что делать вместо этого

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

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

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