ConnMan VPN: Den saknade menyn är en daemon, inte ett protokoll

Föreställningen är att ett ConnMan-system utan VPN-post på skrivbordet inte har något VPN-stöd installerat. Oftast finns stöd för Wi-Fi och inget för VPN-daemonen, leverantörskonfigurationen eller autentiseringsagenten, och det är tre separata frånvaro. Menyn är en vy över dessa komponenter, inte funktionen själv. Kontrollera versionen och paketeringen berättar mer för dig med ett enda kommando än vilket antal felrapporter från skrivbordet som helst.

Myten: menyn är VPN-funktionen

Börja med den installerade ConnMan-versionen och paketen som följde med den. En felrapport från en äldre utgåva beskriver en annan funktionsuppsättning, och att citera den slutar oftast med att någon installerar om en nätverkshanterare som inte behövde bytas ut.

Skriv ner vad du faktiskt har innan du ändrar något: daemonens binärfil, leverantörskatalogen och om det finns en agent.

Vilken daemon som äger tunneln

I ConnMan 1.41-dokumentationen för Debian bookworm är connman-vpnd daemonen som hanterar VPN-anslutningar vid sidan av connmand. Den listar integrationer för namngivna VPN-hjälpare, inklusive OpenVPN och OpenConnect. Listan är ett påstående om hjälpare, inte ett löfte om att varje protokoll eller autentiseringsflöde kommer att fungera. Läs den som en meny över vad som ska kontrolleras, inte som en kompatibilitetsgaranti.

Matcha sedan integrationen mot gatewayens godkända protokoll. Ordet Cisco säger dig inte om du behöver en gammaldags vpnc-anslutning eller ett AnyConnect-kompatibelt flöde, och fel val ger ett autentiseringsfel som ser ut som ett problem med inloggningsuppgifterna.

Om både en fristående hjälpare och ConnMan kan resa tunneln, bestäm vem som äger rutter, DNS och livscykel innan någon av dem startar.

Daemoninställningar är inte leverantörsinställningar

Daemonens allmänna konfiguration och en enskild leverantörs konfiguration är olika filer med olika format. I den dokumenterade bookworm-ordningen läser daemonen /etc/connman/connman-vpn.conf, medan leverantörernas etableringsfiler ligger under /var/lib/connman-vpn/ med suffixet .config. Att lägga en OpenVPN-profil i den katalogen gör den inte till en ConnMan-etableringsfil. Den versionsbundna leverantörshandboken beskriver leverantörsavsnitten och de typspecifika fälten som dessa filer faktiskt behöver.

Översätt bara genom den installerade integrationens stödda mappning. Certifikattillit, referenser till den privata nyckeln, gateway-identitet, rutter och autentiseringsindata behåller var och en sin roll, och ett exempel för en annan leverantörstyp är inte utbytbart bara för att båda behöver en serveradress.

När en leverantör inte laddas, jämför dess fält med handboken för den installerade utgåvan i stället för med ett bloggexempel.

Autentiseringsagenten är ett separat beroende

En leverantörsdefinition kan fortfarande behöva en agent för att hämta inloggningsuppgifter eller slutföra ett autentiseringsutbyte. För sin OpenConnect-integration förklarar samma handbok att saknade autentiseringsrelaterade värden kan begäras via VPN Agent API, och att en kortlivad cookie i allmänhet inte lämpar sig som en permanent konfigurationshemlighet. Den mekanismen garanterar inte stöd för varje webbläsarinloggning, MFA-förfrågan eller gateway-tillståndskontroll. Bekräfta hela flödet med den som äger driftsättningen.

Kompensera inte en saknad agent genom att skriva ett lösenord eller en sessionstoken i en brett läsbar fil. Det gör en saknad integration till en exponering av inloggningsuppgifter, och det andra problemet överlever det första.

Om gatewayen kräver en interaktiv inloggning är agenten en del av designen och inte ett valfritt tillägg.

Verifiera fyra resultat, inte ett

Efter etablering med behörighet, kontrollera fyra saker separat: leverantören är vald, anslutningen är autentiserad, de effektiva rutterna är de du avsåg, och resolvern beter sig som förväntat. En körande daemon, en listad leverantör och ett program som når sin resurs är tre olika resultat, och bara det sista är användarens faktiska mål. Att registrera dem separat talar om vilket steg som ska åtgärdas.

Ta med återanslutningsbeteende och den krävda policyn för otillgängligt tillstånd i den kontrollen, eftersom en tunnel som reser sig en gång och aldrig återhämtar sig inte är driftsatt. Håll den fungerande basnätverkskonfigurationen återställbar medan du ändrar VPN-integrationen.

Att byta ut Wi-Fi-hanteraren för att få en knapp är en mycket större förändring än den saknade åtgärden som krävdes, och oftast är det myten som vinner.