ConnMan VPN: Den manglande menyen er ein daemon, ikkje ein protokoll

Førestillinga er at eit ConnMan-system utan VPN-oppføring på skrivebordet ikkje har VPN-støtte installert. Vanlegvis har det støtte for Wi-Fi og inga for VPN-daemonen, leverandørkonfigurasjonen eller autentiseringsagenten, og det er tre separate fråvær. Menyen er ei vising av desse komponentane, ikkje funksjonen sjølv. Kontrollere versjonen og pakkinga fortel deg meir med éin kommando enn noko tal feilrapportar frå skrivebordet.

Myten: menyen er VPN-funksjonen

Start med den installerte ConnMan-versjonen og pakkane som følgde med han. Ein feilrapport frå ei eldre utgåve skildrar eit anna funksjonssett, og å sitere han endar vanlegvis med at nokon reinstallerer ein nettverkshandsamar dei ikkje trongde å bytte ut.

Skriv ned kva du faktisk har før du endrar noko: den binære daemon-fila, leverandørmappa og om det finst ein agent.

Kva daemon som eig tunnelen

I ConnMan 1.41-dokumentasjonen for Debian bookworm er connman-vpnd daemonen som styrer VPN-tilkoplingar ved sida av connmand. Han listar opp integrasjonar for namngjevne VPN-hjelparar, mellom anna OpenVPN og OpenConnect. Den lista er ei utsegn om hjelparar, ikkje eit løfte om at kvar protokoll eller autentiseringsflyt vil virke. Les ho som ein meny over kva som må kontrollerast, ikkje som ein kompatibilitetsgaranti.

Deretter må du matche integrasjonen mot den godkjende protokollen til gatewayen. Ordet Cisco fortel deg ikkje om du treng ei gammaldags vpnc-tilkopling eller ein AnyConnect-kompatibel flyt, og feil val gir ein autentiseringsfeil som ser ut som eit legitimasjonsproblem.

Viss både ein frittståande hjelpar og ConnMan kan reise tunnelen, avgjer kven som eig rutene, DNS og livssyklusen før nokon av dei startar.

Daemoninnstillingar er ikkje leverandørinnstillingar

Den generelle konfigurasjonen til daemonen og konfigurasjonen til ein enkelt leverandør er ulike filer med ulike format. I det dokumenterte bookworm-oppsettet les daemonen /etc/connman/connman-vpn.conf, medan klargjeringsfilene til leverandørane ligg under /var/lib/connman-vpn/ med eit .config-suffiks. Å leggje ein OpenVPN-profil i den mappa gjer han ikkje til ei ConnMan-klargjeringsfil. Den versjonsbundne leverandørhandboka skildrar leverandørseksjonane og dei typspesifikke felta som desse filene faktisk treng.

Set om berre gjennom den støtta mapperinga til den installerte integrasjonen. Sertifikattillit, referansar til privat nøkkel, gateway-identitet, ruter og autentiseringsinndata held kvar sin rolle, og eit døme for ein annan leverandørtype er ikkje utskiftbart berre fordi begge treng ei tenaradresse.

Når ein leverandør ikkje lastar, samanlikn felta med handboka for den installerte utgåva i staden for med eit bloggdøme.

Autentiseringsagenten er ein eigen avhengnad

Ein leverandørdefinisjon kan framleis trenge ein agent for å hente legitimasjon eller fullføre ein autentiseringsutveksling. For OpenConnect-integrasjonen sin forklarer same handboka at manglande autentiseringsrelaterte verdiar kan bli etterspurde gjennom VPN Agent API, og at ein kortliva cookie generelt ikkje eignar seg som ein permanent konfigurasjonsløyndom. Den mekanismen garanterer ikkje støtte for kvar nettlesarinnlogging, MFA-førespurnad eller gateway-tilstandssjekk. Stadfest heile flyten med den som eig utrullinga.

Ikkje kompenser for ein manglande agent ved å skrive eit passord eller ein sesjonstoken i ei breitt lesbar fil. Det gjer ein manglande integrasjon om til ei eksponering av legitimasjon, og det andre problemet overlever det første.

Viss gatewayen krev ei interaktiv innlogging, er agenten ein del av designet og ikkje eit valfritt tillegg.

Stadfest fire resultat, ikkje eitt

Etter autorisert klargjering, kontroller fire ting kvar for seg: leverandøren er vald, tilkoplinga er autentisert, dei effektive rutene er dei du hadde tenkt, og resolvarten oppfører seg som venta. Ein køyrande daemon, ein oppført leverandør og eit program som når ressursen sin er tre ulike resultat, og berre det siste er det faktiske målet til brukaren. Å registrere dei kvar for seg fortel deg kva trinn som skal rettast.

Ta med gjenoppkoplingåtferd og den påkravde politikken for utilgjengeleg tilstand i den kontrollen, fordi ein tunnel som reiser seg éin gong og aldri kjem tilbake, ikkje er rulle ut. Hald den fungerande basisnettverkskonfigurasjonen gjenopprettbar medan du endrar VPN-integrasjonen.

Å bytte ut Wi-Fi-handsamaren for å få ein knapp er ei mykje større endring enn den manglande operasjonen som var nødvendig, og det er vanlegvis myten som vinn.