Pag-expire ng cookie ng ConnMan OpenConnect, hindi problema sa sertipiko

Gumagana ang ConnMan nang isang hapon at pagkatapos ay tumatanggi, at binabanggit ng linya sa journal ang pagpapatunay ng sertipiko. Ang linyang iyon ay nagpapadala ng mga tao sa mga bundle ng CA na hindi kailanman nasira. Dalawang magkaibang sira ang gumagawa ng halos parehong hugis ng pagkabigo: nag-expire ang cookie ng sesyon, o tunay na nagbago ang sertipiko ng server. Mapaghihiwalay ang mga ito sa mga isang minuto, at isa lamang sa kanila ang may kinalaman sa fingerprint.

Dalawang sira, isang nakakalitong linya ng log

Naghiwalay sila sa dalawang obserbasyon, at wala sa mga ito ang kailangang basahin nang dalawang beses. Ang una ay kung kailan nagsimula ang pagkabigo: dumarating ang nag-expire na cookie pagkatapos ng mga oras o araw ng paggana, at dumarating ang pinalitang sertipiko agad pagkatapos ng pagbabago sa gateway.

Ang pagsubok na isang minuto ay ang pagpapatakbo ng authenticate sa ibaba. Ihambing ang FINGERPRINT nito sa OpenConnect.ServerCert sa file. Ang magkatulad na fingerprint na may ibang COOKIE ay nangangahulugang palitan lamang ang cookie. Ang ibang fingerprint ay nangangahulugang tunay na nagbago ang sertipiko ng server, kaya sadyang i-pin itong muli at itala kung sino ang nagapruba.

Bumuo ng materyal sa halip na i-type ito

Walang hakbang sa pag-import ang ConnMan para sa isang profile ng OpenConnect, di gaya ng NetworkManager. Binabasa nito ang isang file ng provisioning na ang mga halaga ay dapat gawin nang maaga, at ang sinusuportahang paraan upang gawin ang mga ito ay ang authenticate mode ng OpenConnect.

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

Nagpi-print ang output ng apat na halaga: POST, COOKIE, HOST at FINGERPRINT. Ang fingerprint, na may prefix na sha256:, ang pin ng server. Ang cookie ang artefact ng sesyon na ang habang-buhay ay pinagpapasyahan ng gateway. Tratuhin silang magkaibang uri ng lihim: nag-expire sila sa magkaibang iskedyul, at isa lamang ang inaasahang magbabago.

Dinadala ng file ang dalawa, at tumatanda sila nang magkaiba

Nasa ilalim ng /var/lib/connman-vpn/ ang file ng provisioning at binabasa ito bawat koneksyon ng daemon ng VPN, hindi ng applet sa tray. Panatilihin ang pangalan ng koneksyon sa global na seksyon at ang mga detalye ng protocol sa seksyon ng provider.

[global]
Name = Company VPN

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

Gamitin ang hostname na talagang pinaglilingkuran ng portal. Ang hubad na IP address ay maaaring makapasa sa tsek ng sertipiko at mabigo pa rin, dahil nagru-route ang appliance sa virtual host at inaasahan ang pangalan.

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

Ano ang talagang ipinapakita ng journal

Hindi sasabihin ng tooltip sa tray kung aling sira ang mayroon ka. Sasabihin ito ng journal, kung babasahin mo ang pagkakasunod-sunod sa halip na ang unang nakakaalarmang linya. Ang lumang cookie ay karaniwang nagpapakita na natapos ang TLS negotiation at tumanggi ang HTTP layer pagkatapos, kaya naroon ang mga salita tungkol sa mga sertipiko sa tabi ng pagkabigo sa awtorisasyon.

Ihambing ang bagong pagpapatakbo ng authenticate sa mga halaga sa file. Kung tugma ang fingerprint at ang cookie lamang ang naiiba, may sagot ka na nang hindi hinahawakan ang mga setting ng pagtitiwala.

I-refresh ang field na nag-expire

Ulitin ang command na authenticate, palitan ang OpenConnect.Cookie, at i-restart ang daemon. Iwanan ang fingerprint maliban kung ang bagong output ay nagpapakita ng ibang halaga; sa ganoong kaso tunay na pinalitan ang sertipiko ng server at ang muling pag-pin ay desisyong dapat itala ng isang tao, hindi isang paste mula sa mensahe ng error.

Makatwiran ang pag-automate ng refresh: isang maliit na script ang nagbabasa ng password mula sa standard input, nagpapatakbo ng authenticate mode at nagsusulat muli lamang ng linya ng cookie. Ilagay ang kredensyal sa labas ng script at mabasa lamang ng account na nagpapatakbo nito, at gawing atomic ang pagsusulat muli upang ang nabigong pagpapatakbo ay hindi mag-iwan ng kalahating naisulat na file.

Kung kailangan ang refresh tuwing ilang oras, isulat ang agwat. Ito ay katangian ng patakaran sa sesyon ng gateway, at ito ang nagpapasya kung i-automate ang refresh o humingi ng mas mahabang sesyon.