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, а недаўгавечныя кукі, як правіла, не падыходзяць як пастаянны сакрэт канфігурацыі. Гэты механізм не гарантуе падтрымку кожнага ўваходу праз браўзер, запыту MFA або праверкі стану шлюза. Пацвердзіце ўвесь працэс з тымі, хто валодае разгортваннем.
Не кампенсуйце адсутнасць агента запісам пароля або токена сеансу ў файл, які шырока чытаецца. Гэта ператварае адсутную інтэграцыю ва ўцечку ўліковых даных, і другая праблема жыве даўжэй за першую.
Калі шлюз патрабуе інтэрактыўнага ўваходу, агент з'яўляецца часткай праекта, а не дадатковым пунктам.
Праверце чатыры вынікі, а не адзін
Пасля дазволенага забеспячэння праверце чатыры рэчы асобна: пастаўшчык выбраны, злучэнне аўтэнтыфікавана, эфектыўныя маршруты — тыя, што вы мелі на ўвазе, і рэзалвер паводзіць сябе як чакалася. Працуючы дэман, пастаўшчык у спісе і праграма, якая дасягае свайго рэсурсу, — гэта тры розныя вынікі, і толькі апошні з'яўляецца сапраўднай мэтай карыстальніка. Асобны запіс гэтых вынікаў скажа, які этап трэба выправіць.
Уключыце ў гэтую праверку паводзіны пры перападключэнні і патрабаваную палітыку стану недаступнасці, бо тунель, які ўзнімаецца адзін раз і ніколі не аднаўляецца, не лічыцца разгорнутым. Трымайце працоўную канфігурацыю базавай сеткі аднаўляльнай, пакуль змяняеце інтэграцыю VPN.
Замена менеджэра Wi-Fi дзеля атрымання кнопкі — значна большае змяненне, чым патрабавалася для адсутнай аперацыі, і звычайна гэта перамога міфа.