ConnMan VPN: Het ontbrekende menu is een daemon, geen protocol

De overtuiging is dat een ConnMan-systeem zonder VPN-item op de desktop geen VPN-ondersteuning geïnstalleerd heeft. Meestal is er ondersteuning voor Wi-Fi en geen voor de VPN-daemon, de providerconfiguratie of de authenticatieagent, en dat zijn drie afzonderlijke afwezigheden. Het menu is een weergave van die componenten, niet de functie zelf. De versie en de packaging controleren vertelt je met één commando meer dan welk aantal bugmeldingen van de desktop dan ook.

De mythe: het menu is de VPN-functie

Begin met de geïnstalleerde ConnMan-versie en de pakketten die daarmee meekwamen. Een bugmelding uit een oudere release beschrijft een andere functieset, en die citeren eindigt meestal met iemand die een netwerkbeheerder herinstalleert die niet vervangen hoefde te worden.

Schrijf op wat je werkelijk hebt voordat je iets verandert: het binaire bestand van de daemon, de providermap en of er een agent aanwezig is.

Welke daemon de tunnel bezit

In de ConnMan 1.41-documentatie voor Debian bookworm is connman-vpnd de daemon die VPN-verbindingen naast connmand beheert. Hij noemt integraties voor benoemde VPN-helpers, waaronder OpenVPN en OpenConnect. Die lijst is een uitspraak over helpers, geen belofte dat elk protocol of elke authenticatiestroom werkt. Lees hem als een menu van wat je moet controleren, niet als een compatibiliteitsgarantie.

Koppel daarna de integratie aan het goedgekeurde protocol van de gateway. Het woord Cisco zegt je niet of je een ouderwetse vpnc-verbinding nodig hebt of een AnyConnect-compatibele stroom, en de verkeerde keuze levert een authenticatiefout op die op een inloggegevensprobleem lijkt.

Als zowel een zelfstandige helper als ConnMan de tunnel kunnen opzetten, bepaal dan vóór een van beide begint wie de routes, DNS en levenscyclus bezit.

Daemoninstellingen zijn geen providerinstellingen

De algemene configuratie van de daemon en de configuratie van een individuele provider zijn verschillende bestanden met verschillende formaten. In de gedocumenteerde bookworm-indeling leest de daemon /etc/connman/connman-vpn.conf, terwijl provider-provisioningbestanden onder /var/lib/connman-vpn/ staan met een .config-suffix. Een OpenVPN-profiel in die map zetten maakt er geen ConnMan-provisioningbestand van. De versiegebonden providerhandleiding beschrijft de providersecties en de typespecifieke velden die die bestanden echt nodig hebben.

Vertaal alleen via de ondersteunde mapping van de geïnstalleerde integratie. Certificaatvertrouwen, verwijzingen naar de privésleutel, gateway-identiteit, routes en authenticatie-invoer behouden elk hun eigen rol, en een voorbeeld voor een ander providertype is niet uitwisselbaar alleen omdat beide een serveradres nodig hebben.

Als een provider niet laadt, vergelijk de velden dan met de handleiding voor de geïnstalleerde release in plaats van met een blogvoorbeeld.

De authenticatieagent is een aparte afhankelijkheid

Een providerdefinitie kan nog steeds een agent nodig hebben om inloggegevens te verkrijgen of een authenticatie-uitwisseling af te ronden. Voor de OpenConnect-integratie legt dezelfde handleiding uit dat ontbrekende authenticatiegerelateerde waarden via de VPN Agent API kunnen worden opgevraagd, en dat een kortlevende cookie over het algemeen niet geschikt is als permanent configuratiegeheim. Dat mechanisme garandeert geen ondersteuning voor elke browserlogin, MFA-aanvraag of gateway-posturecontrole. Bevestig de hele stroom met wie de uitrol bezit.

Compenseer een ontbrekende agent niet door een wachtwoord of sessietoken in een breed leesbaar bestand te schrijven. Dat maakt van een ontbrekende integratie een blootstelling van inloggegevens, en het tweede probleem overleeft het eerste.

Als de gateway een interactieve login vereist, is de agent deel van het ontwerp en geen optionele toevoeging.

Verifieer vier uitkomsten, niet één

Controleer na geautoriseerde provisioning vier dingen afzonderlijk: de provider is geselecteerd, de verbinding is geauthenticeerd, de effectieve routes zijn de routes die je bedoelde, en de resolver gedraagt zich zoals verwacht. Een draaiende daemon, een vermelde provider en een applicatie die haar resource bereikt zijn drie verschillende uitkomsten, en alleen de laatste is het werkelijke doel van de gebruiker. Ze afzonderlijk vastleggen vertelt je welke fase je moet repareren.

Neem het herverbindingsgedrag en het vereiste beleid voor de niet-beschikbare toestand op in die controle, want een tunnel die één keer omhoog komt en nooit herstelt, is niet uitgerold. Houd de werkende basisnetwerkconfiguratie herstelbaar terwijl je de VPN-integratie wijzigt.

De Wi-Fi-beheerder vervangen om een knop te krijgen is een veel grotere wijziging dan de ontbrekende handeling die nodig was, en meestal wint de mythe.