Чи може цей плагін NetworkManager запустити два VPN одночасно?

У списку з'єднань два записи VPN, обидва кажуть з'єднано, і лише один із них несе трафік, який ви очікували. Або другий взагалі відмовляється запускатися, і ніхто не може сказати, чи винен плагін, клієнт або забута політика. Твердження про обмеження в один VPN описують конкретні реалізації, а реалізації різняться. Спочатку пройдіть можливість, потім узгодження.

Спочатку порахуйте збережені профілі, потім активації

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

Активація того самого UUID двічі — це третій випадок, і це не паралельність. Це повторна активація одного екземпляра.

Прочитайте власні метадані плагіна

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

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

Паралельний не означає узгоджений

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

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

DNS обирає переможця, хочете ви цього чи ні

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

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

Розгортайте у фіксованому порядку і перевіряйте між кроками

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

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