ConnMan VPN: отсутствующее меню — это демон, а не протокол

Распространено убеждение, что система ConnMan без пункта VPN на рабочем столе не имеет установленной поддержки VPN. Обычно поддержка Wi-Fi есть, а для демона VPN, конфигурации поставщика или агента аутентификации её нет, и это три отдельные отсутствия. Меню — это представление этих компонентов, а не сама функция. Проверка версии и упаковки скажет вам одной командой больше, чем любое число отчётов об ошибках с рабочего стола.

Миф: меню — это и есть функция VPN

Начните с установленной версии ConnMan и пакетов, которые шли с ней. Отчёт об ошибке из старого выпуска описывает другой набор функций, и его цитирование обычно заканчивается тем, что кто-то переустанавливает менеджер сети, который не нужно было заменять.

Запишите, что у вас на самом деле есть, прежде чем что-либо менять: бинарный файл демона, каталог поставщиков и есть ли агент.

Какой демон владеет туннелем

В документации ConnMan 1.41 для Debian bookworm connman-vpnd — это демон, который управляет VPN-подключениями наряду с connmand. Он перечисляет интеграции для именованных помощников VPN, включая OpenVPN и OpenConnect. Этот список — утверждение о помощниках, а не обещание, что заработает любой протокол или поток аутентификации. Читайте его как список того, что нужно проверить, а не как гарантию совместимости.

Затем сопоставьте интеграцию с утверждённым протоколом шлюза. Слово Cisco не говорит, нужно ли вам подключение в старом стиле vpnc или поток, совместимый с AnyConnect, и неверный выбор даёт сбой аутентификации, который выглядит как проблема с учётными данными.

Если и отдельный помощник, и ConnMan могут поднять туннель, решите, кто из них владеет маршрутами, DNS и жизненным циклом, прежде чем кто-либо из них начнёт.

Настройки демона — это не настройки поставщика

Общая конфигурация демона и конфигурация отдельного поставщика — это разные файлы в разных форматах. В документированном порядке bookworm демон читает /etc/connman/connman-vpn.conf, а файлы подготовки поставщиков находятся в /var/lib/connman-vpn/ с суффиксом .config. Если просто положить профиль OpenVPN в этот каталог, он не станет файлом подготовки ConnMan. А руководство поставщика для этой версии описывает разделы поставщика и поля, специфичные для типа, которые этим файлам действительно нужны.

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

Когда поставщик не загружается, сравните его поля с руководством для установленного выпуска, а не с примером из блога.

Агент аутентификации — отдельная зависимость

Определению поставщика всё ещё может требоваться агент, чтобы получить учётные данные или завершить обмен аутентификации. Для его интеграции с OpenConnect то же руководство объясняет, что недостающие значения, связанные с аутентификацией, можно запросить через VPN Agent API, и что короткоживущий cookie обычно не годится как постоянный секрет конфигурации. Этот механизм не гарантирует поддержку каждого входа в браузере, запроса MFA или проверки состояния шлюза. Подтвердите весь процесс с тем, кто отвечает за развёртывание.

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

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

Проверяйте четыре результата, а не один

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

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

Замена менеджера Wi-Fi ради кнопки — гораздо большее изменение, чем требовавшаяся отсутствующая операция, и обычно побеждает миф.