Berapa lama OpenConnect harus terus mencoba VPN yang terputus?

--reconnect-timeout menjawab satu pertanyaan sempit: setelah terowongan jatuh, berapa lama proses klien ini terus mencoba sebelum menyerah dan keluar. Halaman manual OpenConnect mencatat opsi itu dengan nilai bawaan terdokumentasi 300 detik untuk percobaan ulang yang menyusul tautan hilang atau peer yang berhenti menjawab, dan angkanya adalah tenggat bagi satu klien yang berjalan, bukan bukti bahwa VPN tetap terjangkau. Ini juga bukan kebijakan untuk menjaga proses tetap hidup, dan di situlah sebagian besar kebingungan dimulai.

Kebingungan bertambah ketika mekanisme kedua duduk di atasnya. Supervisor yang memulai ulang klien, pemeriksa yang mem-ping gateway, dan jendela percobaan ulang bawaan semuanya bisa bereaksi terhadap satu kegagalan, dan insiden itu lalu menghasilkan tiga garis waktu yang tidak dapat didamaikan siapa pun.

Apa yang sebenarnya dibatasi jendela sambung ulang

Bayangkan jaringan akses lenyap selama beberapa detik. Klien melihat tautan putus, atau berhenti mendengar balasan dari peer mati, dan mulai membangun ulang sesi sambil mempertahankan status yang bisa dipertahankannya. Percobaan berlanjut sampai gateway menerima lagi atau jendela habis, dan jendela yang habis berakhir dengan keluar bukan nol. Keluar itulah, bukan nilai batas waktu, titik tempat kepemilikan siklus hidup berpindah kepada siapa pun yang mengawasi prosesnya.

Jendela tidak mengatakan apa pun tentang seberapa sering pemeriksa dijalankan, dan tidak dapat memperpanjang autentikasi. Jika gateway mencabut sesi, atau akun kini menuntut faktor kedua yang baru, menunggu lebih lama tidak akan membuat sesi lama sah kembali. Percobaan ulang hanya berhasil ketika jalur kembali, gateway masih mengenali sesi, dan kredensial yang diminta tetap dapat dipakai, jadi bacalah angka itu sebagai tenggat, bukan sebagai interval keaktifan.

Jendela juga tidak mengatur apa yang dilakukan aplikasi selama ia berjalan. Bergantung pada platform dan sejauh mana kegagalan berlangsung, klien mungkin menyambung ulang dengan rute yang masih terpasang, atau setelah rute itu dicabut. Itulah sebabnya permintaan yang diajukan di tengah gangguan cenderung menggantung sampai batas waktu alih-alih gagal cepat.

Mulai ulang oleh supervisor dan percobaan ulang klien adalah dua lapisan

Biarkan klien yang berjalan menghabiskan jendelanya sendiri, dan biarkan manajer layanan menanggapi keluarnya. Klien di latar depan di bawah systemd dengan kebijakan mulai ulang memberikan tepat pembagian itu: percobaan selama periode terbatas, lalu satu keputusan mulai ulang. Hasilnya satu garis waktu yang masih bisa Anda rekonstruksi sesudahnya.

Klien di latar belakang plus pemeriksa mandiri yang memulai salinan lain ketika tidak melihat antarmuka adalah pola yang salah. Kedua proses lalu berebut simpul perangkat, rute, dan pengaturan resolver yang sama. Jika Anda memang ingin daemon, taruh opsi itu pada baris perintah yang benar-benar dipakai klien untuk mulai:

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

Dua perincian pada baris itu berbobot. --background melepaskan proses, sehingga berkas pid menjadi satu-satunya pegangan yang andal padanya, dan batas waktu hanya terpakai selama proses yang sama hidup; supervisor yang membunuhnya tidak menyisakan anggaran untuk melanjutkan.

Pemutusan yang disengaja membutuhkan sinyalnya sendiri. Jeda terencana dan gangguan sungguhan tampak sama bagi pengamat naif, keduanya terbaca sebagai «tidak tersambung». Kendalikan jeda lewat operasi berhenti milik supervisor, atau penanda yang dipahami pembungkusnya, agar penghentian yang disengaja tidak memicu mulai ulang yang tidak diminta siapa pun.

Mencegah penyerahan berlomba dengan lingkar percobaan ulang

Pemulihan tanpa pengawasan bergantung pada kredensial yang diperbarui tanpa kehadiran orang. Gelang kunci yang hanya terbuka di dalam sesi desktop interaktif, atau token yang selalu meminta kode yang diketik, akan membuat klien tertahan di tahap autentikasi begitu jalur kembali. Selesaikan alur kerja itu sebelum memperpanjang jendela, karena jendela yang lebih panjang hanya memberi permintaan yang terblokir itu lebih banyak waktu untuk gagal.

Verifikasi server tidak boleh dilonggarkan demi mengurangi permintaan. Pin atau jangkar kepercayaan yang memvalidasi gateway itulah yang membuat sambung ulang otomatis aman, dan mematikannya untuk menghindari pertanyaan sertifikat menukar gangguan yang terlihat dengan yang tak terlihat. Pertahankan identitas yang terverifikasi dan perbaiki permintaannya; klien yang bersedia menyambung ke gateway mana pun lebih buruk daripada klien yang berhenti dan menunggu.

Kehadiran antarmuka juga bukan sinyal kesehatan. Peranti terowongan bisa ada dengan sesi mati di belakangnya, dan proses peluncur bisa ada tanpa terowongan sama sekali. Tak satu pun pengamatan itu bertahan pada permintaan nyata. Kesehatan harus datang dari apa yang dibutuhkan pengguna, seperti permintaan yang menembus terowongan ke layanan internal yang dikenal.

Apa yang harus diverifikasi selama dan setelah gangguan

Jalankan empat peristiwa sebagai uji terpisah: gangguan yang lebih pendek dari jendela, gangguan yang lebih panjang darinya, kegagalan autentikasi, dan penghentian yang disengaja. Masing-masing harus berakhir pada keadaan berbeda yang dapat diprediksi, dan batas antara dua yang pertama adalah seluruh alasan memilih nilai.

Pertahankan pemeriksaan menghadap ke luar, karena tabel proses sendiri membuktikan sangat sedikit. Amati pid tetap stabil sepanjang gangguan pendek, lalu pastikan pid itu hilang dan diganti satu kali setelah 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)"

Selama gangguan pendek, pastikan klien benar-benar mencoba ulang alih-alih keluar lebih awal, dan bahwa rute serta entri resolver kembali tanpa duplikat. Untuk gangguan yang lebih panjang, pastikan keluarnya bersih dan tepat satu mulai ulang menyusul. Untuk kegagalan autentikasi, pastikan klien tidak berputar melawan gateway yang akan terus menolaknya. Tambahkan pemeriksaan bahwa pid kembali ke satu nilai alih-alih menumpuk.

Untuk penghentian yang disengaja, URL kesehatan harus tetap tak terjangkau dan prosesnya harus tetap mati. Lalu tutup lingkar dari sisi aplikasi: permintaan yang sama harus gagal selama terowongan tidak ada dan harus berhasil setelah kembali, dari alamat sumber yang diharapkan kebijakan Anda. Ikon terowongan hijau bukan bukti, tetapi permintaan yang tuntas adalah bukti.