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, и че краткотрайно бисквитка по принцип не е подходяща като постоянна тайна на конфигурацията. Този механизъм не гарантира поддръжка на всеки вход през браузър, заявка за MFA или проверка на състоянието на шлюза. Потвърдете целия работен поток с този, който отговаря за внедряването.

Не компенсирайте липсващия агент, като запишете парола или токен за сесия във файл, четим от много хора. Това превръща липсващата интеграция в излагане на идентификационни данни и вторият проблем живее по-дълго от първия.

Ако шлюзът изисква интерактивен вход, агентът е част от дизайна, а не допълнителна опция.

Проверете четири резултата, не един

След разрешено осигуряване проверете четири неща поотделно: доставчикът е избран, връзката е удостоверена, ефективните маршрути са тези, които сте искали, и резолверът се държи както се очаква. Работещ демон, изброен доставчик и приложение, което достига своя ресурс, са три различни резултата и само последният е действителната цел на потребителя. Отделното им записване ви казва кой етап да поправите.

Включете в тази проверка поведението при повторно свързване и изискваната политика за състояние на недостъпност, защото тунел, който се вдига веднъж и никога не се възстановява, не е внедрен. Пазете работещата конфигурация на базовата мрежа възстановима, докато променяте интеграцията VPN.

Смяната на Wi-Fi мениджъра, за да получите бутон, е много по-голяма промяна от необходимата липсваща операция и обикновено митът печели.