ConnMans OpenConnect-cookie utløper, ikke et sertifikatproblem

ConnMan virker en ettermiddag og avviser deretter, og logglinjen nevner sertifikatverifisering. Den linjen sender folk til CA-pakker som aldri var ødelagte. To forskjellige feil gir nesten samme form for svikt: sesjonscookien utløper, eller serverens sertifikat er faktisk endret. De kan skilles på rundt et minutt, og bare én av dem har noe med fingeravtrykket å gjøre.

To feil, én forvirrende logglinje

De skilles på to observasjoner, og ingen av dem krever en ny gjennomlesing. Den første er når feilen begynte: en utløpt cookie kommer etter timer eller dager med arbeid, og et utskiftet sertifikat kommer rett etter en gateway-endring.

Testen på et minutt er authenticate-kjøringen nedenfor. Sammenlign dens FINGERPRINT med OpenConnect.ServerCert i filen. Et identisk fingeravtrykk med en annen COOKIE betyr at bare cookien skal skiftes ut. Et annet fingeravtrykk betyr at serverens sertifikat faktisk er endret, så fest det med vilje på nytt og noter hvem som godkjente det.

Generer materialet i stedet for å skrive det

ConnMan har ikke noe importtrinn for en OpenConnect-profil, i motsetning til NetworkManager. Det leser en provisioning-fil der verdiene må produseres på forhånd, og den støttede måten å produsere dem på er OpenConnects authenticate-modus.

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

Utdata skriver ut fire verdier: POST, COOKIE, HOST og FINGERPRINT. Fingeravtrykket, med prefikset sha256:, er serverens feste. Cookien er sesjonens artefakt med en levetid som gatewayen bestemmer. Behandle dem som forskjellige slags hemmeligheter: de utløper etter forskjellige tidsplaner, og bare én forventes å endre seg.

Filen bærer begge, og de eldes forskjellig

Provisioning-filen ligger under /var/lib/connman-vpn/ og leses per tilkobling av VPN-daemonen, ikke av brettappletten. Hold tilkoblingsnavnet i den globale delen og protokolldetaljene i leverandørdelen.

[global]
Name = Company VPN

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

Bruk vertsnavnet portalen faktisk betjener. En bar IP-adresse kan bestå sertifikatkontrollen og likevel mislykkes, fordi apparatet ruter på den virtuelle verten 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

Hva loggen faktisk viser

Brettets verktøytips vil ikke si hvilken feil du har. Loggen vil, hvis du leser rekkefølgen i stedet for den første alarmerende linjen. En gammel cookie viser typisk at TLS-forhandlingen fullføres og at HTTP-laget avviser etterpå, og derfor står ordene om sertifikater ved siden av en autorisasjonsfeil.

Sammenlign en fersk authenticate-kjøring med verdiene i filen. Hvis fingeravtrykket stemmer og bare cookien avviker, har du svaret uten å røre tillitsinnstillingene.

Forny feltet som utløp

Gjenta authenticate-kommandoen, skift ut OpenConnect.Cookie, og start daemonen på nytt. La fingeravtrykket være i fred med mindre det ferske utdataet viser en annen verdi; i så fall er serverens sertifikat faktisk skiftet ut, og ny festing er en beslutning noen bør notere, ikke en innliming fra en feilmelding.

Det er rimelig å automatisere fornyelsen: et lite skript leser passordet fra standard input, kjører authenticate-modus og skriver bare om cookielinjen. Hold påloggingsinformasjonen utenfor skriptet og lesbar bare for kontoen som kjører det, og gjør omskrivingen atomisk slik at en mislykket kjøring ikke etterlater en halvskrevet fil.

Hvis fornyelsen trengs hver få timer, skriv ned intervallet. Det er en egenskap ved gatewayens sesjonspolicy, og den avgjør om fornyelsen skal automatiseres eller en lengre sesjon bes om.