ConnMan VPN: o menú que falta é un daemon, non un protocolo

A crenza é que un sistema ConnMan sen entrada VPN no escritorio non ten instalado ningún soporte VPN. Normalmente ten soporte para Wi-Fi e ningún para o daemon VPN, a configuración do provedor ou o axente de autenticación, e esas son tres ausencias separadas. O menú é unha vista deses compoñentes, non a función en si. Comprobar a versión e a empaquetaxe diche máis cun só comando que calquera número de informes de erro do escritorio.

O mito: o menú é a función VPN

Comece pola versión instalada de ConnMan e os paquetes que a acompañaron. Un informe de erro dunha versión anterior describe un conxunto de funcións distinto, e citalo adoita rematar con alguén reinstalando un xestor de rede que non necesitaba substituír.

Anote o que realmente ten antes de cambiar nada: o binario do daemon, o directorio de provedores e se hai un axente presente.

Que daemon posúe o túnel

Na documentación de ConnMan 1.41 para Debian bookworm, connman-vpnd é o daemon que xestiona as conexións VPN xunto a connmand. Enumera integracións para asistentes VPN con nome, incluídos OpenVPN e OpenConnect. Esa lista é unha afirmación sobre os asistentes, non unha promesa de que vaia funcionar cada protocolo ou fluxo de autenticación. Lína como un menú do que hai que comprobar, non como unha garantía de compatibilidade.

Despois emparexe a integración co protocolo aprobado da pasarela. A palabra Cisco non lle di se necesita unha conexión ao estilo vpnc antigo ou un fluxo compatible con AnyConnect, e escoller mal produce un fallo de autenticación que parece un problema de credenciais.

Se tanto un asistente independente como ConnMan poden levantar o túnel, decida cal é dono das rutas, do DNS e do ciclo de vida antes de que arranque calquera dos dous.

A configuración do daemon non é a configuración do provedor

A configuración xeral do daemon e a configuración dun provedor concreto son ficheiros distintos con formatos distintos. Na disposición documentada de bookworm o daemon le /etc/connman/connman-vpn.conf, mentres que os ficheiros de aprovisionamento de provedores viven en /var/lib/connman-vpn/ cun sufixo .config. Deixar un perfil OpenVPN nese directorio non o converte nun ficheiro de aprovisionamento de ConnMan. O manual do provedor para esta versión describe as seccións do provedor e os campos específicos de tipo que eses ficheiros necesitan realmente.

Traduza só mediante a mapaxe compatible da integración instalada. A confianza no certificado, as referencias á clave privada, a identidade da pasarela, as rutas e as entradas de autenticación conservan cada unha o seu papel, e unha mostra doutro tipo de provedor non é intercambiable só porque ambos necesiten un enderezo de servidor.

Cando un provedor non se cargue, compare os seus campos co manual da versión instalada e non cun exemplo dun blog.

O axente de autenticación é unha dependencia aparte

Unha definición de provedor aínda pode necesitar un axente para obter credenciais ou rematar un intercambio de autenticación. Para a súa integración con OpenConnect, o mesmo manual explica que os valores relacionados coa autenticación que faltan se poden solicitar mediante a API do VPN Agent, e que unha cookie de curta duración xeralmente non serve como segredo permanente de configuración. Ese mecanismo non garante compatibilidade con cada inicio de sesión do navegador, cada solicitude MFA ou cada comprobación de postura da pasarela. Confirme o fluxo completo con quen sexa dono do despregamento.

Non compense un axente ausente escribindo un contrasinal ou un testemuño de sesión nun ficheiro amplamente lexible. Iso converte unha integración ausente nunha exposición de credenciais, e o segundo problema sobrevive ao primeiro.

Se a pasarela necesita un inicio de sesión interactivo, o axente forma parte do deseño e non é un extra opcional.

Verifique catro resultados, non un

Tras un aprovisionamento autorizado, comprobe catro cousas por separado: o provedor está seleccionado, a conexión autenticouse, as rutas efectivas son as que pretendía e o resolvedor compórtase como se esperaba. Un daemon en marcha, un provedor listado e unha aplicación que acada o seu recurso son tres resultados distintos, e só o último é o obxectivo real do usuario. Rexistralos por separado diche que etapa corrixir.

Inclúa nesa comprobación o comportamento de reconexión e a política de estado non dispoñible requirida, porque un túnel que se levanta unha vez e nunca se recupera non está despregado. Manteña recuperable a configuración de rede base que funciona mentres cambia a integración VPN.

Substituír o xestor de Wi-Fi para obter un botón é un cambio moito maior ca a operación que faltaba, e normalmente é o mito gañando.