VPN macet setelah router di-reboot: tiga hal yang berubah

Router selesai melakukan boot, laptop bergabung lagi ke SSID yang sama, dan VPN tetap dalam keadaan terhubung tanpa ada yang bergerak. Profil tersimpan masih utuh. Yang kedaluwarsa di bawahnya adalah jalur, dan klien masih memegang status yang dibangunnya untuk jalur lama.

Tiga kondisi menentukan perbaikannya. Periksa berurutan, karena yang belakangan hanya membuang tenaga jika yang pertama sudah menjelaskan macetnya.

Kondisi satu: alamat lokal berubah

Reboot dapat memberikan alamat lain kepada mesin. VPN yang dikonfigurasi dengan titik akhir lokal tetap lalu terus memakai sambungan yang sudah tidak ada. Hal yang sama berlaku bagi klien yang mengikat soketnya ke alamat lama. Antarmuka terowongan dapat tetap naik sementara setiap paket yang dihasilkannya pergi ke tempat yang tidak berguna.

Bandingkan alamat yang dipakai klien dengan alamat yang dipegang antarmuka saat ini. Rute default yang menunjuk ke gateway yang juga berubah adalah jenis masalah yang sama dengan nama lain.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Kondisi dua: pemetaan terjemahan hilang

Router rumah menerjemahkan aliran keluar, dan pemetaan itu hidup di memori. Reboot menghapus semuanya. Itu tidak berbahaya bagi koneksi baru dan fatal bagi terowongan yang percaya aliran yang ada masih sah. Lalu pihak seberang tidak melihat apa pun, sehingga klien tidak pernah menerima kesalahan yang bisa ditindaklanjuti.

Di sinilah terowongan tanpa keepalive macet diam-diam alih-alih gagal dengan berisik. Batasan terdokumentasi WireGuard menggambarkan bentuk kegagalan yang sama. Status titik akhir yang salah menghasilkan paket yang dibuang, bukan diagnosis.

Keepalive persisten 25 detik adalah mitigasi yang lazim, karena menyegarkan pemetaan sebelum batas waktu diam dapat berakhir. Itu tidak memperbaiki pemetaan yang sudah hilang. Pasangkan keepalive dengan logika penyambungan ulang alih-alih memperlakukannya sebagai perbaikan.

Kondisi tiga: alamat publik berubah

Jika alamat eksternal router itu sendiri berubah, apa pun di seberang yang menyaring berdasarkan alamat sumber kini melihat rekan yang berbeda. Terowongan dapat naik dan server tetap membuang lalu lintas, yang terlihat seperti klien rusak dan sebenarnya kebijakan di ujung lain.

Catat alamat eksternal sebelum dan sesudah reboot. Ketika keduanya berbeda, pertanyaannya berpindah dari klien ke siapa pun yang memelihara daftar izin, dan menyetel ulang kredensial di laptop tidak dapat menolong.

Pulihkan dengan urutan yang benar

Selesaikan dulu setiap proses masuk captive portal yang diperlukan, lalu biarkan klien menyambung ulang lewat prosedur yang didukungnya alih-alih mematikan prosesnya. Amati apakah identitas dan lalu lintas data keduanya pulih, karena itu dua tahap berbeda dari koneksi yang sama.

Halaman yang di-cache tidak membuktikan apa pun, begitu pula aplikasi obrolan yang menyambung ulang sendiri. Uji titik akhir yang benar-benar Anda pedulikan dengan permintaan baru. Pertahankan kebijakan lalu lintas langsung selama gangguan, karena upaya penyambungan ulang bukan pemblokiran.

Ketika ini berulang setelah setiap reboot, catatan lebih penting daripada percobaan ulang. Catat alamat lokal, gateway, alamat eksternal, dan status klien sebelum dan sesudah, lalu bandingkan kedua kolom. Itu mengubah keluhan kabur menjadi bug siklus hidup yang dapat diperbaiki seseorang, dan menghentikan penggantian sertifikat untuk ketiga kalinya gara-gara batas waktu pemetaan.