ConnMans OpenConnect-cookie udløber, ikke et certifikatproblem

ConnMan virker en eftermiddag og afviser derefter, og loglinjen nævner certifikatverifikation. Den linje sender folk til CA-pakker, der aldrig var i stykker. To forskellige fejl giver næsten samme form for svigt: sessionscookien udløber, eller servercertifikatet er faktisk ændret. De kan skelnes på cirka et minut, og kun én af dem har noget med fingeraftrykket at gøre.

To fejl, én forvirrende loglinje

De skilles ad på to observationer, og ingen af dem kræver en anden gennemlæsning. Den første er, hvornår fejlen begyndte: en udløbet cookie kommer efter timer eller dage med arbejde, og et udskiftet certifikat kommer lige efter en gatewayændring.

Testen på et minut er authenticate-kørslen nedenfor. Sammenlign dens FINGERPRINT med OpenConnect.ServerCert i filen. Et identisk fingeraftryk med en anden COOKIE betyder, at kun cookien skal udskiftes. Et andet fingeraftryk betyder, at servercertifikatet faktisk er ændret, så fastgør det med vilje igen, og noter, hvem der godkendte det.

Generér materialet i stedet for at skrive det

ConnMan har ikke et importtrin til en OpenConnect-profil, i modsætning til NetworkManager. Den læser en provisioning-fil, hvis værdier skal fremstilles på forhånd, og den understøttede måde at fremstille dem på er OpenConnects authenticate-tilstand.

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

Outputtet udskriver fire værdier: POST, COOKIE, HOST og FINGERPRINT. Fingeraftrykket, med præfikset sha256:, er serverens fastgørelse. Cookien er sessionens artefakt med en levetid, som gatewayen bestemmer. Behandl dem som forskellige slags hemmeligheder: de udløber efter forskellige skemaer, og kun én forventes at ændre sig.

Filen bærer begge, og de ældes forskelligt

Provisioning-filen ligger under /var/lib/connman-vpn/ og læses pr. forbindelse af VPN-daemonen, ikke af bakkeappletten. Behold forbindelsesnavnet i det globale afsnit og protokoldetaljerne i udbyderafsnittet.

[global]
Name = Company VPN

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

Brug det værtsnavn, portalen faktisk betjener. En bar IP-adresse kan bestå certifikatkontrollen og alligevel fejle, fordi apparatet ruter på den virtuelle vært og forventer navnet.

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

Hvad loggen faktisk viser

Bakketipset vil ikke sige, hvilken fejl du har. Loggen vil, hvis du læser rækkefølgen i stedet for den første alarmerende linje. En gammel cookie viser typisk, at TLS-forhandlingen fuldføres, og at HTTP-laget derefter afviser, og det er derfor ordene om certifikater står ved siden af en autorisationsfejl.

Sammenlign en frisk authenticate med værdierne i filen. Hvis fingeraftrykket stemmer, og kun cookien afviger, har du svaret uden at røre tillidsindstillingerne.

Forny det felt, der er udløbet

Gentag authenticate-kommandoen, udskift OpenConnect.Cookie, og genstart daemonen. Lad fingeraftrykket være, medmindre det friske output viser en anden værdi; i så fald er servercertifikatet faktisk udskiftet, og ny fastgørelse er en beslutning, som nogen bør notere, ikke en indsættelse fra en fejlmeddelelse.

Det er rimeligt at automatisere fornyelsen: et lille script læser adgangskoden fra standardindgangen, kører authenticate-tilstand og omskriver kun cookielinjen. Hold legitimationsoplysningen ude af scriptet og læsbar kun for den konto, der kører det, og gør omskrivningen atomisk, så en mislykket kørsel ikke efterlader en halvskrevet fil.

Hvis fornyelsen er nødvendig hver få timer, så skriv intervallet ned. Det er en egenskab ved gatewayens sessionspolitik, og den afgør, om fornyelsen skal automatiseres, eller der skal bedes om en længere session.