Список VPN у nmcli: збережені профілі проти активних тунелів

Ви запускаєте nmcli connection show, очікуючи список VPN, а отримуєте кожне з’єднання, яке машина колись зберегла, включно з мостом і точкою доступу. Шуканий VPN може бути там, може мати тип, відмінний від vpn, або взагалі не бути з’єднанням NetworkManager. Щоб зрозуміти, який із цих трьох випадків ваш, потрібні дві команди.

Два списки, два питання

connection show відповідає, що зберіг NetworkManager, а connection show --active — що зараз підключено до пристрою. Перший список включає неактивні профілі, і це навмисно: збережений VPN, який не працює, усе ще профіль, який, можливо, доведеться виправити. Плутанина між двома створює враження, що тунель працює, тоді як існує лише його конфігурація.

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

NAME, UUID і TYPE зазвичай усе, що потрібно для першого проходу, а потім ви перевіряєте єдиний запис, який вас цікавить, за UUID.

TYPE — ось де сюрпризи

OpenVPN з’єднання, якими керує плагін, показуються як тип vpn, бо плагін — це служба всередині загальної структури VPN. Власна підтримка WireGuard — це окремий повноцінний тип з’єднання, тому фільтр за vpn його не знайде. Пошук тунелю WireGuard, який нічого не повертає, зазвичай проблема фільтра, а не відсутній профіль. Це архітектурна різниця, а не дивина в назвах.

Те саме стосується інших типів тунелів, які NetworkManager з часом навчився обробляти нативно, тому прочитайте стовпець TYPE, перш ніж робити висновок, що чогось немає.

Перелічіть усе й відфільтруйте потім, і профіль з’явиться.

Читайте UUID, а не лише назву

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

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

Скопіюйте UUID у свої нотатки, коли змінюєте щось, що, можливо, доведеться відкотити.

Чого збережений профіль вам не скаже

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

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

Один власник на інтерфейс тримає список чесним, а довідка з nmcli документує, які поля насправді повідомляє кожне подання.

Повідомляйте, не розкриваючи секретів

connection show з назвою друкує налаштування, а додавання --show-secrets друкує приватні ключі та паролі разом із ними. Для вставки діагностики в тікет вони не потрібні. Натомість повідомляйте тип, UUID, стан і відповідні маршрути, а все, що прийшло зі сховища секретів, закривайте.

Інтерактивна активація з --ask — це підтримуваний спосіб надати відсутні облікові дані, а автоматизація без нагляду потребує іншої схваленої схеми замість збереженого пароля відкритим текстом.

Короткий, закритий звіт легше перевірити, ніж повний дамп.