Skadimi i cookie-t të ConnMan OpenConnect, jo problem certifikate

ConnMan punon një pasdite dhe më pas refuzon, dhe rreshti i regjistrit përmend verifikimin e certifikatës. Ai rresht i dërgon njerëzit te paketat CA që nuk ishin prishur kurrë. Dy defekte të ndryshme prodhojnë pothuajse të njëjtën formë dështimi: cookie-ja e sesionit skadon, ose certifikata e serverit ka ndryshuar vërtet. Ato mund të ndahen në rreth një minutë, dhe vetëm njëra prej tyre ka të bëjë fare me gjurmën e gishtit.

Dy defekte, një rresht regjistri ngatërrues

Ato ndahen në dy vëzhgime, dhe asnjëra nuk kërkon një lexim të dytë. E para është kur filloi defekti: një cookie e skaduar vjen pas orësh ose ditësh pune, dhe një certifikatë e zëvendësuar vjen menjëherë pas një ndryshimi të portës.

Testi i një minute është ekzekutimi i authenticate më poshtë. Krahasoni FINGERPRINT-in e tij me OpenConnect.ServerCert në skedar. Një gjurmë identike me një COOKIE tjetër do të thotë të zëvendësoni vetëm cookie-n. Një gjurmë tjetër do të thotë që certifikata e serverit ka ndryshuar vërtet, prandaj fiksojeni përsëri me qëllim dhe shënoni kush e miratoi atë.

Gjeneroni materialin në vend që ta shkruani

ConnMan nuk ka një hap importimi për një profil OpenConnect, ndryshe nga NetworkManager. Ai lexon një skedar furnizimi, vlerat e të cilit duhet të prodhohen paraprakisht, dhe mënyra e mbështetur për t'i prodhuar ato është modaliteti authenticate i OpenConnect.

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

Dalja shtyp katër vlera: POST, COOKIE, HOST dhe FINGERPRINT. Gjurma e gishtit, me prefiksin sha256:, është fiksimi i serverit. Cookie-ja është artefakti i sesionit me një jetëgjatësi që vendos porta. Trajtojini si lloje të ndryshme sekreti: skadojnë sipas kalendarëve të ndryshëm, dhe pritet të ndryshojë vetëm njëra.

Skedari mban të dyja, dhe ato plaken ndryshe

Skedari i furnizimit ndodhet nën /var/lib/connman-vpn/ dhe lexohet për çdo lidhje nga daemon-i i VPN-së, jo nga applet-i i tabakasë. Mbani emrin e lidhjes në seksionin global dhe detajet e protokollit në seksionin e ofruesit.

[global]
Name = Company VPN

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

Përdorni emrin e hostit që portali shërben vërtet. Një adresë IP e thjeshtë mund të kalojë kontrollin e certifikatës dhe të dështojë gjithsesi, sepse pajisja rrugëton sipas hostit virtual dhe pret emrin.

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

Çfarë tregon vërtet regjistri

Këshilla në tabaka nuk do të thotë se cili defekt keni. Regjistri do ta thotë, nëse lexoni sekuencën dhe jo rreshtin e parë alarmues. Një cookie e vjetër zakonisht tregon se negociimi TLS përfundoi dhe shtresa HTTP refuzoi më pas, prandaj fjalët për certifikatat qëndrojnë pranë një dështimi autorizimi.

Krahasoni një ekzekutim të freskët authenticate me vlerat në skedar. Nëse gjurma përputhet dhe ndryshon vetëm cookie-ja, e keni përgjigjen pa prekur cilësimet e besimit.

Rifreskoni fushën e skaduar

Përsëritni komandën authenticate, zëvendësoni OpenConnect.Cookie dhe rinisni daemon-in. Lëreni gjurmën e gishtit të qetë, përveç rastit kur dalja e freskët tregon një vlerë tjetër; në atë rast certifikata e serverit u zëvendësua vërtet dhe rifiksimi është një vendim që dikush duhet të regjistrojë, jo një ngjitje nga një mesazh gabimi.

Automatizimi i rifreskimit është i arsyeshëm: një skript i vogël lexon fjalëkalimin nga hyrja standarde, ekzekuton modalitetin authenticate dhe rishkruan vetëm rreshtin e cookie-s. Mbani kredencialet jashtë skriptit dhe të lexueshme vetëm nga llogaria që e ekzekuton, dhe bëjeni rishkrimin atomik që një ekzekutim i dështuar të mos lërë një skedar gjysmë të shkruar.

Nëse rifreskimi nevojitet çdo disa orë, shkruani intervalin. Është një veti e politikës së sesioneve të portës, dhe vendos nëse rifreskimi duhet automatizuar ose duhet kërkuar një sesion më i gjatë.