ConnMan VPN: el menú que falta és un dimoni, no un protocol

La creença és que un sistema ConnMan sense cap entrada VPN a l'escriptori no té cap suport VPN instal·lat. Normalment té suport per a Wi-Fi i cap per al dimoni VPN, la configuració del proveïdor o l'agent d'autenticació, i aquestes són tres absències separades. El menú és una vista sobre aquests components, no la funcionalitat en si. Comprovar la versió i l'empaquetament us diu més en una ordre que qualsevol nombre d'informes d'error d'escriptori.

El mite: el menú és la funcionalitat VPN

Comenceu per la versió instal·lada de ConnMan i els paquets que hi venien. Un informe d'error d'una versió anterior descriu un conjunt de funcions diferent, i citar-lo sol acabar amb algú reinstal·lant un gestor de xarxa que no calia substituir.

Anoteu què teniu realment abans de canviar res: el binari del dimoni, el directori de proveïdors i si hi ha un agent.

Quin dimoni posseeix el túnel

A la documentació de ConnMan 1.41 de Debian bookworm, connman-vpnd és el dimoni que gestiona les connexions VPN al costat de connmand. Enumera integracions per a auxiliars VPN amb nom, incloent-hi OpenVPN i OpenConnect. Aquesta llista és una afirmació sobre els auxiliars, no una promesa que tots els protocols o fluxos d'autenticació funcionaran. Llegiu-la com un menú del que cal comprovar, no com una garantia de compatibilitat.

Després feu coincidir la integració amb el protocol aprovat de la passarel·la. La paraula Cisco no us diu si necessiteu una connexió de l'estil vpnc antic o un flux compatible amb AnyConnect, i triar malament produeix un error d'autenticació que sembla un problema de credencials.

Si tant un auxiliar independent com ConnMan poden aixecar el túnel, decidiu quin és el propietari de les rutes, el DNS i el cicle de vida abans que cap dels dos arrenqui.

La configuració del dimoni no és la configuració del proveïdor

La configuració general del dimoni i la configuració d'un proveïdor concret són fitxers diferents amb formats diferents. En la disposició documentada de bookworm el dimoni llegeix /etc/connman/connman-vpn.conf, mentre que els fitxers de subministrament de proveïdors viuen a /var/lib/connman-vpn/ amb un sufix .config. Deixar un perfil OpenVPN en aquest directori no el converteix en un fitxer de subministrament de ConnMan. El manual del proveïdor per a aquesta versió descriu les seccions del proveïdor i els camps específics de tipus que aquests fitxers necessiten realment.

Traduïu només a través del mapatge suportat per la integració instal·lada. La confiança en el certificat, les referències a la clau privada, la identitat de la passarel·la, les rutes i les entrades d'autenticació conserven cadascuna el seu paper, i una mostra d'un altre tipus de proveïdor no és intercanviable només perquè tots dos necessitin una adreça de servidor.

Quan un proveïdor no es carrega, compareu-ne els camps amb el manual de la versió instal·lada i no amb un exemple d'un blog.

L'agent d'autenticació és una dependència separada

Una definició de proveïdor encara pot necessitar un agent per obtenir credencials o acabar un intercanvi d'autenticació. Per a la seva integració amb OpenConnect, el mateix manual explica que els valors relacionats amb l'autenticació que falten es poden sol·licitar mitjançant l'API del VPN Agent, i que una galeta de curta durada generalment no serveix com a secret permanent de configuració. Aquest mecanisme no garanteix suport per a cada inici de sessió al navegador, cada sol·licitud MFA o cada comprovació de postura de la passarel·la. Confirmeu tot el flux amb qui sigui propietari del desplegament.

No compenseu un agent absent escrivint una contrasenya o un testimoni de sessió en un fitxer àmpliament llegible. Això converteix una integració absent en una exposició de credencials, i el segon problema sobreviu al primer.

Si la passarel·la necessita un inici de sessió interactiu, l'agent forma part del disseny i no és un extra opcional.

Verifiqueu quatre resultats, no un

Després d'un subministrament autoritzat, comproveu quatre coses per separat: el proveïdor està seleccionat, la connexió s'ha autenticat, les rutes efectives són les que volíeu i el resolutor es comporta com s'esperava. Un dimoni en marxa, un proveïdor llistat i una aplicació que arriba al seu recurs són tres resultats diferents, i només l'últim és l'objectiu real de l'usuari. Enregistrar-los per separat us diu quina etapa cal corregir.

Incloeu en aquesta comprovació el comportament de reconnexió i la política d'estat no disponible requerida, perquè un túnel que s'aixeca una vegada i mai no es recupera no està desplegat. Manteniu recuperable la configuració de xarxa base que funciona mentre canvieu la integració VPN.

Substituir el gestor de Wi-Fi per obtenir un botó és un canvi molt més gran que l'operació que faltava, i normalment és el mite guanyant.