ConnMan funciona toda una tarde y luego rechaza, y la línea del registro menciona la verificación del certificado. Esa línea manda a la gente a paquetes de CA que nunca estuvieron rotos. Dos fallos distintos producen casi la misma forma de fallo: la cookie de sesión caduca, o el certificado del servidor cambió de verdad. Se pueden separar en alrededor de un minuto, y solo uno de ellos tiene que ver con la huella.

Dos fallos, una línea de registro confusa

Se separan con dos observaciones, y ninguna de las dos requiere una segunda lectura. La primera es cuándo empezó el fallo: una cookie caducada llega tras horas o días de funcionamiento, y un certificado sustituido llega justo después de un cambio de puerta de enlace.

SignalExpired cookieChanged certificate
When it startedafter hours or days of workingright after a gateway change
Fingerprint from a fresh authenticateunchangeddifferent value
Usual log tailHTTP CONNECT 401 / unauthorizedsigner not found / verify failed
Repairreplace the cookie, restartre-pin deliberately, then restart

La prueba de un minuto es la ejecución de authenticate de abajo. Compare su FINGERPRINT con OpenConnect.ServerCert en el archivo. Una huella idéntica con una COOKIE distinta significa sustituir solo la cookie. Una huella distinta significa que el certificado del servidor cambió de verdad, así que vuelva a fijarlo a propósito y anote quién lo aprobó.

Genere el material en lugar de escribirlo

ConnMan no tiene un paso de importación para un perfil de OpenConnect, a diferencia de NetworkManager. Lee un archivo de aprovisionamiento cuyos valores deben producirse de antemano, y la forma admitida de producirlos es el modo authenticate de OpenConnect.

sudo openconnect --csd-wrapper=/home/user/.cisco/csd-wrapper.sh \
  --authenticate --user myuser vpn.example.com

La salida imprime cuatro valores: POST, COOKIE, HOST y FINGERPRINT. La huella, con el prefijo sha256:, es la fijación del servidor. La cookie es el artefacto de sesión con una vida útil que decide la puerta de enlace. Trátelos como tipos distintos de secreto: caducan según calendarios distintos, y solo se espera que cambie uno.

El archivo lleva ambos, y envejecen de forma distinta

El archivo de aprovisionamiento vive en /var/lib/connman-vpn/ y lo lee por conexión el demonio de VPN, no el applet de la bandeja. Mantenga el nombre de la conexión en la sección global y los detalles del protocolo en la sección del proveedor.

[global]
Name = Company VPN

[provider_openconnect]
Type = OpenConnect
Name = Company Cisco VPN
Host = vpn.example.com
Domain = corp.example
OpenConnect.ServerCert = sha256:...
OpenConnect.Cookie = ...

Use el nombre de host que el portal sirve realmente. Una dirección IP desnuda puede pasar la comprobación del certificado y aun así fallar, porque el dispositivo enruta por el host virtual y espera el nombre.

systemctl status connman-vpn --no-pager   # is the daemon even installed and running
sudo systemctl restart connman-vpn       # after the file edit
journalctl -u connman-vpn --since '1 hour ago'  # after the connection attempt

Qué muestra realmente el registro

La información emergente de la bandeja no dirá qué fallo tiene. El registro sí, si lee la secuencia en lugar de la primera línea alarmante. Una cookie vieja suele mostrar que la negociación TLS se completó y que la capa HTTP rechaza después, y por eso las palabras sobre certificados aparecen junto a un fallo de autorización.

Compare una ejecución de authenticate nueva con los valores del archivo. Si la huella coincide y solo difiere la cookie, ya tiene su respuesta sin tocar los ajustes de confianza.

Renueve el campo que caducó

Repita el comando authenticate, sustituya OpenConnect.Cookie y reinicie el demonio. Deje la huella en paz salvo que la salida nueva muestre un valor distinto; en ese caso el certificado del servidor se sustituyó de verdad y volver a fijarlo es una decisión que alguien debe registrar, no un pegado de un mensaje de error.

Automatizar la renovación es razonable: un script pequeño lee la contraseña de la entrada estándar, ejecuta el modo authenticate y reescribe solo la línea de la cookie. Mantenga la credencial fuera del script y legible solo por la cuenta que lo ejecuta, y haga la reescritura atómica para que una ejecución fallida no deje un archivo a medio escribir.

Si la renovación hace falta cada pocas horas, anote el intervalo. Es una propiedad de la política de sesiones de la puerta de enlace, y decide si conviene automatizar la renovación o pedir una sesión más larga.

Artículos relacionados