Імпорт у NetworkManager не вдається для файлів OpenVPN і WireGuard

Я вибрав Імпорт із файлу… у налаштуваннях GNOME, вибрав профіль, який працює з клієнтом постачальника, і діалог закрився, нічого не додавши до списку. На другому ноутбуці імпорт завершився, з'єднання з'явилося під назвою профілю, а потім воно не пройшло першого запиту автентифікації. NetworkManager ніколи не запускає ваш файл .ovpn або wg-quick як є. Він передає файл парсеру, парсер перетворює його на власний формат з'єднання NetworkManager, і відтоді тунель будується з цього розібраного об'єкта — секрети, маршрути, DNS і все інше. Тож корисне питання не в тому, чому файл зламаний, а в тому, чи відбувся розбір і що він зберіг.

Що імпорт насправді робить із файлом

Для OpenVPN парсер живе в пакеті плагіна, а створене ним з'єднання вказує на службу D-Bus на кшталт org.freedesktop.NetworkManager.openvpn. Немає плагіна — немає парсера: тип невідомий nmcli, а графічний список додавання VPN може взагалі не показувати пункт імпорту. WireGuard відрізняється в одному важливому аспекті — у NetworkManager є власні налаштування WireGuard від серії 1.30, тому окремого пакета-плагіна немає, але читач wg-quick існує лише у збірках, які його постачають.

У будь-якому разі файл читається один раз. Результат записується як keyfile у /etc/NetworkManager/system-connections/, названий за з'єднанням, належить root і недоступний іншим користувачам, бо містить ключовий матеріал. Цей keyfile тепер і є з'єднанням; правка оригінального .ovpn після цього нічого не змінює.

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

Переконайтеся в наявності плагіна, перш ніж налагоджувати профіль

Відсутній плагін виглядає точно як пошкоджений профіль, тож спершу перевірте пакет. У Debian і Ubuntu підтримка OpenVPN постачається як network-manager-openvpn плюс помічник для робочого столу; у Fedora це пакети NetworkManager-openvpn і NetworkManager-openvpn-gnome; в Arch — networkmanager-openvpn.

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

Потім імпортуйте за абсолютним шляхом: nmcli connection import type openvpn file /home/you/profile.ovpn. Відносні шляхи зазвичай працюють, але оболонка, яка змінила каталог, перетворює швидкий імпорт на об'їзд. Для WireGuard перевірте nmcli --version і переконайтеся, що бік ядра існує з modprobe wireguard; імпорт, який вдається на машині без модуля, залишає вас із з'єднанням, чий пристрій так і не з'явиться. довідка nmcli документує підкоманду import і прийнятні назви типів. Якщо type wireguard відхиляється одразу, збірка старша за цю можливість, і правильний крок — пакет із дистрибутива або бекпорт, а не копіювання конфігурації до довільного каталогу в надії, що щось її прочитає.

Читайте з'єднання OpenVPN, а не .ovpn

Коли з'єднання створено, читайте розібрані налаштування, а не перечитуйте файл: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Вам потрібні remote і порт, транспорт, ідентифікаційний матеріал — ca, cert, key, tls-auth або tls-crypt — і метод автентифікації. Для профілю з паролем приватного ключа додайте sudo nmcli --show-secrets connection show "Work VPN" і подивіться на secret-прапорці: 0 — none, отже секрет лежить у keyfile; 1 — agent-owned; 2 — not-saved, тобто він ніколи не записується в keyfile; 4 — not-required, тобто секрет узагалі не потрібен. Це біти, а не шкала, тому 3 — це просто agent-owned плюс not-saved. Секрет, який запитують раз за сеанс, — це agent-owned (1), причому його запитує агент; окремого номера прапорця для цього немає. Незбіг прапорців — звичайна причина, чому профіль підключається з аплета робочого столу і не працює зі скрипта або під час завантаження.

