La scadenza del cookie di ConnMan OpenConnect, non un problema di certificato
Due guasti sembrano uguali nel registro. Confrontate l'impronta fissata con il cookie di sessione, rinnovate il campo scaduto e poi riavviate il demone.
ConnMan funziona un pomeriggio e poi rifiuta, e la riga del registro menziona la verifica del certificato. Quella riga manda le persone verso bundle CA che non erano mai stati rotti. Due guasti diversi producono quasi la stessa forma di errore: il cookie di sessione scade, oppure il certificato del server è davvero cambiato. Si separano in circa un minuto, e solo uno dei due riguarda l'impronta.
Due guasti, una riga di registro confusa
Si separano su due osservazioni, e nessuna delle due richiede una seconda lettura. La prima è quando è iniziato il guasto: un cookie scaduto arriva dopo ore o giorni di funzionamento, e un certificato sostituito arriva subito dopo un cambio di gateway.
| 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 |
Il test di un minuto è l'esecuzione di authenticate qui sotto. Confrontate il suo FINGERPRINT con OpenConnect.ServerCert nel file. Un'impronta identica con un COOKIE diverso significa sostituire solo il cookie. Un'impronta diversa significa che il certificato del server è davvero cambiato, quindi rifissatelo di proposito e annotate chi lo ha approvato.
Generate il materiale invece di digitarlo
ConnMan non ha un passaggio di importazione per un profilo OpenConnect, a differenza di NetworkManager. Legge un file di provisioning i cui valori devono essere prodotti in anticipo, e il modo supportato per produrli è la modalità authenticate di OpenConnect.
sudo openconnect --csd-wrapper=/home/user/.cisco/csd-wrapper.sh \
--authenticate --user myuser vpn.example.comL'output stampa quattro valori: POST, COOKIE, HOST e FINGERPRINT. L'impronta, con il prefisso sha256:, è il fissaggio del server. Il cookie è l'artefatto di sessione con una durata decisa dal gateway. Trattateli come tipi diversi di segreto: scadono secondo calendari diversi, e solo uno dovrebbe cambiare.
Il file porta entrambi, e invecchiano in modo diverso
Il file di provisioning vive sotto /var/lib/connman-vpn/ ed è letto per connessione dal demone VPN, non dall'applet della barra. Tenete il nome della connessione nella sezione globale e i dettagli del protocollo nella sezione del provider.
[global]
Name = Company VPN
[provider_openconnect]
Type = OpenConnect
Name = Company Cisco VPN
Host = vpn.example.com
Domain = corp.example
OpenConnect.ServerCert = sha256:...
OpenConnect.Cookie = ...Usate il nome host che il portale serve davvero. Un indirizzo IP nudo può superare il controllo del certificato e fallire comunque, perché l'apparecchio instrada sull'host virtuale e si aspetta il nome.
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 attemptCosa mostra davvero il registro
Il suggerimento della barra non dirà quale guasto avete. Il registro sì, se leggete la sequenza invece della prima riga allarmante. Un cookie vecchio di solito mostra che la negoziazione TLS si completa e che il livello HTTP rifiuta dopo, ed è per questo che le parole sui certificati stanno accanto a un errore di autorizzazione.
Confrontate un'esecuzione di authenticate fresca con i valori nel file. Se l'impronta corrisponde e solo il cookie differisce, avete la risposta senza toccare le impostazioni di fiducia.
Rinnovate il campo scaduto
Ripetete il comando authenticate, sostituite OpenConnect.Cookie e riavviate il demone. Lasciate stare l'impronta a meno che l'output fresco non mostri un valore diverso; in quel caso il certificato del server è stato davvero sostituito e il rifissaggio è una decisione che qualcuno deve registrare, non un incollaggio da un messaggio di errore.
Automatizzare il rinnovo è ragionevole: un piccolo script legge la password dall'input standard, esegue la modalità authenticate e riscrive solo la riga del cookie. Tenete la credenziale fuori dallo script e leggibile solo dall'account che lo esegue, e rendete la riscrittura atomica così un'esecuzione fallita non lascia un file scritto a metà.
Se il rinnovo serve ogni poche ore, annotate l'intervallo. È una proprietà della politica di sessione del gateway, e decide se automatizzare il rinnovo o chiedere una sessione più lunga.