A expiração do cookie do ConnMan OpenConnect, não um problema de certificado
Duas falhas parecem iguais no registo. Compare a impressão digital fixada com o cookie de sessão, renove o campo que expirou e depois reinicie o daemon.
O ConnMan funciona durante uma tarde e depois recusa, e a linha do registo menciona a verificação do certificado. Essa linha envia as pessoas para pacotes de CA que nunca estiveram avariados. Duas falhas diferentes produzem quase a mesma forma de insucesso: o cookie de sessão expira, ou o certificado do servidor mudou mesmo. Conseguem separar-se em cerca de um minuto, e só uma delas envolve a impressão digital.
Duas falhas, uma linha de registo confusa
Separam-se em duas observações, e nenhuma delas exige uma segunda leitura. A primeira é quando a falha começou: um cookie expirado chega depois de horas ou dias a funcionar, e um certificado substituído chega logo após uma mudança de 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 |
O teste de um minuto é a execução de authenticate abaixo. Compare o FINGERPRINT com OpenConnect.ServerCert no ficheiro. Uma impressão digital idêntica com um COOKIE diferente significa substituir apenas o cookie. Uma impressão digital diferente significa que o certificado do servidor mudou mesmo, por isso volte a fixá-lo de propósito e registe quem aprovou isso.
Gere o material em vez de o escrever
O ConnMan não tem um passo de importação para um perfil OpenConnect, ao contrário do NetworkManager. Lê um ficheiro de aprovisionamento cujos valores têm de ser produzidos antecipadamente, e a forma suportada de os produzir é o modo authenticate do OpenConnect.
sudo openconnect --csd-wrapper=/home/user/.cisco/csd-wrapper.sh \
--authenticate --user myuser vpn.example.comA saída imprime quatro valores: POST, COOKIE, HOST e FINGERPRINT. A impressão digital, com o prefixo sha256:, é a fixação do servidor. O cookie é o artefacto de sessão com uma vida útil decidida pelo gateway. Trate-os como tipos diferentes de segredo: expiram em calendários diferentes, e só se espera que um mude.
O ficheiro transporta ambos, e envelhecem de forma diferente
O ficheiro de aprovisionamento vive em /var/lib/connman-vpn/ e é lido por ligação pelo daemon de VPN, não pela aplicação da bandeja. Mantenha o nome da ligação na secção global e os detalhes do protocolo na secção do fornecedor.
[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 o nome de anfitrião que o portal serve realmente. Um endereço IP simples pode passar a verificação do certificado e falhar mesmo assim, porque o equipamento encaminha pelo anfitrião virtual e espera o 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 attemptO que o registo mostra realmente
A dica da bandeja não dirá qual falha tem. O registo dirá, se ler a sequência em vez da primeira linha alarmante. Um cookie antigo mostra habitualmente que a negociação TLS terminou e que a camada HTTP recusou depois, e é por isso que as palavras sobre certificados ficam ao lado de uma falha de autorização.
Compare uma execução de authenticate recente com os valores no ficheiro. Se a impressão digital coincidir e só o cookie diferir, já tem a resposta sem tocar nas definições de confiança.
Renove o campo que expirou
Repita o comando authenticate, substitua OpenConnect.Cookie e reinicie o daemon. Deixe a impressão digital em paz, a menos que a saída recente mostre um valor diferente; nesse caso o certificado do servidor foi mesmo substituído e voltar a fixá-lo é uma decisão que alguém deve registar, não uma colagem de uma mensagem de erro.
Automatizar a renovação é razoável: um pequeno script lê a palavra-passe da entrada padrão, executa o modo authenticate e reescreve apenas a linha do cookie. Mantenha a credencial fora do script e legível apenas pela conta que o executa, e torne a reescrita atómica para que uma execução falhada não deixe um ficheiro a meio escrever.
Se a renovação for necessária a cada poucas horas, anote o intervalo. É uma propriedade da política de sessões do gateway, e decide se se automatiza a renovação ou se pede uma sessão mais longa.