Вторинне VPN-з'єднання належить одному профілю Wi-Fi, а не всім

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

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

Що таке вторинне з'єднання насправді

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

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

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

Розмістіть зв'язок там, де створюються профілі

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

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

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

Плануйте зміну ідентичності VPN

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

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

Активація — це не примус

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

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

Внесіть цю різницю в інструкції, які користувачі справді читають. Нова мережа Wi-Fi може попросити тунель; примус вирішує, чи може щось вийти, коли під'єднатися не вдається. Користувачі, яким розповіли лише першу половину, повідомлять, що проєкт зламаний.

Тестуйте зі справді новим профілем

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

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