VPN putus saat layar gelap: kunci, layar mati, atau suspend?

Ketika seseorang berkata VPN mati saat layar menjadi gelap, pertanyaan berguna pertama adalah peristiwa mana dari tiga yang sebenarnya terjadi: sesi terkunci, panel dimatikan, atau seluruh mesin tertidur. Itu mekanisme terpisah pada pengatur waktu terpisah, dan hanya satu di antaranya yang dapat sepenuhnya mencegah sebuah proses dijadwalkan. Telusuri pemeriksaan di bawah ini secara berurutan. Berhenti pada yang pertama yang menjawab pertanyaan, karena setiap pemeriksaan setelahnya menjawab hal lain.

Pemeriksaan satu: pisahkan kunci dari layar mati dan dari tidur

Kunci mengubah siapa yang boleh memakai sesi; kompositor terus menggambar, tumpukan jaringan terus berjalan, dan klien VPN tidak menyadari apa pun. Peredupan layar mematikan panel setelah selang waktu tidak aktif dan membiarkan mesin sepenuhnya bangun. Suspend menghentikan CPU, yang berarti tidak ada proses ruang pengguna yang dijadwalkan, sehingga tidak ada keepalive yang dapat berjalan, sependek apa pun selang yang Anda atur.

Tabel itulah sebabnya «layar menjadi gelap» bukan diagnosis. Desktop yang diatur meredup pada lima menit dan suspend pada tiga puluh akan menampilkan layar gelap pada menit keenam dengan terowongan yang sepenuhnya sehat. Kegagalan pada menit ketiga puluh adalah peristiwa lain dengan perbaikan lain, dan keduanya tampak sama dari seberang ruangan.

Pemeriksaan dua: letakkan peristiwa daya dan jaringan pada satu garis waktu

Baca jurnal untuk jendela terbatas alih-alih seluruh proses boot, dan sertakan baik manajer login maupun pemilik koneksi:

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

Perintah pertama menunjukkan permintaan tidur, bangun, dan transisi jaringan yang menyusul. Yang kedua menunjukkan apa yang saat ini memegang kunci penghambat, yang memberi tahu Anda apakah ada sesuatu yang sengaja memblokir tidur dan program mana itu. Sesuaikan nama unit jika pemilik koneksi Anda bukan NetworkManager, dan ingat bahwa membaca unit pengguna lain atau jurnal sistem bergantung pada kebijakan lokal.

Baris yang hilang bukan hasil negatif. Jika jurnal unit yang dipilih tidak terlihat oleh akun Anda, tidak adanya catatan tidur tidak membuktikan apa pun, dan menyimpulkan «mesin itu tidak pernah tidur» dari filter kosong adalah cara orang menghabiskan seminggu menyetel keepalive.

Pemeriksaan tiga: jika mesin tertidur, putuskan apakah itu memang disengaja

Begitu transisi tidur muncul di garis waktu, pertanyaannya berubah dari mengapa VPN rusak menjadi apakah mesin seharusnya tidur sama sekali. Pada laptop jawabannya sering ya, dan putusnya terowongan adalah perilaku yang diharapkan yang harus dipulihkan klien saat bangun. Pada stasiun kerja yang seharusnya tetap dapat dijangkau, kebijakan tidurlah yang harus diubah. Menentukan mesin mana dari dua ini yang Anda hadapi memerlukan satu pertanyaan, dan itu bukan pertanyaan yang dapat dijawab jurnal untuk Anda.

Ubah melalui kontrol yang menjadi milik sesi yang sedang login, atau melalui mekanisme yang didukung administrator jika persyaratannya berlaku untuk seluruh mesin. Mengedit pengaturan manajer tampilan saat Anda login sebagai akun lain bukan tindakan yang sama dan akan tampak berhasil sampai sesi berikutnya dimulai. Menonaktifkan manajemen daya sepenuhnya adalah reaksi pertama yang luas yang memakan masa pakai baterai dan menyembunyikan pertanyaan kebijakan yang sebenarnya.

Pemeriksaan empat: jika mesin tetap bangun, lihat jaringan dan klien

Mesin yang bangun tetapi kehilangan terowongannya memiliki salah satu dari tiga cerita: jaringan akses putus, klien VPN berhenti atau dimulai ulang, atau sisi server membiarkan asosiasi kedaluwarsa sementara klien terus percaya bahwa ia terhubung. Bandingkan stempel waktu peristiwa tautan yang mendasari dengan peristiwa terowongan, dan tepatlah tentang mana yang datang lebih dulu.

Lalu uji jalur pemulihan secara terpisah dari sesi aslinya. Permintaan baru melalui terowongan yang pulih dapat berhasil sementara sesi aplikasi berumur panjang yang dibuka sebelum pemutusan tetap rusak, karena aplikasi memegang soket basi atau alamat yang di-cache. Itu masalah aplikasi, bukan bukti bahwa terowongan gagal kembali.

Apa isi laporan yang berguna

Tuliskan urutannya dengan stempel waktu dan pemilik: kapan sesi terkunci, kapan layar meredup, apakah permintaan tidur tercatat, kapan tautan putus dan kembali, kapan terowongan berubah status, dan apa yang sebenarnya dilakukan aplikasi. Setiap butir punya pemilik, jadi setiap butir dapat diserahkan kepada orang yang tepat alih-alih menjadi keluhan umum tentang Linux.

Jika salah satu baris itu hilang, itulah hal berikutnya yang harus diukur, bukan hal berikutnya yang harus diubah. Garis waktu dengan celah lebih informatif daripada perubahan pengaturan yang dilakukan berdasarkan dugaan.