ConnMan VPN: Die ontbrekende kieslys is 'n daemon, nie 'n protokol nie

Die oortuiging is dat 'n ConnMan-stelsel sonder 'n VPN-inskrywing op die tafelblad geen VPN-ondersteuning geïnstalleer het nie. Dit het gewoonlik ondersteuning vir Wi-Fi en niks vir die VPN-daemon, die verskafferkonfigurasie of die verifikasie-agent nie, en dit is drie afsonderlike afwesighede. Die kieslys is 'n aansig op daardie komponente, nie die funksie self nie. Om die weergawe en die verpakking na te gaan vertel jou meer in een opdrag as enige aantal tafelblad-foutverslae.

Die mite: die kieslys is die VPN-funksie

Begin met die geïnstalleerde ConnMan-weergawe en die pakkette wat daarmee saamgekom het. 'n Foutverslag uit 'n ouer uitgawe beskryf 'n ander stel funksies, en om dit aan te haal eindig gewoonlik met iemand wat 'n netwerkbestuurder herinstalleer wat hulle nie nodig gehad het om te vervang nie.

Skryf neer wat jy werklik het voordat jy enigiets verander: die daemon-lêer, die verskaffergids, en of 'n agent teenwoordig is.

Watter daemon besit die tonnel

In die Debian bookworm ConnMan 1.41-dokumentasie is connman-vpnd die daemon wat VPN-verbindings bestuur saam met connmand. Dit lys integrasies vir genoemde VPN-hulpprogramme, insluitend OpenVPN en OpenConnect. Daardie lys is 'n verklaring oor hulpmiddels, nie 'n belofte dat elke protokol of verifikasiewerkstroom sal werk nie. Lees dit as 'n kieslys van wat om na te gaan, nie as 'n versoenbaarheidsgarantie nie.

Pas dan die integrasie by die poort se goedgekeurde protokol. Die woord Cisco sê nie vir jou of jy 'n ou vpnc-tipe verbinding of 'n AnyConnect-versoenbare werkstroom nodig het nie, en die verkeerde keuse lewer 'n verifikasiemislukking op wat soos 'n geloofwaardigheidsprobleem lyk.

As beide 'n selfstandige hulpmiddel en ConnMan die tonnel kan opbring, besluit watter een roetes, DNS en lewensiklus besit voordat enigeen begin.

Daemon-instellings is nie verskaffer-instellings nie

Die daemon se algemene konfigurasie en 'n individuele verskaffer se konfigurasie is verskillende lêers met verskillende formate. In die gedokumenteerde bookworm-reëling lees die daemon /etc/connman/connman-vpn.conf, terwyl verskaffer-voorsieningslêers onder /var/lib/connman-vpn/ met 'n .config-agtervoegsel woon. Om 'n OpenVPN-profiel in daardie gids te laat val, maak dit nie 'n ConnMan-voorsieningslêer nie. Die weergawe-gebonde verskafferhandleiding beskryf die verskafferafdelings en die tipe-spesifieke velde wat daardie lêers werklik nodig het.

Vertaal slegs deur die geïnstalleerde integrasie se ondersteunde kartering. Sertifikaatvertroue, privaatsleutelverwysings, poortidentiteit, roetes en verifikasie-insette behou elkeen hul eie rol, en 'n voorbeeld vir 'n ander verskaffertipe is nie uitruilbaar net omdat beide 'n bedieneradres nodig het nie.

Wanneer 'n verskaffer nie laai nie, vergelyk sy velde met die handleiding vir die geïnstalleerde uitgawe eerder as met 'n blogvoorbeeld.

Die verifikasie-agent is 'n afsonderlike afhanklikheid

'n Verskafferdefinisie kan steeds 'n agent nodig hê om geloofsbriewe te bekom of 'n verifikasie-uitruiling te voltooi. Vir sy OpenConnect-integrasie verduidelik dieselfde handleiding dat ontbrekende verifikasiateverwante waardes deur die VPN Agent API aangevra kan word, en dat 'n kortstondige koekie gewoonlik nie geskik is as 'n permanente konfigurasiegeheim nie. Daardie meganisme waarborg nie ondersteuning vir elke blaaier-aanmelding, MFA-vraag of poort-houdingkontrole nie. Bevestig die hele werkstroom met diegene wat die ontplooiing besit.

Moenie 'n afwesige agent vergoed deur 'n wagwoord of 'n sessietoken in 'n wyd leesbare lêer te skryf nie. Dit omskep 'n ontbrekende integrasie in 'n geloofsbrief-blootstelling, en die tweede probleem oorleef die eerste.

As die poort 'n interaktiewe aanmelding nodig het, is die agent deel van die ontwerp eerder as 'n opsionele bykomstigheid.

Verifieer vier uitkomste, nie een nie

Na gemagtigde voorsiening, kontroleer vier dinge afsonderlik: die verskaffer is gekies, die verbinding is geverifieer, die effektiewe roetes is dié wat jy bedoel het, en die resolver gedra hom soos verwag. 'n Lopende daemon, 'n gelyste verskaffer en 'n toepassing wat sy hulpbron bereik is drie verskillende uitkomste, en slegs die laaste een is die gebruiker se werklike doel. Om hulle afsonderlik aan te teken, sê vir jou watter stadium om reg te maak.

Sluit herverbindingsgedrag en die vereiste onbeskikbaarheid-beleid by daardie kontrole in, want 'n tonnel wat een keer opkom en nooit herstel nie, is nie ontplooi nie. Hou die werkende basisnetwerk-konfigurasie herstelbaar terwyl jy die VPN-integrasie verander.

Om die Wi-Fi-bestuurder te vervang net om 'n knoppie te kry, is 'n veel groter verandering as die ontbrekende bewerking wat nodig is, en dit is gewoonlik die mite wat wen.