vpn.persistent terus mencoba, tetapi tidak membuat Anda tetap terhubung

NetworkManager mengekspos satu properti, vpn.persistent, dan orang memintanya menjawab empat pertanyaan berbeda sekaligus. Dokumentasi hulunya cermat: persistensi berlaku ketika layanan VPN mendukungnya dan profil mengaktifkannya, lalu koneksi diminta bertahan melewati perubahan tautan dan pemadaman sampai pemutusan eksplisit. Dokumentasi yang sama juga menunjukkan bahwa nilai bawaan properti adalah false, yang bukan asumsi sebagian besar rencana pemulihan. Bacalah sebagai permintaan untuk mencoba, bukan janji hasil.

Apa yang sebenarnya dijanjikan pengaturan ini

Nilai yang disimpan dalam profil adalah instruksi bagi manajer, dan manajer harus menyerahkan instruksi itu kepada plugin VPN yang tahu apa yang harus dilakukan dengannya. Jika plugin yang terpasang mengabaikan properti itu, profil tetap aktif dan log tetap sunyi, yang merupakan yang terburuk dari dua dunia bagi siapa pun yang kelak men-debug. Tidak ada apa pun di dalam profil yang dapat memaksa plugin menerapkan perilaku yang tidak dimilikinya, sehingga satu-satunya hasil yang terlihat adalah ketiadaan.

Itulah sebabnya syarat dalam dokumentasi lebih penting daripada tombolnya. Periksa plugin dan rilis mana yang benar-benar Anda miliki, lalu tulis versinya di samping deskripsi koneksi agar orang berikutnya tidak perlu menemukannya lagi. Kebijakan pemulihan yang dibangun di atas bendera yang belum diterapkan gagal tepat sekali di produksi dan selalu pada saat paling tidak nyaman.

Memperlakukan properti sebagai percobaan juga menetapkan ekspektasi yang tepat untuk pengujian. Anda tidak memeriksa apakah bendera sudah disetel; Anda memeriksa apakah ada sesuatu yang terjadi saat tautan putus. Itu eksperimen yang berbeda, dan hanya satu di antaranya layak menghabiskan satu sore.

Empat pertanyaan yang dilebur menjadi satu

Aktivasi bertanya apa yang menyalakan VPN sejak awal. Profil NetworkManager dapat diikat ke koneksi dasar, layanan OpenVPN yang dikelola terpisah memiliki startup sendiri, dan menambahkan peluncur ketiga ke susunan itu memberi Anda dua pemilik dengan gagasan berbeda tentang siapa yang berwenang. Putuskan komponen mana yang memiliki startup sebelum menambahkan pemicu lain.

Pemulihan bertanya apa yang terjadi ketika tautan berubah atau hilang, dan itulah pertanyaan sempit yang ditangani vpn.persistent. Keaktifan bertanya apakah klien dapat mengetahui bahwa ujung jauh berhenti menjawab, dan perilaku keepalive atau mulai ulang OpenVPN menjawabnya sebagai gantinya; kedua mekanisme itu sering dijelaskan dengan kata yang sama dan diterapkan di tempat berbeda. Uji keduanya secara terpisah, dengan alat berbeda, atau Anda akan mengaitkan satu perilaku ke perilaku lainnya.

Niat bertanya apakah sambung ulang memang diinginkan, dan itulah pertanyaan yang tidak dapat dijawab oleh jajak status. Penghentian yang disengaja dan pemadaman menghasilkan keadaan tidak aktif yang sama, jadi apa pun yang menyambung ulang karena ketiadaan sedang menebak keputusan manusia. Menebak tidak masalah sampai saat ia mengesampingkan seseorang.

Daftar periksa yang memisahkannya

Jalankan peristiwanya secara berurutan alih-alih membaca konfigurasi dan menalar tentangnya, dan catat apa yang ditunjukkan masing-masing dengan stempel waktu.

Pertama, aktifkan koneksi dasar yang dimaksud dan pastikan VPN naik melalui pemicu yang Anda harapkan, bukan melalui mekanisme yang lupa Anda pasang. Kedua, selama gangguan yang disetujui, bandingkan peristiwa VPN manajer, keadaan pemulihan klien pemilik, dan permintaan baru ke sumber daya privat. Ketiga, putuskan dengan sengaja, tunggu, dan pastikan tidak ada yang memulai ulang profil di belakang Anda.

Langkah ketiga adalah yang dilewati orang, dan itulah yang paling sering menemukan cacat sebenarnya. Pengawas yang menjajaki profil aktif dan menyambung ulang saat profil itu tidak ada akan dengan senang hati membatalkan pemutusan yang disengaja pengguna. Dari sudut pandang pengguna itu bukan ketahanan; itu mesin yang tidak mau menuruti. Tanyakan kepada mereka sebelum menambahkan satu.

Tulis hasilnya ke dokumen yang sama dengan deskripsi koneksi. Kebijakan pemulihan hanya sebaik terakhir kali seseorang melihatnya gagal dengan sengaja. Stempel waktu membuat perbedaannya terlihat bagi siapa pun yang membaca catatan berikutnya.

Autentikasi adalah bagian dari pemulihan

Menyambung ulang bukan tindakan jaringan semata. Jika alur yang disetujui membutuhkan tantangan baru, kode sekali pakai, atau rahasia yang tidak dapat dijangkau konteks aktivasi, tidak ada pengaturan persistensi yang dapat menghasilkannya dari ketiadaan.

Itu menjelaskan pola yang akrab: koneksi pulih di mesin dengan gantungan kunci yang terbuka dan gagal di mesin yang sama setelah reboot. Lapisan jaringan melakukan tepat apa yang diminta dan lapisan kredensial tidak punya apa pun untuk ditawarkan.

Perbaiki alur kerja kredensial alih-alih memperpendek interval percobaan ulang. Percobaan ulang yang lebih cepat terhadap permintaan yang tidak dapat dijawab siapa pun menghasilkan kebisingan log dan kesan palsu bahwa sesuatu sedang dicoba.

Persistensi bukan kill switch

Properti ini berusaha mempertahankan atau memulihkan hubungan VPN. Ia tidak memutuskan apa yang boleh dilakukan aplikasi saat VPN mati, dan ia sendiri tidak memblokir apa pun.

Jika persyaratannya adalah tidak ada lalu lintas yang keluar dari terowongan, itu kebijakan terpisah dengan mekanismenya sendiri, pengujiannya sendiri, dan mode kegagalannya sendiri. Menganggap persistensi mencakupnya mengubah keputusan keamanan menjadi kecelakaan.

Catat kedua belah pihak dalam catatan pemulihan: apa yang dicoba VPN, dan lalu lintas aplikasi apa yang diizinkan selama percobaan berlangsung.