ConnMan berfungsi satu petang dan kemudian menolak, dan baris jurnal menyebut pengesahan sijil. Baris itu menghantar orang kepada berkas CA yang tidak pernah rosak. Dua kerosakan berbeza menghasilkan bentuk kegagalan yang hampir sama: cookie sesi tamat tempoh, atau sijil pelayan benar-benar berubah. Kedua-duanya boleh dipisahkan dalam kira-kira satu minit, dan hanya satu daripadanya melibatkan cap jari.

Dua kerosakan, satu baris log yang mengelirukan

Kedua-duanya berpisah pada dua pemerhatian, dan tidak ada yang perlu dibaca dua kali. Yang pertama ialah bila kegagalan bermula: cookie yang tamat tempoh datang selepas berjam-jam atau berhari-hari berfungsi, dan sijil yang diganti datang sejurus selepas perubahan gerbang.

SignalExpired cookieChanged certificate
When it startedafter hours or days of workingright after a gateway change
Fingerprint from a fresh authenticateunchangeddifferent value
Usual log tailHTTP CONNECT 401 / unauthorizedsigner not found / verify failed
Repairreplace the cookie, restartre-pin deliberately, then restart

Ujian satu minit ialah larian authenticate di bawah. Bandingkan FINGERPRINT-nya dengan OpenConnect.ServerCert dalam fail. Cap jari yang sama dengan COOKIE berbeza bermaksud ganti cookie sahaja. Cap jari berbeza bermaksud sijil pelayan benar-benar berubah, jadi pin semula dengan sengaja dan catat siapa yang meluluskannya.

Jana bahan itu daripada menaipnya

ConnMan tiada langkah import untuk profil OpenConnect, tidak seperti NetworkManager. Ia membaca fail peruntukan yang nilainya mesti dijana terlebih dahulu, dan cara yang disokong untuk menjananya ialah mod authenticate OpenConnect.

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

Output mencetak empat nilai: POST, COOKIE, HOST dan FINGERPRINT. Cap jari, dengan awalan sha256:, ialah pin pelayan. Cookie ialah artifak sesi dengan jangka hayat yang ditentukan gerbang. Perlakukan kedua-duanya sebagai jenis rahsia yang berbeza: kedua-duanya tamat tempoh mengikut jadual berbeza, dan hanya satu yang dijangka berubah.

Fail itu membawa kedua-duanya, dan kedua-duanya menua secara berbeza

Fail peruntukan terletak di bawah /var/lib/connman-vpn/ dan dibaca bagi setiap sambungan oleh daemon VPN, bukan oleh applet dulang. Simpan nama sambungan dalam bahagian global dan butiran protokol dalam bahagian pembekal.

[global]
Name = Company VPN

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

Gunakan nama hos yang benar-benar dilayan oleh portal. Alamat IP kosong boleh lulus pemeriksaan sijil dan masih gagal, kerana peranti menghalakan berdasarkan hos maya dan mengharapkan namanya.

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

Apa yang sebenarnya ditunjukkan jurnal

Petua dulang tidak akan memberitahu kerosakan mana yang anda hadapi. Jurnal akan, jika anda membaca urutan dan bukan baris pertama yang membimbangkan. Cookie basi biasanya menunjukkan rundingan TLS selesai dan lapisan HTTP menolak selepas itu, sebab itulah perkataan tentang sijil berada di sebelah kegagalan kebenaran.

Bandingkan larian authenticate yang baharu dengan nilai dalam fail. Jika cap jari sepadan dan hanya cookie berbeza, anda sudah ada jawapannya tanpa menyentuh tetapan kepercayaan.

Segarkan medan yang tamat tempoh

Ulang perintah authenticate, ganti OpenConnect.Cookie, dan mulakan semula daemon. Biarkan cap jari kecuali output baharu menunjukkan nilai berbeza; dalam kes itu sijil pelayan benar-benar diganti dan peminian semula ialah keputusan yang seseorang patut catat, bukan tampalan daripada mesej ralat.

Mengautomasikan penyegaran adalah wajar: skrip kecil membaca kata laluan daripada input standard, menjalankan mod authenticate dan menulis semula hanya baris cookie. Jauhkan kelayakan daripada skrip dan hanya boleh dibaca oleh akaun yang menjalankannya, dan jadikan penulisan semula atomik supaya larian yang gagal tidak meninggalkan fail separuh tertulis.

Jika penyegaran diperlukan setiap beberapa jam, catat selangnya. Itu sifat dasar sesi gerbang, dan ia menentukan sama ada penyegaran diautomasikan atau sesi yang lebih panjang diminta.

Artikel berkaitan