VPN mati setelah tidur: terowongan hilang atau aplikasi basi?

Tutupnya dibuka, ikon nirkabel kembali, dan VPN masih tampil terhubung. Halaman internal pertama lalu menggantung sampai waktu habis, dan tab baru melakukan hal yang sama. Tiga hal berbeda dapat menghasilkan gambaran itu dan membutuhkan tiga perbaikan berbeda: terowongan yang tidak bertahan dari tidur, profil yang tidak diminta siapa pun untuk aktif kembali, atau aplikasi yang masih memegang sesi yang mati berjam-jam lalu. Membandingkannya lebih cepat daripada memasang ulang apa pun.

Tiga hal bisa rusak setelah bangun

Kandidat pertama adalah terowongannya sendiri. Antarmuka bisa masih ada dengan alamat sementara asosiasi dengan peer sudah hilang, karena itu lampu indikator bukan bukti jalur yang berfungsi. Jabat tangan yang lebih tua daripada tidur adalah petunjuknya, dan satu perintah cukup untuk melihatnya.

Yang kedua adalah aktivasi. Banyak klien menyambung ulang sendiri; sebagian tidak, dan profil yang tidak diminta kembali akan duduk di sana tampak terkonfigurasi. Kegagalan itu senyap secara desain, karena tidak ada yang memberikan galat.

Yang ketiga adalah aplikasi. Tab peramban, sesi SSH, atau koneksi basis data dapat bertahan dari perubahan jaringan sebagai deskriptor berkas sementara transport di bawahnya mati. Sesi baru lalu bekerja sempurna, yang memberi tahu Anda terowongannya baik-baik saja sejak awal.

Bandingkan ketiganya sebelum mengubah apa pun, karena perbaikannya tidak tumpang tindih. Memulai ulang klien yang tak pernah diminta menyala lagi membuang bukti yang Anda butuhkan. Catat kandidat mana yang cocok dengan gejalanya sebelum menyentuh konfigurasi. Satu kalimat itu biasanya menentukan sisa penyelidikan.

Pertama: apakah terowongannya kembali?

Lihat antarmuka dan keadaan peer, bukan teks status klien sendiri. Antarmuka dengan alamat dan tanpa jabat tangan terbaru adalah terowongan yang hanya ada namanya.

ip -brief addr show
wg show
ip route show table all | head -20

Jika antarmukanya tidak ada sama sekali, terowongan tidak bertahan dan pertanyaannya menjadi siapa yang seharusnya mengembalikannya. Jika ada tetapi jabat tangannya tua, asosiasi dengan peer perlu dibangun ulang, dan klien mungkin menunggu lalu lintas untuk memicunya.

Periksa juga rute dan konfigurasi DNS. Terowongan bisa kembali tanpa rutenya, yang menghasilkan keadaan membingungkan ketika antarmuka menyala dan nama internal masih diselesaikan lewat server yang salah.

Kedua: apakah ada yang memintanya kembali?

Di sinilah perbandingan itu berbayar. Profil plugin OpenVPN dan koneksi WireGuard asli ditangani berbeda oleh NetworkManager, dan referensi pengaturan koneksi menyatakan jelas bahwa connection.autoconnect tidak mengaktifkan profil VPN; mekanisme untuk mengangkat VPN bersama koneksi adalah connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Jika menyambung ulang secara manual memperbaiki masalahnya setiap kali, itu tanda aktivasi yang hilang dan bukan terowongan yang rusak. Log biasanya akan menunjukkan antarmuka turun dan tidak ada yang mengembalikannya.

Tahan dorongan untuk segera menambahkan hook tidur. Hook yang menyala sebelum jaringan pulih berlomba dengan proses yang justru ingin dibantunya, dan mengubah masalah yang dapat direproduksi menjadi berkala.

Ketiga: apakah aplikasi memegang keadaan lama?

Buka sesi yang benar-benar baru ke tujuan yang sama sebelum menyentuh VPN. Jika sesi baru bekerja dan yang lama tidak, terowongannya baik dan aplikasi memegang koneksi mati.

Ini yang termurah dari tiga pemeriksaan dan yang paling sering dilewati, karena jendela yang gagal ada tepat di layar. Tutup, buka lagi, dan catat apakah masalahnya bertahan. Jika sesi baru bekerja, hentikan penyelidikan terowongan sepenuhnya. Jika itu juga gagal, aplikasi adalah gejala, bukan penyebab.

Sebagian aplikasi pulih sendiri setelah waktu habis, karena itu gejalanya bisa tampak membaik sendiri setelah beberapa menit. Perilaku itu menunjuk ke aplikasi dan bukan ke terowongan, dan layak dicatat terpisah. Rekan yang melaporkan bahwa semuanya sembuh sendiri sedang menggambarkan pola ini, bukan keberuntungan.

Buat perbandingannya dapat direproduksi

Jaga variabelnya kecil: satu jaringan akses, satu durasi tidur, dan permintaan pertama yang sama setiap kali. Lalu catat dua hasil: apakah menyambung ulang secara manual memperbaikinya, dan apakah tidur lain memunculkan kegagalannya lagi.

Pengamatan terakhir itulah yang paling andal memisahkan ketiga kandidat. Sesi baru yang bekerja setelah sesi lama gagal bukan masalah terowongan, dan pemasangan ulang klien tidak akan mengubahnya.

Keepalive persisten WireGuard hanya masuk dalam gambaran ini sebagai keepalive pemetaan NAT. Ia mengirim paket untuk menjaga pemetaan tetap terbuka; ia tidak mencegah mesin tidur dan tidak dapat terus mengirim selama prosesnya ditangguhkan.

Catat di tiket apa yang Anda temukan: mana dari ketiganya yang rusak, apa yang memperbaikinya, dan bagaimana Anda mereproduksinya. Orang berikutnya yang membuka tutup pada hari Senin akan berterima kasih, dan jawabannya tidak perlu ditemukan ulang dari nol.