La caducidad de la cookie de ConnMan OpenConnect, no un problema de certificado
Dos fallos se ven iguales en el registro. Compare la huella fijada con la cookie de sesión, renueve el campo que caducó y luego reinicie el demonio.
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.
| Signal | Expired cookie | Changed certificate |
|---|---|---|
| When it started | after hours or days of working | right after a gateway change |
| Fingerprint from a fresh authenticate | unchanged | different value |
| Usual log tail | HTTP CONNECT 401 / unauthorized | signer not found / verify failed |
| Repair | replace the cookie, restart | re-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.comLa 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 attemptQué 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.