Где Linux должен хранить ваш пароль VPN? Не в профиле
Флаги секретов NetworkManager решают, хранит ли пароль профиль, агент связки ключей или никто. Ответ зависит от того, когда запускается соединение.
Пароль VPN должен где-то жить: в профиле соединения, в связке ключей, которую разблокирует рабочий стол, или нигде. NetworkManager называет этот выбор флагом секрета, и именно неверный выбор — причина того, что соединение работает после входа в систему и не работает как служба. Флаг — это одна строка конфигурации, и он решает, какой из трёх исходов вы получите.
Три флага покрывают почти все случаи, и решение зависит от того, когда запускается соединение.
Три флага секретов, три поведения
Флаг 0 означает, что секрет сохраняется вместе с соединением, в любом хранилище, где лежит профиль. Флаг 1 делает его собственностью агента: секрет поступает от агента секретов, например связки ключей рабочего стола, и NetworkManager запрашивает его при активации. Флаг 2 означает не сохранён, поэтому секрет никогда не записывается и должен предоставляться каждый раз. Флаг 4 помечает секрет как необязательный, для соединений, которым он действительно не нужен.
| Flag | Where it lives | Works unattended |
|---|---|---|
| 0 saved | Connection profile | Yes, if the store is readable |
| 1 agent-owned | Secret agent or keyring | Only if that agent is available |
| 2 not-saved | Nowhere | No |
Задавайте флаги для каждого секрета, а не для соединения. У одного соединения могут быть пароль, принадлежащий агенту, и сохранённая парольная фраза закрытого ключа.
Решайте по тому, когда запускается соединение
Если соединение запускает вошедший пользователь, собственность агента — разумное значение по умолчанию: связка ключей разблокируется при входе, и секрет никогда не лежит в файле. Если соединение должно подняться до того, как кто-либо войдёт, собственность агента — неверный выбор, потому что нет связки ключей сеанса, которую можно разблокировать.
Вот и всё решение. Всё остальное — его вариант.
Для службы до входа в систему поддерживаемый шаблон — хранилище системного уровня или защищённый файл ключа, и защитой становятся права доступа к файлу. Не решайте проблему, вставляя пароль в shell-скрипт, который выполняется при загрузке.
Что даёт связка ключей и что нет
Связка ключей держит секрет вне профиля соединения и привязывает его к сеансу пользователя. Она не делает секрет доступным службе без сеанса и ничего не шифрует в сети. Это отдельные свойства, которые люди часто смешивают. Что она действительно даёт, так это меньший радиус поражения, когда профильный файл утекает.
Закрытый ключ, на который ссылается профиль, требует собственных прав, независимо от того, где живёт пароль.
Диагностика без вываливания секретов
Имён соединений, UUID и флагов обычно достаточно, чтобы объяснить сбой. nmcli connection show перечисляет профиль, а флаги секретов подсказывают, откуда пароль должен был взяться.
Избегайте --show-secrets в заявках и чатах. Как только он вставлен, это учётные данные в стенограмме.
Хранение — это не отзыв
Удаление секрета из одной связки ключей не аннулирует учётные данные, которые удалённый оператор уже принял. Отзыв учётной записи — действие на стороне сервера, а локальное хранение — отдельный вопрос с отдельным владельцем.
Решайте и то и другое до инцидента, а не во время него. Интерактивное пользовательское соединение и служба до входа требуют разных ответов, а общий shell-скрипт не является ни тем, ни другим. Документация NetworkManager о флагах секретов перечисляет значения полностью.