Список 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 — поддерживаемый способ передать отсутствующие учётные данные, а автоматизации без присмотра нужна другая одобренная схема вместо сохранённого пароля открытым текстом.

Короткий, скрытый отчёт легче проверить, чем полный дамп.