Berapa lama OpenConnect perlu terus mencuba VPN yang terputus?

--reconnect-timeout menjawab satu soalan sempit: selepas terowong jatuh, berapa lama proses klien ini terus mencuba sebelum menyerah dan keluar. Halaman manual OpenConnect merekodkan pilihan itu dengan lalai terdokumen 300 saat untuk cubaan semula yang menyusuli pautan hilang atau rakan yang berhenti menjawab, dan nombor itu ialah tarikh akhir bagi satu klien yang berjalan, bukan bukti VPN kekal boleh dicapai. Ia juga bukan dasar untuk mengekalkan proses hidup, dan di situlah kebanyakan kekeliruan bermula.

Kekeliruan bertambah apabila mekanisme kedua duduk di atasnya. Penyelia yang memulakan semula klien, pemeriksa yang mengeping gateway, dan tetingkap cubaan semula terbina semuanya boleh bertindak balas terhadap satu kegagalan, dan insiden itu kemudian menghasilkan tiga garis masa yang tiada siapa dapat selaraskan.

Apa yang sebenarnya dihadkan oleh tetingkap sambung semula

Bayangkan rangkaian akses hilang selama beberapa saat. Klien melihat pautan terputus, atau berhenti mendengar balasan daripada rakan mati, dan mula membina semula sesi sambil mengekalkan keadaan yang mampu. Cubaan berterusan sehingga gateway menerima semula atau tetingkap tamat, dan tetingkap yang tamat berakhir dengan keluar bukan sifar. Keluar itulah, bukan nilai tamat masa, tempat pemilikan kitaran hayat beralih kepada sesiapa yang menyelia proses itu.

Tetingkap tidak berkata apa-apa tentang kekerapan pemeriksa dijalankan, dan ia tidak boleh memanjangkan pengesahan. Jika gateway telah membatalkan sesi, atau akaun kini menuntut faktor kedua yang baharu, menunggu lebih lama tidak akan menjadikan sesi lama sah semula. Cubaan semula hanya berjaya apabila laluan kembali, gateway masih mengenali sesi, dan kelayakan yang diminta kekal boleh digunakan, jadi bacalah nombor itu sebagai tarikh akhir dan bukan selang kecergasan.

Tetingkap juga tidak mengawal apa yang aplikasi lakukan semasa ia berjalan. Bergantung pada platform dan sejauh mana kegagalan itu pergi, klien mungkin menyambung semula dengan laluan masih terpasang, atau selepas laluan itu ditarik. Itulah sebabnya permintaan yang dikeluarkan di tengah gangguan cenderung tergantung sehingga tamat masa dan bukannya gagal pantas.

Mula semula oleh penyelia dan cubaan semula klien ialah dua lapisan

Biarkan klien yang berjalan menghabiskan tetingkapnya sendiri, dan biarkan pengurus perkhidmatan bertindak balas terhadap keluarnya. Klien di latar hadapan di bawah systemd dengan dasar mula semula memberikan tepat pembahagian itu: cubaan untuk tempoh terhad, kemudian satu keputusan mula semula. Hasilnya ialah satu garis masa yang masih boleh anda bina semula selepas itu.

Klien di latar belakang ditambah pemeriksa bebas yang memulakan salinan lain apabila tidak melihat antara muka ialah corak yang menjadi kacau. Kedua-dua proses kemudian berebut nod peranti, laluan dan tetapan penyelesai yang sama. Jika anda benar-benar mahu daemon, letakkan pilihan itu pada baris arahan yang klien benar-benar mulakan:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Dua butiran pada baris itu mempunyai berat. --background melepaskan proses, jadi fail pid menjadi satu-satunya pegangan yang boleh dipercayai padanya, dan tamat masa hanya digunakan selagi proses yang sama hidup; penyelia yang membunuhnya tidak meninggalkan bajet untuk meneruskan.

Pemutusan yang disengajakan memerlukan isyaratnya sendiri. Jeda terancang dan gangguan sebenar kelihatan sama kepada pemerhati naif, kedua-duanya dibaca sebagai «tidak bersambung». Kendalikan jeda melalui operasi berhenti penyelia, atau penanda yang difahami pembalut, supaya penghentian yang disengajakan tidak mencetuskan mula semula yang tiada siapa minta.

Mengelakkan penyerahan berlumba dengan gelung cubaan semula

Pemulihan tanpa pengawasan bergantung pada kelayakan yang diperbaharui tanpa kehadiran orang. Gelang kunci yang hanya terbuka dalam sesi desktop interaktif, atau token yang sentiasa memerlukan kod ditaip, akan membiarkan klien terhenti pada peringkat pengesahan sebaik laluan kembali. Selesaikan aliran kerja itu sebelum memanjangkan tetingkap, kerana tetingkap yang lebih panjang hanya memberi gesaan yang tersekat itu lebih banyak masa untuk gagal.

Pengesahan pelayan tidak sepatutnya dilonggarkan untuk mengurangkan gesaan. Pin atau sauh kepercayaan yang mengesahkan gateway itulah yang menjadikan sambung semula automatik selamat, dan mematikannya untuk mengelakkan soalan sijil menukar gangguan yang kelihatan dengan yang tidak kelihatan. Kekalkan identiti yang disahkan dan baiki gesaan itu; klien yang sanggup menyambung ke mana-mana gateway lebih buruk daripada yang berhenti dan menunggu.

Kehadiran antara muka juga bukan isyarat kesihatan. Peranti terowong boleh wujud dengan sesi mati di belakangnya, dan proses pelancar boleh wujud tanpa terowong sama sekali. Tiada satu pun pemerhatian itu bertahan pada permintaan sebenar. Kesihatan mesti datang daripada apa yang pengguna perlukan, seperti permintaan yang menembusi terowong ke perkhidmatan dalaman yang diketahui.

Apa yang perlu disahkan semasa dan selepas gangguan

Jalankan empat peristiwa sebagai ujian berasingan: gangguan lebih pendek daripada tetingkap, gangguan lebih panjang daripadanya, kegagalan pengesahan, dan penghentian yang disengajakan. Setiap satu harus berakhir dalam keadaan berbeza yang boleh diramal, dan sempadan antara dua yang pertama ialah seluruh sebab memilih nilai.

Kekalkan pemeriksaan menghadap ke luar, kerana jadual proses sendiri membuktikan sangat sedikit. Perhatikan pid kekal stabil sepanjang gangguan pendek, kemudian sahkan ia hilang dan diganti sekali selepas yang panjang:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Semasa gangguan pendek, sahkan klien benar-benar mencuba semula dan bukan keluar awal, dan bahawa laluan serta entri penyelesai kembali tanpa pendua. Untuk gangguan yang lebih panjang, sahkan keluar bersih dan tepat satu mula semula menyusul. Untuk kegagalan pengesahan, sahkan klien tidak berpusing melawan gateway yang akan terus menolaknya. Tambah pemeriksaan bahawa pid kembali kepada satu nilai dan bukan terkumpul.

Untuk penghentian yang disengajakan, URL kesihatan harus kekal tidak dapat dicapai dan proses harus kekal mati. Kemudian tutup gelung dari sisi aplikasi: permintaan yang sama mesti gagal semasa terowong tiada dan mesti berjaya selepas ia kembali, dari alamat sumber yang dijangkakan dasar anda. Ikon terowong hijau bukan bukti, tetapi permintaan yang selesai ialah bukti.