Keyfile или Netplan: где на самом деле хранится профиль VPN?

Найти импортированный файл — это лёгкая часть и часто неверное начало. Важно то, какой файл NetworkManager сегодня читает как сохранённое подключение, и это зависит от идентификатора подключения и того бэкенда конфигурации, который установленные пакеты действительно используют. Правка импорта до ответа на этот вопрос — это путь, которым работающий VPN превращается в две наполовину правильные конфигурации.

Импортированный файл — не сохранённый профиль

Вокруг каждой проблемы VPN кружат три имени: имя подключения, имя импортированного файла и виртуальный интерфейс, который появляется при поднятии туннеля. Ни одно из них не идентифицирует сохранённую конфигурацию, а имя подключения можно изменить, пока файл за ним сохраняет свой исходный идентификатор.

Начните с описи только для чтения и выберите нужный VPN по идентификатору, а не по метке:

nmcli -f NAME,UUID,TYPE connection show

Держите имена хостов конечных точек и метки идентичности вне любой описи, которую вы вставляете в заявку. Полезная часть — тип и идентификатор; остальное — контекст, который постороннему не нужен. Отредактируйте остальное перед публикацией и скажите, что вы это сделали, чтобы никто не гадал, что означают пропуски.

Расположения keyfile не означают одно и то же

С нативным плагином keyfile файлы подключений могут появляться в трёх каталогах, и разница между ними — это устойчивость, а не удобство.

Правка копии времени выполнения выглядит успешной до следующего запуска, когда изменение испаряется и файл выглядит загадочно возвращённым. Правка копии, поставляемой пакетом, работает, пока обновление не заменит её, — это более медленная и запутанная версия того же урока.

Документация keyfile добавляет деталь, которую стоит уважать: эти файлы могут содержать закрытые ключи и парольные фразы, и NetworkManager игнорирует любой keyfile, который могут читать или записывать пользователи, отличные от root. Расширение прав каталога ради поиска настройки ломает то поведение загрузки, которое вы пытались изучить.

Когда устойчивостью владеет Netplan

В Ubuntu интеграция NetworkManager, описанная в документации Netplan и доступная с 23.10, меняет место, где живёт долговечная копия. Для невременных подключений она записывает /etc/netplan/90-NM-<connection UUID>.yaml и создаёт эфемерный профиль NetworkManager в /run/NetworkManager/system-connections/.

Это интеграция дистрибутива, а не правило для каждой установки NetworkManager. Убедитесь, что установленные пакеты действительно её используют, прежде чем искать файл YAML. Помните также, что профиль времени выполнения может быть сгенерированным представлением чего-то другого, а не источником, который стоит править. Две команды проверки экономят час правки не того файла.

Документированный пример хранит подключение OpenVPN через тип Netplan nm-devices с данными сквозной передачи NetworkManager. То, что у Netplan нет собственной интерпретации конкретного поля VPN, не значит, что сохранённый VPN потерян; это значит, что поле путешествует как непрозрачные данные.

Временные интерфейсы — не профили

Активация создаёт временные виртуальные подключения и интерфейсы, которые никогда не должны были сохраняться. Интеграция намеренно не пишет новый файл YAML для каждого из них, поэтому их отсутствие в /etc/netplan ничего не говорит о том, сохранён ли родительский профиль.

Если вы гоняетесь за файлом, который появляется и исчезает, вы, вероятно, смотрите на один из них, а не на свою конфигурацию. Проверьте, переживает ли он перезапуск, прежде чем делать какой-либо вывод из его содержимого. Файл времени выполнения, исчезающий при перезагрузке, говорит вам, что он никогда не был источником, и это единственное наблюдение перенаправляет всё расследование. Оно также объясняет, почему правка тогда казалась успешной.

Секреты и владение

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

Изучите ссылки и флаги секретов, не печатая секретные значения. Вход в настольную сессию может сделать доступным агента, которого не было при загрузке, а копирование сгенерированного файла времени выполнения не воспроизводит этого агента. Практический симптом — туннель, который подключается, когда человек входит в систему, и отказывает, когда машина запускается одна. Этот шаблон указывает на владение секретами, а не на маршрутизацию.

Вносите одобренные изменения через менеджер, владеющий подключением, затем проверьте и сохранённый идентификатор, и действующее подключение. Держите одного постоянного владельца, потому что независимая правка импорта, сгенерированного keyfile и источника YAML оставляет три конкурирующих объяснения того, что использует следующее переподключение. Выберите то, что действительно сохраняется, правьте только это и отметьте в заявке, какой файл вы сочли авторитетным. Следующий человек поблагодарит вас за одну строку происхождения.