Mengapa VPN Anda lebih lama pulih daripada pemutusannya

Wi-Fi kembali tiga puluh detik lalu dan VPN masih mati, jadi klien tampak rusak. Sering kali ia hanya mengikuti jadwal coba ulangnya sendiri, dan jadwal itu tidak tahu jaringan baru saja kembali. Selisih itulah seluruh ceritanya: waktu pemulihan adalah pemutusan ditambah jeda apa pun yang sudah disetujui klien. Menurunkan setiap timer adalah satu jawaban, dan memahami timer mana yang penting adalah jawaban lainnya.

Tiga kondisi menentukan apakah penyetelan membantu: tahap mana yang lambat, apakah kegagalan bisa dicoba ulang sama sekali, dan bagaimana klien mengetahui jaringan sudah kembali.

Tiga penantian yang tampak seperti satu

Resolusi titik akhir, negosiasi IKE atau TLS, pengiriman ulang paket, dan memulai percobaan baru adalah peristiwa terpisah dengan timer terpisah. strongSwan mendokumentasikan mundur pengiriman ulang untuk IKE, dan OpenVPN punya kendali coba ulang sendiri dengan semantik berbeda. Menyalin angka dari satu ke yang lain mengasumsikan mekanismenya sama, padahal tidak. Baca urutan log sebelum memutuskan interval mana yang sedang Anda lihat.

Satu menit sunyi di log belum tentu proses yang membeku. Itu bisa jadi mundur eksponensial yang melakukan tepat seperti yang dikonfigurasi.

Tahap mana yang sebenarnya lambat?

Jika log menunjukkan percobaan gagal dengan galat autentikasi, tidak ada perubahan timer yang membantu, karena kredensialnya salah. Jika percobaan sama sekali tidak dilakukan, klien berada di dalam jendela tunggunya dan jadwal adalah solusinya. Jika percobaan dilakukan dan waktu habis, masalahnya adalah keterjangkauan atau pendengar yang hilang, dan mencoba lebih cepat hanya memenuhi log. Ketiga keadaan itu punya pemilik berbeda, dan hanya satu yang merupakan masalah waktu.

Klasifikasikan kegagalan sebelum Anda menyentuh angka.

Kapan menurunkan timer membantu, dan kapan tidak

Turunkan batas atas coba ulang ketika biaya dominan adalah menunggu setelah pemutusan singkat yang sering, seperti laptop yang berpindah antar titik akses. Biarkan saja ketika kegagalan panjang atau jarang, karena mencoba ulang agresif menambah beban tepat pada saat konsentrator paling tidak mampu menjawab. Dalam kedua kasus, ubah satu parameter, catat, dan ukur pemulihan berikutnya alih-alih menganggapnya membaik.

Waktu tunggu yang sangat rendah yang disalin ke setiap profil adalah keadaan akhir biasa dari penyetelan tanpa pengukuran.

Periksa kesiapan sebelum menyalahkan klien

Klien sering tidak bisa melihat jaringan sudah bisa dipakai sampai ada sesuatu yang mencoba. Portal tawanan, pembaruan DHCP, atau perubahan rute bisa membuatnya menunggu jadwal yang ditetapkan sebelum semua itu terjadi. Amati perubahan status jaringan sistem operasi dan percobaan klien berikutnya pada jam yang sama, dan Anda akan melihat siapa yang menunggu. Versi cepatnya adalah mencatat stempel waktu peristiwa jaringan siap dan stempel waktu percobaan pertama setelahnya.

Pastikan juga lalu lintas langsung masih diblokir selama penantian, karena sambung ulang yang lebih cepat tetapi membocorkan lalu lintas bukan perbaikan.

Apa yang perlu dicatat

Tuliskan timer mana yang berubah, dari nilai apa ke nilai apa, dan bagaimana pemulihannya sesudahnya. Catat juga versi klien, karena nilai bawaan bergeser antar rilis dan waktu tunggu sangat rendah yang tidak terdokumentasi akan membingungkan orang berikutnya yang membaca profil.

Catatan itu mengubah peningkatan perangkat lunak berikutnya menjadi perbandingan, bukan eksperimen.