Найшвидше побачити, що парсер викинув, попросивши плагін записати файл назад, а потім порівнявши його: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Директиви, що зникають у цьому diff, не існуватимуть під час підключення. Хуки — звичайні підозрювані: script-security, up, down і route-up розраховують на скрипт, що запускається з підвищеними правами, і навмисно не переносяться. Не знижуйте перевірку і не давайте зайвих привілеїв, щоб імпорт удався; непідтримувана опція зазвичай відображає набір можливостей плагіна, а не недоступний сервер. Перенесіть цю поведінку в dispatcher-скрипт NetworkManager або в політику на боці сервера.

Також переконайтеся, що поля ідентичності вижили: посилання на CA, remote-cert-tls і будь-яка перевірка імені, на яку покладався профіль. З'єднання, яке піднімається без них, може розмовляти з чим завгодно, що відповідає на цій адресі.

Читайте з'єднання WireGuard, а не файл wg-quick

Файл wg-quick — це формат із shell-семантикою; імпортоване з'єднання — це набір налаштувань. PrivateKey стає приватним ключем інтерфейсу, Address — однією або кількома адресами IPv4 та IPv6, DNS зіставляється з властивостями resolver у NetworkManager, MTU зіставляється з wireguard.mtu (власне значення wg-quick за замовчуванням — 1420), а кожен блок peer стає записом peer із публічним ключем, endpoint, дозволеними IP і persistent keepalive. Виведіть те, що збережено, з nmcli --show-secrets connection show wg0; якщо список peer не з'являється в цьому виводі, прочитайте keyfile:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

Не виживає shell-половина wg-quick. PreUp, PostUp, PreDown, PostDown і Table — це поведінка того інструмента, а не атрибути інтерфейсу WireGuard, тому після імпорту їх ніхто не виконує. Якщо оригінал використовував Table = off, щоб не чіпати маршрут за замовчуванням, свіжі випуски NetworkManager надають для тієї ж мети ip4-auto-default-route та ip6-auto-default-route; задайте їх явно, замість припускати, що з'єднання поводиться як скрипт. Хуку, який додавав власний маршрут, потрібен цей маршрут у налаштуваннях маршрутизації з'єднання, інакше він просто буде відсутній.

Дайте з'єднанню рівно одного власника

Класичний наступний збій — з'єднання, яке працює до наступного завантаження, а потім зациклюється. Зазвичай [email protected] все ще був увімкнений з минулого експерименту, або клієнт постачальника запускав власний демон, і два власники писали маршрути й DNS для одного й того самого призначення. NetworkManager задає resolver своїм шляхом, wg-quick пише через resolvconf, і перемагає останній, хто пише — тож розв'язання імен працює, потім припиняється, потім знову працює. Перевірте systemctl status wg-quick@wg0, nmcli connection show --active і ip link show type wireguard, а потім вимкніть другого власника, замість підкручувати його метрику.

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

Перевірте трафіком і переживіть перезавантаження

Підніміть з'єднання з nmcli connection up "Work VPN", а потім читайте стан, адресу й маршрути, замість довіряти значку: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default і справжній запит імені, яке розв'язується лише всередині тунелю. Handshake або успішний ping доводить лише те, що криптографія працює; він нічого не каже про пересилання, префікси split tunnel чи приватний DNS — а це зазвичай і ламається.

Потім перезавантажтеся і повторіть. Поведінка autoconnect, перейменований інтерфейс і плагін, який завантажується після пристрою, — усе це збої, які видно лише при чистому завантаженні. journalctl -u NetworkManager -b --no-pager | tail -n 40 показує, що демон зробив із цим з'єднанням у цьому завантаженні. Для другого комп'ютера скопіюйте keyfile і тримайте його у власності root із режимом 600, або використайте nmcli connection export для OpenVPN і повторно імпортуйте отриманий .ovpn — шлях експорту не має відповідника для WireGuard, тож цей напрямок — копія файлу або новий імпорт із захищеного оригіналу.

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