Mengapa VPN anda lebih lama pulih daripada gangguan itu

Wi-Fi kembali tiga puluh saat lalu dan VPN masih mati, jadi klien kelihatan rosak. Selalunya ia hanya mengikut jadual cubaan semulanya sendiri, dan jadual itu tidak tahu rangkaian baru sahaja kembali. Jurang itulah keseluruhan cerita: masa pemulihan ialah gangguan ditambah sebarang tunggu yang sudah diterima klien. Menurunkan setiap pemasa ialah satu jawapan, dan memahami pemasa mana yang penting ialah jawapan yang lain.

Tiga syarat menentukan sama ada pelarasan membantu: peringkat mana yang perlahan, sama ada kegagalan boleh dicuba semula, dan bagaimana klien tahu rangkaian sudah kembali.

Tiga tunggu yang kelihatan seperti satu

Peleraian titik akhir, rundingan IKE atau TLS, penghantaran semula paket dan memulakan percubaan baharu ialah peristiwa berasingan dengan pemasa berasingan. strongSwan mendokumenkan mundur penghantaran semula untuk IKE, dan OpenVPN mempunyai kawalan cubaan semulanya sendiri dengan semantik berbeza. Menyalin nombor dari satu ke satu yang lain menganggap mekanismenya sama, tetapi ia tidak sama. Baca urutan log sebelum memutuskan selang mana yang anda lihat.

Seminit senyap dalam log bukan semestinya proses yang beku. Ia mungkin mundur eksponen yang melakukan tepat seperti yang dikonfigurasikan.

Peringkat mana yang sebenarnya perlahan?

Jika log menunjukkan percubaan gagal dengan ralat pengesahan, tiada perubahan pemasa membantu, kerana kelayakan itu salah. Jika tiada percubaan dibuat langsung, klien berada dalam tetingkap tunggunya dan jadual ialah penyelesaiannya. Jika percubaan dibuat dan tamat masa, masalahnya ialah kebolehcapaian atau pendengar yang tiada, dan cuba semula lebih cepat hanya memenuhi log. Setiap tiga keadaan itu mempunyai pemilik berbeza, dan hanya satu daripadanya masalah pemasaan.

Kelaskan kegagalan sebelum anda menyentuh nombor.

Bila menurunkan pemasa membantu, dan bila tidak

Turunkan had cubaan semula apabila kos utama ialah menunggu selepas gangguan pendek yang kerap, seperti komputer riba yang bergerak antara titik akses. Biarkan ia apabila kegagalan panjang atau jarang, kerana cubaan semula agresif menambah beban tepat pada saat konsentrator paling kurang mampu menjawab. Dalam kedua-dua kes, ubah satu parameter, catatkannya, dan ukur pemulihan seterusnya daripada menganggap ia bertambah baik.

Tamat masa yang sangat rendah yang disalin ke setiap profil ialah keadaan akhir biasa pelarasan tanpa pengukuran.

Periksa kesediaan sebelum menyalahkan klien

Klien selalunya tidak dapat melihat rangkaian boleh digunakan sehingga sesuatu mencuba. Portal tawanan, pembaharuan DHCP atau perubahan laluan boleh membiarkannya menunggu jadual yang ditetapkan sebelum semua itu berlaku. Perhatikan perubahan keadaan rangkaian sistem pengendalian dan percubaan klien seterusnya pada jam yang sama, dan anda akan melihat siapa yang menunggu. Versi pantas ialah mencatat cap masa peristiwa rangkaian sedia dan cap masa percubaan pertama selepasnya.

Sahkan juga bahawa trafik langsung masih disekat semasa menunggu, kerana sambung semula yang lebih cepat tetapi membocorkan trafik bukan peningkatan.

Apa yang perlu dicatat

Tulis pemasa mana yang berubah, dari nilai apa ke nilai apa, dan bagaimana pemulihan kelihatan selepas itu. Catat versi klien juga, kerana nilai lalai bergerak antara keluaran dan tamat masa yang sangat rendah tanpa dokumentasi akan mengelirukan orang seterusnya yang membaca profil.

Catatan itu menjadikan peningkatan perisian seterusnya perbandingan dan bukan eksperimen.