ConnMan VPN: відсутнє меню — це демон, а не протокол
Відсутність меню VPN у 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 заради кнопки — значно більша зміна, ніж потрібна була відсутня операція, і зазвичай перемагає міф.