ConnMans OpenConnect-cookie går ut, inte ett certifikatproblem

ConnMan fungerar en eftermiddag och vägrar sedan, och loggrader nämner certifikatverifiering. Den raden skickar folk till CA-paket som aldrig var trasiga. Två olika fel ger nästan samma form av misslyckande: sessionscookien går ut, eller så har serverns certifikat faktiskt ändrats. De går att skilja på ungefär en minut, och bara ett av dem har något med fingeravtrycket att göra.

Två fel, en förvirrande loggrad

De skiljs åt på två observationer, och ingen av dem kräver en andra läsning. Den första är när felet började: en utgången cookie kommer efter timmar eller dagar av arbete, och ett utbytt certifikat kommer direkt efter en gatewayändring.

Testet på en minut är authenticate-körningen nedan. Jämför dess FINGERPRINT med OpenConnect.ServerCert i filen. Ett identiskt fingeravtryck med en annan COOKIE betyder att bara cookien ska bytas ut. Ett annat fingeravtryck betyder att serverns certifikat faktiskt har ändrats, så fäst det medvetet igen och anteckna vem som godkände det.

Generera materialet i stället för att skriva det

ConnMan har inget importsteg för en OpenConnect-profil, till skillnad från NetworkManager. Det läser en provisioning-fil vars värden måste tas fram i förväg, och det stödda sättet att ta fram dem är OpenConnects authenticate-läge.

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

Utdata skriver ut fyra värden: POST, COOKIE, HOST och FINGERPRINT. Fingeravtrycket, med prefixet sha256:, är serverns fästpunkt. Cookien är sessionens artefakt med en livstid som gatewayen bestämmer. Behandla dem som olika typer av hemlighet: de går ut enligt olika scheman, och bara en förväntas ändras.

Filen bär båda, och de åldras olika

Provisioning-filen ligger under /var/lib/connman-vpn/ och läses per anslutning av VPN-daemonen, inte av panelprogrammet. Håll anslutningsnamnet i det globala avsnittet och protokolldetaljerna i leverantörsavsnittet.

[global]
Name = Company VPN

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

Använd det värdnamn som portalen faktiskt betjänar. En bar IP-adress kan klara certifikatkontrollen och ändå misslyckas, eftersom enheten routar på den virtuella värden och förväntar sig namnet.

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

Vad loggen faktiskt visar

Panelens verktygstips säger inte vilket fel du har. Loggen gör det, om du läser sekvensen i stället för den första alarmerande raden. En gammal cookie visar vanligtvis att TLS-förhandlingen slutförs och att HTTP-lagret avvisar efteråt, och det är därför orden om certifikat står bredvid ett auktoriseringsfel.

Jämför en färsk authenticate-körning med värdena i filen. Om fingeravtrycket stämmer och bara cookien skiljer sig har du svaret utan att röra förtroendeinställningarna.

Förnya fältet som gick ut

Upprepa authenticate-kommandot, byt ut OpenConnect.Cookie och starta om daemonen. Låt fingeravtrycket vara ifred om inte den färska utdatan visar ett annat värde; i så fall har serverns certifikat faktiskt bytts ut och ny fästning är ett beslut som någon bör anteckna, inte en inklistring från ett felmeddelande.

Att automatisera förnyelsen är rimligt: ett litet skript läser lösenordet från standardindata, kör authenticate-läget och skriver bara om cookieraden. Håll inloggningsuppgiften utanför skriptet och läsbar bara för kontot som kör det, och gör omskrivningen atomisk så att en misslyckad körning inte lämnar en halvskriven fil.

Om förnyelsen behövs varje få timmar, skriv ner intervallet. Det är en egenskap hos gatewayens sessionspolicy, och den avgör om förnyelsen ska automatiseras eller om en längre session ska begäras.