ConnMan VPN: Den manglende menyen er en daemon, ikke en protokoll

Forestillingen er at et ConnMan-system uten VPN-oppføring på skrivebordet ikke har VPN-støtte installert. Vanligvis har det støtte for Wi-Fi og ingen for VPN-daemonen, leverandørkonfigurasjonen eller autentiseringsagenten, og det er tre separate fravær. Menyen er en visning av disse komponentene, ikke funksjonen selv. Kontrollere versjonen og pakkingen forteller deg mer med én kommando enn noe antall feilrapporter fra skrivebordet.

Myten: menyen er VPN-funksjonen

Start med den installerte ConnMan-versjonen og pakkene som fulgte med den. En feilrapport fra en eldre utgivelse beskriver et annet funksjonssett, og å sitere den ender vanligvis med at noen reinstallerer en nettverksbehandler de ikke trengte å bytte ut.

Skriv ned hva du faktisk har før du endrer noe: daemonens binære fil, leverandørmappen og om det finnes en agent.

Hvilken daemon som eier tunnelen

I ConnMan 1.41-dokumentasjonen for Debian bookworm er connman-vpnd daemonen som administrerer VPN-tilkoblinger ved siden av connmand. Den lister opp integrasjoner for navngitte VPN-hjelpere, inkludert OpenVPN og OpenConnect. Den listen er en uttalelse om hjelpere, ikke et løfte om at hver protokoll eller autentiseringsflyt vil fungere. Les den som en meny over hva som må kontrolleres, ikke som en kompatibilitetsgaranti.

Deretter må du matche integrasjonen mot gatewayens godkjente protokoll. Ordet Cisco forteller deg ikke om du trenger en gammeldags vpnc-tilkobling eller en AnyConnect-kompatibel flyt, og feil valg gir en autentiseringsfeil som ser ut som et legitimasjonsproblem.

Hvis både en frittstående hjelper og ConnMan kan reise tunnelen, avgjør hvem som eier ruter, DNS og livssyklus før noen av dem starter.

Daemoninnstillinger er ikke leverandørinnstillinger

Daemonens generelle konfigurasjon og en enkelt leverandørs konfigurasjon er forskjellige filer med forskjellige formater. I det dokumenterte bookworm-oppsettet leser daemonen /etc/connman/connman-vpn.conf, mens leverandørenes klargjøringsfiler ligger under /var/lib/connman-vpn/ med et .config-suffiks. Å legge en OpenVPN-profil i den mappen gjør den ikke til en ConnMan-klargjøringsfil. Den versjonsbundne leverandørhåndboken beskriver leverandørseksjonene og de typspesifikke feltene som disse filene faktisk trenger.

Oversett bare gjennom den installerte integrasjonens støttede mapping. Sertifikattillit, referanser til privat nøkkel, gateway-identitet, ruter og autentiseringsinndata beholder hver sin rolle, og et eksempel for en annen leverandørtype er ikke utskiftbart bare fordi begge trenger en serveradresse.

Når en leverandør ikke lastes, sammenlign feltene med håndboken for den installerte utgivelsen i stedet for med et bloggeksempel.

Autentiseringsagenten er en egen avhengighet

En leverandørdefinisjon kan fortsatt trenge en agent for å hente legitimasjon eller fullføre en autentiseringsutveksling. For sin OpenConnect-integrasjon forklarer samme håndbok at manglende autentiseringsrelaterte verdier kan forespørres gjennom VPN Agent API, og at en kortlevd cookie generelt ikke egner seg som en permanent konfigurasjonshemmelighet. Den mekanismen garanterer ikke støtte for hver nettleserinnlogging, MFA-forespørsel eller gateway-tilstandssjekk. Bekreft hele flyten med den som eier utrullingen.

Ikke kompenser for en manglende agent ved å skrive et passord eller en sesjonstoken i en bredt lesbar fil. Det gjør en manglende integrasjon om til en eksponering av legitimasjon, og det andre problemet overlever det første.

Hvis gatewayen krever en interaktiv innlogging, er agenten en del av designet og ikke et valgfritt ekstra.

Bekreft fire resultater, ikke ett

Etter autorisert klargjøring, kontroller fire ting hver for seg: leverandøren er valgt, tilkoblingen er autentisert, de effektive rutene er de du hadde tenkt, og resolvertjenesten oppfører seg som forventet. En kjørende daemon, en oppført leverandør og et program som når ressursen sin er tre forskjellige resultater, og bare det siste er brukerens faktiske mål. Å registrere dem hver for seg forteller deg hvilket trinn som skal rettes.

Ta med gjenoppkoblingsatferd og den påkrevde politikken for utilgjengelig tilstand i den kontrollen, fordi en tunnel som reiser seg én gang og aldri kommer tilbake, ikke er rullet ut. Hold den fungerende basisnettverkskonfigurasjonen gjenopprettbar mens du endrer VPN-integrasjonen.

Å bytte ut Wi-Fi-behandleren for å få en knapp er en mye større endring enn den manglende operasjonen som var nødvendig, og det er vanligvis myten som vinner.