Чому 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 і сподіватися — ні.

Закритий ключ із власною парольною фразою додає другий шар. Навіть збережений пароль облікового запису не відкриє ключ, який вимагає парольної фрази, тож перевірте, який саме секрет запитує збійний етап, перш ніж щось змінювати.

Чого не робити і що робити натомість

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

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

Перевіряйте з контрольованого чистого завантаження, а не з ручної повторної спроби після входу. Повторна спроба вдається з тієї причини, через яку спроба під час завантаження провалилася, і саме ці докази знищує швидкий тест.