Wi-Fi підключається сам; VPN потрібен вторинний зв'язок

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

Автопідключення — не перемикач VPN

Профіль Wi-Fi або Ethernet може активуватися сам, бо володіє пристроєм. Профіль плагіна VPN не володіє пристроєм у тому ж сенсі; він запускається поруч із з'єднанням, яке ним володіє. Тому прапорець автопідключення на VPN виглядає правильним, зберігається коректно й не створює тунелю. Прапорець відповідає на питання про профіль, а не про мережу, яка йому потрібна.

Таке читання моделі пояснює і режим відмови. База підключається, ніщо не просить VPN запуститися, і робочий стіл показує відключений VPN поруч із підключеною мережею. Ніщо не зламано; зв'язок просто ніколи не створювався.

Визначте обидва профілі за UUID

nmcli -f NAME,UUID,TYPE connection show

Виберіть профіль Wi-Fi або Ethernet, який має запускати тунель, потім потрібний профіль VPN. Використовуйте UUID, а не імена, бо ім'я — це мітка, яку можна дублювати або змінити, а UUID — це те, що шлях активації справді розв'язує.

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

Додайте VPN до базового з'єднання

nmcli connection modify uuid "PRIMARY_UUID" +connection.secondaries "VPN_UUID"

Форма з плюсом додає до наявного списку; якщо її пропустити, список замінюється, що мовчки видаляє будь-яке інше вже налаштоване вторинне з'єднання. Спочатку подивіться поточне значення і запишіть його, перш ніж щось змінювати.

Налаштування з'єднань NetworkManager описують вторинні як VPN-з'єднання, що запускаються разом із базовим. Чи є вбудований профіль WireGuard тим самим типом об'єкта, залежить від того, як NetworkManager ним керує, тому та сама команда може бути неправильним інструментом для тунелю, який виглядає як інтерфейс, а не як плагін VPN.

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

Секрети не входять до зв'язку

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

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

Прочитайте обидві події, потім перевірте ресурс

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

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