Expirarea cookie-ului ConnMan OpenConnect, nu o problemă de certificat
Două defecțiuni arată la fel în jurnal. Comparați amprenta fixată cu cookie-ul sesiunii, reîmprospătați câmpul expirat și apoi reporniți daemonul.
ConnMan funcționează o după-amiază și apoi refuză, iar linia din jurnal menționează verificarea certificatului. Acea linie trimite oamenii la pachete CA care nu au fost niciodată stricate. Două defecțiuni diferite produc aproape aceeași formă de eșec: cookie-ul sesiunii expiră sau certificatul serverului s-a schimbat cu adevărat. Pot fi separate în aproximativ un minut, și doar unul dintre ele implică amprenta.
Două defecțiuni, o linie de jurnal înșelătoare
Se separă prin două observații, iar niciuna nu cere o a doua citire. Prima este când a început defecțiunea: un cookie expirat apare după ore sau zile de funcționare, iar un certificat înlocuit apare imediat după o schimbare 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 |
Testul de un minut este rularea authenticate de mai jos. Comparați FINGERPRINT-ul ei cu OpenConnect.ServerCert din fișier. O amprentă identică cu un COOKIE diferit înseamnă să înlocuiți doar cookie-ul. O amprentă diferită înseamnă că certificatul serverului s-a schimbat cu adevărat, așa că fixați-l din nou în mod deliberat și notați cine a aprobat asta.
Generați materialul în loc să îl scrieți
ConnMan nu are un pas de import pentru un profil OpenConnect, spre deosebire de NetworkManager. Citește un fișier de aprovizionare ale cărui valori trebuie produse în avans, iar modalitatea acceptată de a le produce este modul authenticate al OpenConnect.
sudo openconnect --csd-wrapper=/home/user/.cisco/csd-wrapper.sh \
--authenticate --user myuser vpn.example.comIeșirea tipărește patru valori: POST, COOKIE, HOST și FINGERPRINT. Amprenta, cu prefixul sha256:, este fixarea serverului. Cookie-ul este artefactul sesiunii cu o durată de viață decisă de gateway. Tratați-le ca tipuri diferite de secret: expiră după calendare diferite, și doar unul se așteaptă să se schimbe.
Fișierul le poartă pe amândouă, și ele îmbătrânesc diferit
Fișierul de aprovizionare se află sub /var/lib/connman-vpn/ și este citit pentru fiecare conexiune de daemonul VPN, nu de appletul din tavă. Păstrați numele conexiunii în secțiunea globală și detaliile protocolului în secțiunea furnizorului.
[global]
Name = Company VPN
[provider_openconnect]
Type = OpenConnect
Name = Company Cisco VPN
Host = vpn.example.com
Domain = corp.example
OpenConnect.ServerCert = sha256:...
OpenConnect.Cookie = ...Folosiți numele de gazdă pe care portalul îl deservește cu adevărat. O adresă IP simplă poate trece verificarea certificatului și totuși eșua, pentru că aparatul rutează după gazda virtuală și așteaptă numele.
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 attemptCe arată de fapt jurnalul
Sfatul din tavă nu va spune ce defecțiune aveți. Jurnalul va spune, dacă citiți secvența și nu prima linie alarmantă. Un cookie vechi arată de obicei că negocierea TLS s-a încheiat și că stratul HTTP a refuzat după aceea, de aceea cuvintele despre certificate stau lângă un eșec de autorizare.
Comparați o rulare authenticate proaspătă cu valorile din fișier. Dacă amprenta se potrivește și doar cookie-ul diferă, aveți răspunsul fără să atingeți setările de încredere.
Reîmprospătați câmpul expirat
Repetați comanda authenticate, înlocuiți OpenConnect.Cookie și reporniți daemonul. Lăsați amprenta în pace dacă ieșirea proaspătă nu arată o valoare diferită; în acel caz certificatul serverului a fost într-adevăr înlocuit, iar refixarea este o decizie pe care cineva ar trebui să o consemneze, nu o lipire dintr-un mesaj de eroare.
Automatizarea reîmprospătării este rezonabilă: un script mic citește parola de la intrarea standard, rulează modul authenticate și rescrie doar linia cookie-ului. Țineți acreditarea în afara scriptului și lizibilă doar pentru contul care îl rulează, și faceți rescrierea atomică pentru ca o rulare eșuată să nu lase un fișier pe jumătate scris.
Dacă reîmprospătarea este necesară la fiecare câteva ore, notați intervalul. Este o proprietate a politicii de sesiuni a gateway-ului și decide dacă să automatizați reîmprospătarea sau să cereți o sesiune mai lungă.