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

Лаунчер — це покажчик, а не сховище облікових даних.

Знайдіть UUID і підтвердьте ідентичність

Перелічіть збережені підключення та прочитайте UUID, ідентифікатор підключення й ім’я користувача, яке зберігає кожен профіль. Підтвердьте, який профіль належить якому акаунту, перш ніж щось створювати, бо відображуване ім’я — це мітка, а не ключ. Якщо двом акаунтам потрібні різні шлюзи або різні профілі, це окреме завдання налаштування.

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

Напишіть запис робочого столу

Запису робочого столу потрібні тип, ім’я та виконуваний рядок. Команда має підняти цей UUID і дозволити NetworkManager запитати секрет — для цього й призначений nmcli --ask connection up uuid .... Збережіть Terminal=true, щоб запит було видно, коли потрібен секрет. Замініть заповнювач на UUID, який ви справді спостерігали, і не додавайте обгортку оболонки лише для того, щоб приховати запит.

Специфікація Desktop Entry визначає Exec як програму та її аргументи. Це не скрипт оболонки, і він не потребує його.

Дозвольте агенту тримати секрет

Секрети належать агенту для кожного користувача, зв’язці ключів або інтерактивному запиту. Пароль у Exec видно в списку процесів, у файлі робочого столу та на будь-якому знімку екрана діалогу властивостей. Якщо профілю потрібен секрет, дозвольте підтримуваному запиту зібрати його, а агенту — запам’ятати його для цього користувача.

--ask є інтерактивним за задумом. Це не рецепт для автоматизації без нагляду, і він не гарантує, що кожен виклик автентифікації чи плагін взагалі можна перевести в скрипт.

Не хапайтеся за sudo

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

Два активні профілі для одного шлюзу можуть також конкурувати за маршрути або порушувати правило одночасності. Це питання політики, а не помилка лаунчера.

Перевірте всю дію

Активуйте лаунчер один раз і підтвердьте три речі: який UUID піднявся, яку ідентичність побачив шлюз і чи з’явився запит секрету там, де ви його чекали. Якщо підключення не вдалося, збережіть перше повідомлення про помилку. Додавання пароля до командного рядка, щоб ярлик виглядав самодостатнім, приховує цю помилку і створює гіршу проблему.

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

Схожі статті