ConnMan OpenConnect-cookie går ut, ikkje eit sertifikatproblem

ConnMan verkar ein ettermiddag og nektar så, og logglinja nemner sertifikatkontroll. Den linja sender folk til CA-pakkar som aldri var øydelagde. To ulike feil gjev nesten same forma for svikt: sesjonscookien går ut, eller sertifikatet til tenaren er faktisk endra. Dei kan skiljast på rundt eitt minutt, og berre ein av dei har noko med fingeravtrykket å gjera.

To feil, éi forvirrande logglinje

Dei skil seg på to observasjonar, og ingen av dei krev ei ny gjennomlesing. Den første er når feilen byrja: ein utlopen cookie kjem etter timar eller dagar med arbeid, og eit utskifta sertifikat kjem rett etter ei gateway-endring.

Testen på eitt minutt er authenticate-køyringa nedanfor. Samanlikn FINGERPRINT hennar med OpenConnect.ServerCert i fila. Eit identisk fingeravtrykk med ein annan COOKIE tyder at berre cookien skal skiftast ut. Eit anna fingeravtrykk tyder at sertifikatet til tenaren faktisk er endra, så fest det med vilje på nytt og noter kven som godkjende det.

Generer materialet i staden for å skrive det

ConnMan har ikkje noko importsteg for ein OpenConnect-profil, i motsetnad til NetworkManager. Det les ei provisioning-fil der verdiane må lagast på førehand, og den støtta måten å lage dei på er authenticate-modusen til OpenConnect.

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

Utdata skriv ut fire verdiar: POST, COOKIE, HOST og FINGERPRINT. Fingeravtrykket, med prefikset sha256:, er festet til tenaren. Cookien er artefakten til sesjonen med ei levetid som gatewayen avgjer. Handsame dei som ulike slag løyndom: dei går ut etter ulike tidsplanar, og berre éin blir venta å endre seg.

Fila ber begge, og dei eldast ulikt

Provisioning-fila ligg under /var/lib/connman-vpn/ og blir lesen per tilkoping av VPN-daemonen, ikkje av brett-appletten. Hald tilkopingsnamnet i den globale delen og protokolldetaljane 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 vertsnamnet portalen faktisk tener. Ei bar IP-adresse kan greie sertifikatkontrollen og likevel mislukkast, fordi eininga ruter på den virtuelle verten og ventar 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

Kva loggen faktisk viser

Verktøytipset i brettet vil ikkje seia kva feil du har. Loggen vil det, om du les rekkjefølgja i staden for den første alarmerande linja. Ein gammal cookie viser typisk at TLS-forhandlinga blir fullført og at HTTP-laget nektar etterpå, og difor står orda om sertifikat ved sida av ein autorisasjonsfeil.

Samanlikn ei fersk authenticate-køyring med verdiane i fila. Om fingeravtrykket stemmer og berre cookien avvik, har du svaret utan å røre tillitsinnstillingane.

Forny feltet som gjekk ut

Gjenta authenticate-kommandoen, skift ut OpenConnect.Cookie, og start daemonen på nytt. Lat fingeravtrykket vera i fred med mindre det ferske utdataet viser ein annan verdi; i så fall er sertifikatet til tenaren faktisk skifta ut, og ny festing er eit vedtak nokon bør notere, ikkje ei innliming frå ei feilmelding.

Det er rimeleg å automatisere fornyinga: eit lite skript les passordet frå standard input, køyrer authenticate-modus og skriv berre om cookielinja. Hald påloggingsinformasjonen utanfor skriptet og lesbar berre for kontoen som køyrer det, og gjer omskrivinga atomisk slik at ei mislukka køyring ikkje etterlèt ei halvskriven fil.

Om fornyinga trengst kvar få timar, skriv ned intervallet. Det er ein eigenskap ved sesjonspolitikken til gatewayen, og det avgjer om fornyinga skal automatiserast eller ein lengre sesjon skal be om.