Kedaluwarsa cookie ConnMan OpenConnect, bukan masalah sertifikat
Dua kegagalan terlihat sama di log. Bandingkan sidik jari yang disematkan dengan cookie sesi, segarkan bidang yang kedaluwarsa, lalu mulai ulang daemon.
ConnMan bekerja sepanjang sore lalu menolak, dan baris jurnal menyebut verifikasi sertifikat. Baris itu mengirim orang ke bundel CA yang tidak pernah rusak. Dua gangguan berbeda menghasilkan bentuk kegagalan yang hampir sama: cookie sesi kedaluwarsa, atau sertifikat server benar-benar berubah. Keduanya dapat dipisahkan dalam sekitar satu menit, dan hanya satu yang menyangkut sidik jari sama sekali.
Dua gangguan, satu baris log yang membingungkan
Keduanya terpisah lewat dua pengamatan, dan tidak ada yang perlu dibaca dua kali. Yang pertama adalah kapan kegagalan dimulai: cookie yang kedaluwarsa datang setelah berjam-jam atau berhari-hari bekerja, dan sertifikat yang diganti datang tepat setelah perubahan 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 |
Uji satu menit adalah jalannya authenticate di bawah. Bandingkan FINGERPRINT-nya dengan OpenConnect.ServerCert di berkas. Sidik jari identik dengan COOKIE berbeda berarti ganti cookie saja. Sidik jari berbeda berarti sertifikat server benar-benar berubah, jadi sematkan ulang dengan sengaja dan catat siapa yang menyetujuinya.
Hasilkan materinya alih-alih mengetiknya
ConnMan tidak punya langkah impor untuk profil OpenConnect, tidak seperti NetworkManager. Ia membaca berkas penyediaan yang nilainya harus dihasilkan lebih dulu, dan cara yang didukung untuk menghasilkannya adalah mode authenticate OpenConnect.
sudo openconnect --csd-wrapper=/home/user/.cisco/csd-wrapper.sh \
--authenticate --user myuser vpn.example.comKeluarannya mencetak empat nilai: POST, COOKIE, HOST dan FINGERPRINT. Sidik jari, dengan awalan sha256:, adalah penyematan server. Cookie adalah artefak sesi dengan masa hidup yang ditentukan gateway. Perlakukan keduanya sebagai jenis rahasia yang berbeda: keduanya kedaluwarsa pada jadwal berbeda, dan hanya satu yang diperkirakan berubah.
Berkas itu memuat keduanya, dan keduanya menua secara berbeda
Berkas penyediaan berada di bawah /var/lib/connman-vpn/ dan dibaca per koneksi oleh daemon VPN, bukan oleh applet baki. Simpan nama koneksi di bagian global dan detail protokol di bagian penyedia.
[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 host yang benar-benar dilayani portal. Alamat IP telanjang bisa lolos pemeriksaan sertifikat dan tetap gagal, karena peranti merutekan berdasarkan host virtual 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 attemptApa yang sebenarnya ditunjukkan jurnal
Tooltip baki tidak akan memberi tahu gangguan mana yang Anda alami. Jurnal akan, jika Anda membaca urutannya alih-alih baris pertama yang mengkhawatirkan. Cookie basi biasanya menunjukkan negosiasi TLS selesai dan lapisan HTTP menolak sesudahnya, itulah sebabnya kata-kata tentang sertifikat berada di samping kegagalan otorisasi.
Bandingkan jalannya authenticate yang baru dengan nilai di berkas. Jika sidik jari cocok dan hanya cookie yang berbeda, Anda sudah punya jawabannya tanpa menyentuh pengaturan kepercayaan.
Segarkan bidang yang kedaluwarsa
Ulangi perintah authenticate, ganti OpenConnect.Cookie, dan mulai ulang daemon. Biarkan sidik jari apa adanya kecuali keluaran baru menunjukkan nilai berbeda; dalam hal itu sertifikat server benar-benar diganti dan penyematan ulang adalah keputusan yang harus dicatat seseorang, bukan tempelan dari pesan galat.
Mengotomatiskan penyegaran itu wajar: skrip kecil membaca kata sandi dari masukan standar, menjalankan mode authenticate, dan hanya menulis ulang baris cookie. Jauhkan kredensial dari skrip dan hanya dapat dibaca oleh akun yang menjalankannya, dan buat penulisan ulang bersifat atomik agar jalannya yang gagal tidak meninggalkan berkas setengah tertulis.
Jika penyegaran diperlukan setiap beberapa jam, catat intervalnya. Itu sifat kebijakan sesi gateway, dan itu menentukan apakah penyegaran diotomatiskan atau meminta sesi yang lebih panjang.