ConnMan VPN: el menú que falta es un demonio, no un protocolo

La creencia es que un sistema ConnMan sin entrada VPN en el escritorio no tiene instalado ningún soporte VPN. Normalmente tiene soporte para Wi-Fi y ninguno para el demonio VPN, la configuración del proveedor o el agente de autenticación, y esas son tres ausencias separadas. El menú es una vista de esos componentes, no la función en sí. Comprobar la versión y el empaquetado le dice más con un solo comando que cualquier número de informes de error del escritorio.

El mito: el menú es la función VPN

Empiece por la versión instalada de ConnMan y los paquetes que la acompañaron. Un informe de error de una versión anterior describe un conjunto de funciones distinto, y citarlo suele terminar con alguien reinstalando un gestor de red que no necesitaba sustituir.

Anote lo que realmente tiene antes de cambiar nada: el binario del demonio, el directorio de proveedores y si hay un agente presente.

Qué demonio posee el túnel

En la documentación de ConnMan 1.41 para Debian bookworm, connman-vpnd es el demonio que gestiona las conexiones VPN junto a connmand. Enumera integraciones para asistentes VPN con nombre, incluidos OpenVPN y OpenConnect. Esa lista es una afirmación sobre los asistentes, no una promesa de que vaya a funcionar cada protocolo o flujo de autenticación. Léala como un menú de lo que hay que comprobar, no como una garantía de compatibilidad.

Después empareje la integración con el protocolo aprobado de la pasarela. La palabra Cisco no le dice si necesita una conexión al estilo vpnc antiguo o un flujo compatible con AnyConnect, y elegir mal produce un fallo de autenticación que parece un problema de credenciales.

Si tanto un asistente independiente como ConnMan pueden levantar el túnel, decida cuál es dueño de las rutas, el DNS y el ciclo de vida antes de que arranque cualquiera de los dos.

La configuración del demonio no es la configuración del proveedor

La configuración general del demonio y la configuración de un proveedor concreto son archivos distintos con formatos distintos. En la disposición documentada de bookworm el demonio lee /etc/connman/connman-vpn.conf, mientras que los archivos de aprovisionamiento de proveedores viven en /var/lib/connman-vpn/ con un sufijo .config. Dejar un perfil OpenVPN en ese directorio no lo convierte en un archivo de aprovisionamiento de ConnMan. El manual del proveedor para esta versión describe las secciones del proveedor y los campos específicos de tipo que esos archivos necesitan realmente.

Traduzca solo mediante el mapeo compatible de la integración instalada. La confianza en el certificado, las referencias a la clave privada, la identidad de la pasarela, las rutas y las entradas de autenticación conservan cada una su papel, y una muestra de otro tipo de proveedor no es intercambiable solo porque ambos necesiten una dirección de servidor.

Cuando un proveedor no se cargue, compare sus campos con el manual de la versión instalada y no con un ejemplo de un blog.

El agente de autenticación es una dependencia aparte

Una definición de proveedor todavía puede necesitar un agente para obtener credenciales o terminar un intercambio de autenticación. Para su integración con OpenConnect, el mismo manual explica que los valores relacionados con la autenticación que faltan se pueden solicitar mediante la API del VPN Agent, y que una cookie de corta duración generalmente no sirve como secreto permanente de configuración. Ese mecanismo no garantiza compatibilidad con cada inicio de sesión del navegador, cada solicitud MFA o cada comprobación de postura de la pasarela. Confirme el flujo completo con quien sea dueño del despliegue.

No compense un agente ausente escribiendo una contraseña o un testigo de sesión en un archivo ampliamente legible. Eso convierte una integración ausente en una exposición de credenciales, y el segundo problema sobrevive al primero.

Si la pasarela necesita un inicio de sesión interactivo, el agente forma parte del diseño y no es un extra opcional.

Verifique cuatro resultados, no uno

Tras un aprovisionamiento autorizado, compruebe cuatro cosas por separado: el proveedor está seleccionado, la conexión se ha autenticado, las rutas efectivas son las que pretendía y el resolutor se comporta como se esperaba. Un demonio en marcha, un proveedor listado y una aplicación que alcanza su recurso son tres resultados distintos, y solo el último es el objetivo real del usuario. Registrarlos por separado le dice qué etapa corregir.

Incluya en esa comprobación el comportamiento de reconexión y la política de estado no disponible requerida, porque un túnel que se levanta una vez y nunca se recupera no está desplegado. Mantenga recuperable la configuración de red base que funciona mientras cambia la integración VPN.

Sustituir el gestor de Wi-Fi para obtener un botón es un cambio mucho mayor que la operación que faltaba, y normalmente es el mito ganando.