ConnMan VPN: Ang Nawawalang Menu ay Daemon, Hindi Protokol

Ang paniniwala ay ang isang sistemang ConnMan na walang entry ng VPN sa desktop ay walang naka-install na suporta sa VPN. Karaniwang may suporta ito para sa Wi-Fi at wala para sa daemon ng VPN, sa configuration ng provider o sa agent ng authentication, at iyon ay tatlong magkahiwalay na kawalan. Ang menu ay isang tanaw sa mga bahaging iyon, hindi ang feature mismo. Pagsuri sa bersyon at sa packaging ay nagsasabi sa iyo nang higit sa isang utos kaysa sa anumang bilang ng mga ulat ng bug sa desktop.

Ang mito: ang menu ang feature ng VPN

Magsimula sa naka-install na bersyon ng ConnMan at sa mga package na kasama nito. Ang ulat ng bug mula sa lumang release ay naglalarawan ng ibang set ng feature, at ang pagsipi nito ay kadalasang nagtatapos sa isang taong muling nag-i-install ng network manager na hindi naman kailangang palitan.

Isulat kung ano talaga ang mayroon ka bago magbago ng anuman: ang binary ng daemon, ang direktoryo ng mga provider at kung may agent.

Aling daemon ang may-ari ng tunnel

Sa dokumentasyon ng ConnMan 1.41 para sa Debian bookworm, ang connman-vpnd ang daemon na namamahala ng mga koneksyon ng VPN kasama ng connmand. Naglilista ito ng mga integrasyon para sa mga pinangalanang helper ng VPN, kabilang ang OpenVPN at OpenConnect. Ang listahang iyon ay isang pahayag tungkol sa mga helper, hindi isang pangakong gagana ang bawat protokol o daloy ng authentication. Basahin ito bilang menu ng dapat suriin, hindi bilang garantiya ng compatibility.

Pagkatapos itugma ang integrasyon sa aprubadong protokol ng gateway. Ang salitang Cisco ay hindi nagsasabi kung kailangan mo ng koneksyong estilo lumang vpnc o daloy na compatible sa AnyConnect, at ang maling pagpili ay gumagawa ng pagkabigo sa authentication na mukhang problema sa mga kredensyal.

Kung ang isang standalone na helper at ang ConnMan ay parehong kayang itaas ang tunnel, magpasya kung alin ang may-ari ng mga ruta, DNS at lifecycle bago magsimula ang alinman sa kanila.

Ang mga setting ng daemon ay hindi setting ng provider

Ang pangkalahatang configuration ng daemon at ang configuration ng isang provider ay magkaibang file na may magkaibang format. Sa dokumentadong kaayusan ng bookworm, binabasa ng daemon ang /etc/connman/connman-vpn.conf, habang ang mga file ng provisioning ng provider ay nasa ilalim ng /var/lib/connman-vpn/ na may suffix na .config. Ang paglalagay ng profile ng OpenVPN sa direktoryong iyon ay hindi ito ginagawang file ng provisioning ng ConnMan. Ang manwal ng provider para sa bersyong ito ay naglalarawan ng mga seksyon ng provider at ng mga field na partikular sa uri na talagang kailangan ng mga file na iyon.

Isalin lamang sa pamamagitan ng sinusuportahang mapping ng naka-install na integrasyon. Ang tiwala sa certificate, mga reference sa private key, pagkakakilanlan ng gateway, mga ruta at mga input ng authentication ay pinapanatili ng bawat isa ang sariling papel, at ang isang sample para sa ibang uri ng provider ay hindi mapagpapalit lamang dahil parehong kailangan ng address ng server.

Kapag hindi nag-load ang isang provider, ihambing ang mga field nito sa manwal para sa naka-install na release at hindi sa isang halimbawa mula sa blog.

Ang agent ng authentication ay isang hiwalay na dependency

Ang isang depinisyon ng provider ay maaaring kailanganin pa rin ng agent upang kumuha ng mga kredensyal o tapusin ang isang palitan ng authentication. Para sa integrasyon nito sa OpenConnect, ipinapaliwanag ng parehong manwal na ang mga nawawalang value na may kaugnayan sa authentication ay maaaring hilingin sa pamamagitan ng VPN Agent API, at na ang isang panandaliang cookie ay karaniwang hindi angkop bilang permanenteng lihim ng configuration. Ang mekanismong iyon ay hindi gumagarantiya ng suporta para sa bawat pag-login sa browser, kahilingan sa MFA o pagsusuri ng postura ng gateway. Kumpirmahin ang buong daloy sa taong may-ari ng deployment.

Huwag bawiin ang nawawalang agent sa pamamagitan ng pagsulat ng password o session token sa isang file na malawak na mababasa. Ginagawa nitong pagkakalantad ng kredensyal ang nawawalang integrasyon, at ang pangalawang problema ay mas matagal kaysa sa una.

Kung ang gateway ay nangangailangan ng interactive na pag-login, ang agent ay bahagi ng disenyo at hindi opsyonal na dagdag.

I-verify ang apat na resulta, hindi isa

Pagkatapos ng awtorisadong provisioning, suriin ang apat na bagay nang hiwalay: napili ang provider, na-authenticate ang koneksyon, ang mga epektibong ruta ay ang intensyon mo, at kumikilos ang resolver ayon sa inaasahan. Ang tumatakbong daemon, nakalistang provider at aplikasyong nakararating sa resource nito ay tatlong magkaibang resulta, at ang huli lamang ang tunay na layunin ng gumagamit. Ang hiwalay na pagtatala ng mga ito ay nagsasabi kung aling yugto ang aayusin.

Isama sa pagsusuring iyon ang pag-uugali sa muling pagkonekta at ang kinakailangang patakaran sa hindi available na estado, dahil ang isang tunnel na bumangon nang isang beses at hindi na gumaling ay hindi naka-deploy. Panatilihing maibabalik ang gumaganang configuration ng base network habang binabago mo ang integrasyon ng VPN.

Ang palitan ang manager ng Wi-Fi para makakuha ng button ay mas malaking pagbabago kaysa sa nawawalang operasyon na kailangan, at kadalasan ang mito ang nananalo.