VPN terputus apabila skrin dimatikan: kitaran hayat yang mana?

Pemindahan berhenti pada saat skrin menjadi gelap, dan lencana menyusul beberapa saat kemudian. Tiga perkara berbeza menghasilkan gambaran itu: proses klien dihadkan, laluan menjadi diam dan kehilangan pemetaannya, atau aplikasi kehilangan sesi yang tidak pernah disedari terowong. Setiap satu mempunyai buktinya sendiri, dan setiap pembaikan tergolong dalam lapisan berbeza. Urutan di bawah memisahkannya dengan satu ujian terkawal dan bukan menelusuri semua tetapan.

Tiga kegagalan yang kelihatan sama

Proses latar belakang yang dihadkan berhenti menghantar keepalive, dan pihak lain akhirnya mengisytiharkan terowong mati. Pemetaan diam pada laluan boleh luput semasa peranti tidur, jadi trafik pulangan tidak pernah sampai kepada klien yang masih hidup sepenuhnya. Aplikasi boleh kehilangan sambungannya sendiri semasa terowong kekal naik, yang menghasilkan dialog ralat dengan lencana VPN sihat di belakangnya. Dari sudut pengguna, ketiga-tiganya dibaca sebagai VPN terputus semasa skrin dimatikan.

Perbezaan itu penting kerana penyelesaiannya bercanggah dalam amalan. Pengecualian klien daripada sekatan kuasa membaiki kes pertama dan tidak berbuat apa-apa untuk pemetaan yang telah luput. Memanjangkan keepalive membaiki kes kedua dan membazirkan bateri dalam kes ketiga, di mana tiada apa-apa berkaitan rangkaian yang salah pada mulanya.

Bandingkan aktif dan diam di bawah kawalan

Kekalkan semuanya: peranti sama, rangkaian sama, titik akhir sama, aplikasi sama. Kunci skrin untuk selang pendek yang tetap dan catat tiga pemerhatian: sama ada klien melaporkan pemutusan, sama ada permintaan baharu berfungsi semasa buka kunci, dan sama ada pemindahan sedia ada disambung semula. Kemudian ulangi dengan keepalive atau permintaan berkala berjalan dan bandingkan kedua-dua larian. Satu pemboleh ubah yang berubah antara dua larian lebih bernilai daripada seminggu laporan anekdot.

Masa tergolong dalam rekod. Putus selepas sembilan puluh saat berbau pemetaan atau selang keepalive, manakala putus pada saat kunci menunjukkan penggantungan proses. Catat pencetus dan selangnya, kerana percubaan seterusnya memerlukan sesuatu untuk dibandingkan.

Baca dasar latar belakang platform

Pada Android, kitaran hayat perkhidmatan VPN ialah sebahagian daripada platform, dan always-on serta block-without-VPN ialah suis berasingan dengan kesan berasingan. Klien yang bukan always-on boleh dihentikan apabila sistem mengambil semula sumber, dan tiada tetapan dalam aplikasi mengubahnya. iOS menggunakan had latar belakangnya sendiri pada penyedia terowong, dan tingkah laku yang didokumenkan berbeza daripada daemon desktop yang terus berjalan. Baca dokumentasi platform untuk komponen berkenaan, bukan panduan pengoptimuman bateri generik.

Peranti terurus menambah satu lagi lapisan. Dasar boleh mengatasi tetapan peribadi, jadi perubahan yang kelihatan berjaya kembali semula pada penyegaran dasar seterusnya. Gunakan proses pengecualian yang disokong organisasi jika keperluan itu benar, dan catat mengapa pengecualian itu wujud.

Apa yang peranti lakukan selepas bangun

Sambung semula automatik bukanlah sama dengan menyekat trafik semasa jurang. Periksa kedua-duanya: sama ada terowong kembali, dan sama ada aplikasi yang cuba menghantar semasa jurang keluar tanpa perlindungan. Klien yang bersambung semula dalam dua saat tetapi membocorkan pertanyaan DNS pada saat pertama mempunyai dasar kegagalan yang salah untuk peranti kerja. Uji dengan permintaan tidak berbahaya dan destinasi yang anda kawal.

Pemulihan aplikasi ialah soalan ketiga. Terowong yang kembali tidak membaiki sesi SSH yang tamat masa, dan pengguna sering melaporkan kehilangan sesi itu sebagai kegagalan VPN. Simpan pencetus, binaan klien dan masa tepat bersama-sama dalam laporan, kerana gabungan itu memisahkan kitaran hayat mati skrin yang boleh dijangka daripada pelayan yang gagal secara bebas daripada peranti.