VPN Putus Setelah Pembaruan DHCP? Bandingkan Alamatnya

Pembaruan sewa dan kegagalan VPN cukup sering muncul bersama di log sehingga orang menyimpulkan yang satu menyebabkan yang lain. Kebetulan waktunya nyata; kausalitasnya biasanya tidak. Pembaruan adalah permintaan unicast ke server yang menerbitkan sewa, meminta melanjutkan pengikatan yang sama, dan server dapat memperpanjangnya tanpa klien mengubah satu alamat pun. Menelusuri nilai klien sendiri di sekitar peristiwa memisahkan sewa yang diperbarui diam-diam dari jaringan yang benar-benar berubah di bawah terowongan yang berjalan.

Mulai dari klien yang putus

Buka log koneksi klien lebih dulu dan catat waktu putusnya sampai ke detik. Lalu buka log jaringan sistem operasi untuk menit yang sama dan baca berurutan apa yang dilakukan antarmuka. Urutan inilah seluruh penyelidikan: peristiwa DHCP sebelum terputus, terputus sebelum peristiwa DHCP, dan dua peristiwa tanpa apa pun di antaranya adalah tiga temuan berbeda. Baris log yang hanya menyebut sewa sementara terowongan sudah menyambung ulang adalah hiasan, bukan bukti.

Tulis garis waktu sambil berjalan alih-alih menyimpannya di ingatan. Stempel waktu dari alat berbeda jarang cocok sempurna, dan selisihnya sendiri kadang menjadi penjelasan.

Bandingkan empat nilai di sekitar peristiwa

Empat nilai cukup menggambarkan sisi lokal koneksi untuk menangkap perubahan nyata: alamat antarmuka, gateway default, daftar resolver, dan status operasional antarmuka. Ambil dalam satu menit setelah putus dan bandingkan dengan rekaman yang diambil saat terowongan sehat.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Alamat yang tidak berubah dengan gateway yang tidak berubah dan daftar resolver yang berubah mengarah ke penyelesaian nama, bukan perutean, dan terowongan mungkin bertahan sementara aplikasi berhenti menemukan host. Gateway yang berubah berarti jalur keluar dari jaringan lokal bergeser, dan itu cukup untuk membatalkan rute yang menunjuk ke gateway sebelumnya. Jika keempat nilai cocok dengan rekaman sehat, sewa bukan penyebab Anda dan logika penyambungan ulang klien sendiri menjadi pokoknya. Ambil perbandingan saat gangguan terlihat, karena rekaman sehat yang diambil setelah reboot punya riwayat alamat berbeda dan tidak akan cocok.

Apa yang bisa dan tidak bisa diubah pembaruan

RFC 2131 menjelaskan pembaruan sebagai permintaan ke server asli pada setengah masa sewa, dengan pengikatan ulang ke server mana pun pada tujuh per delapan jika percobaan pertama tidak dijawab. Tidak ada langkah yang menuntut klien memperoleh alamat berbeda, dan server yang kooperatif biasanya memperpanjang pengikatan yang ada. Perubahan alamat sungguhan biasanya datang lewat jalur lain: server menolak pembaruan, klien kehilangan statusnya dan memulai ulang, atau jaringan memindahkan perangkat ke segmen lain.

Sisi publik koneksi bisa berubah tanpa perubahan lokal sama sekali. Di balik penerjemahan kelas operator, alamat yang dilihat rekan VPN dapat dialokasikan ulang secara independen dari apa pun yang dilakukan sewa lokal, dan pengalokasian ulang itu tampak identik dengan kegagalan jaringan lokal dari dalam klien. Membandingkan alamat yang dilaporkan secara lokal dengan pengamatan dari sisi rekan adalah satu-satunya cara memisahkannya.

Ketika klien gagal beradaptasi

Klien yang mengikat transpor ke alamat lama, menyimpan rute usang ke rekan, atau menyimpan identitas antarmuka mungkin terus mencoba jalur yang tidak ada lagi. Itu cacat adaptasi, dan terlihat sebagai pengiriman ulang berulang ke alamat yang tidak lagi bisa dijangkau host. Sebagian klien menanganinya secara desain: WireGuard, misalnya, memperbarui titik akhir rekan ketika paket yang terautentikasi dengan benar datang dari sumber baru.

Mulai ulang manual yang memulihkan layanan adalah petunjuk di mana adaptasi gagal, bukan bukti bahwa sewa dan terowongan tidak kompatibel. Pertahankan kebijakan pemblokiran saat pengujian, atau pengujian itu sendiri menjadi gangguan dengan sebab lain. Catat apakah klien pulih sendiri, berapa lama, dan alamat mana yang dicoba lagi; urutan itu memberi tahu Anda lebih banyak daripada alasan terputus yang ditampilkan di antarmuka.

Ulangi peristiwanya sebelum menyalahkannya

Reproduksi kondisinya alih-alih menunggu jadwal: lepaskan dan perbarui sewa, atau paksakan peristiwa terkendali yang setara, dan amati apakah terowongan bertahan. Di jaringan terkelola, koordinasikan setiap perubahan alamat dengan pemilik jaringan, karena penetapan statis sembarangan dapat bertabrakan dengan perangkat yang sudah memegang alamat itu.

Setelah perbaikan yang didukung, ulangi peristiwa yang sama lalu uji aplikasi dan pencarian nama, karena terowongan yang menyambung ulang tetapi merusak DNS lulus uji yang lebih lemah daripada yang penting. Laporkan perubahan spesifik yang Anda amati, dengan stempel waktunya, alih-alih menyebut sewa terjadwal sebagai penyebab. Perbedaan antara kedua laporan itu adalah apakah orang berikutnya dapat mereproduksi gangguan atau hanya desas-desusnya.