IP WAN berubah dan terowongan putus: pemeriksaan secara berurutan

Terowongan putus, router mencatat sambungan ulang, dan tidak ada yang bergerak di LAN. Alamat WAN baru membatalkan koneksi luar tanpa mengubah apa pun di dalam: alamat sumber klien berubah, status NAT lama menunjuk ke sumber yang sudah tidak ada, dan peer jarak jauh mungkin masih mengirim ke alamat sebelumnya. Pemulihan adalah perilaku normal, dan pertanyaan yang berguna adalah status mana yang gagal diperbarui.

Beri nama peristiwanya sebelum membaca log

Periksa apa yang sebenarnya terjadi di lapisan akses. Pembaruan sewa dari penyedia layanan adalah satu peristiwa. Sesi PPPoE yang tersambung ulang adalah peristiwa lain. Modem serat yang dihidupkan ulang, atau failover WAN dari satu uplink ke uplink lain, mengubah alamat luar atau jalurnya dengan cara ketiga. Itu bukan peristiwa yang sama dan tidak meninggalkan sisa yang sama.

Baris sambungan ulang di log VPN juga bukan bukti perubahan WAN. Waktu tunggu diam, interval autentikasi ulang, dan deteksi peer mati semuanya menghasilkan sambungan ulang tanpa perubahan alamat sama sekali. Bandingkan stempel waktu dari log akses dengan log VPN sebelum menyimpulkan apa pun, dan jaga jendela perbandingan cukup lebar untuk menangkap perubahan yang terjadi pada malam hari.

Roaming dan sambungan ulang adalah protokol yang berbeda

WireGuard memiliki roaming terautentikasi yang tertanam di protokol: ketika peer menerima paket yang terautentikasi dengan benar dari alamat sumber baru, ia memperbarui titik akhir peer itu. Panduan cepat WireGuard menjelaskan konfigurasi peer yang memungkinkan ini, sehingga klien pada alamat yang berubah sering pulih tanpa mulai ulang yang terlihat.

OpenVPN berperilaku berbeda secara bawaan. Sesi UDP dapat berakhir dan tersambung ulang, dan perilaku float opsional memungkinkan peer terautentikasi melanjutkan dari alamat baru di mana konfigurasi mengizinkannya. Terowongan berbasis TCP lebih ketat, karena koneksinya sendiri terikat pada pasangan alamat. Perbedaan itulah yang menentukan apakah pemulihan tampak tak terlihat atau mengumumkan dirinya di log setiap kali.

Tidak ada dari kedua perilaku itu yang mengatakan apa pun tentang aplikasi di dalam. Terowongan yang pulih tidak memulihkan sesi TCP yang sudah dianggap mati oleh peer.

Status yang bukan milik terowongan

Status terjemahan dan perutean bertahan setelah sambungan ulang dengan cara yang mengejutkan orang. Entri conntrack yang dibuat untuk sumber lama menjaga jalur balasan terpaku pada alamat yang sudah tidak ada, dan entri itu kedaluwarsa sesuai jadwalnya sendiri, bukan saat terowongan kembali. Memulai ulang layanan terowongan tidak mempersingkat penantian itu, jadi tautan yang sudah diperbaiki masih bisa tampak rusak untuk sementara.

Rute dan aturan kebijakan dapat merujuk ke gateway atau antarmuka lama. Sekumpulan aturan yang benar sebelum pergantian WAN dapat menunjuk ke perangkat yang sekarang mati, yang menghasilkan terowongan yang melaporkan terhubung dan lalu lintas yang tidak ke mana-mana. DNS dinamis untuk server yang Anda kelola adalah masalah terpisah dari klien yang memperoleh sumber baru. Catatan perlu diperbarui agar klien jarak jauh menemukan Anda, dan tidak ada konfigurasi sisi klien yang mengimbangi alamat yang tidak akan diteruskan oleh terjemahan di hulu.

Urutkan pemeriksaan dari luar ke dalam

Urutan di bawah berjalan dari koneksi luar ke dalam, dan berhenti pada langkah pertama yang gagal itulah yang membuatnya berguna: setiap putaran menyingkirkan lapisan di atasnya. Pertahankan urutan itu bahkan ketika kesalahannya tampak jelas.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Perintah pertama menunjukkan titik akhir saat ini dan usia jabat tangan untuk setiap peer. Perintah kedua dan ketiga menunjukkan apakah antarmuka luar dan rute ke titik akhir masih masuk akal. Jumlah conntrack adalah pemeriksaan kasar untuk status yang tersisa dari alamat sebelumnya, dan jurnal adalah tempat alasan sambungan ulang dicatat.

Lalu uji dari klien LAN, bukan dari router. Ping yang dikirim oleh router itu sendiri menggunakan jalur berbeda dari lalu lintas yang diteruskan, jadi ping router yang berhasil membuktikan terowongan itu ada dan tidak membuktikan apa pun tentang keterjangkauan klien.

Tentukan perilaku yang diharapkan dan tuliskan

Menyambung ulang adalah perilaku yang benar untuk sebagian besar penerapan, jadi tujuannya bukan mencegahnya. Tentukan sebaliknya apa yang harus terjadi pada lalu lintas selama jeda: hentikan, tahan, atau alihkan ke jalur lain. Keputusan itu milik firewall dan kebijakan perutean, bukan milik profil VPN.

Catat peristiwa akses dan waktu sambungan ulang bersama-sama selama satu minggu. Perubahan berulang tanpa peristiwa akses yang sesuai menunjuk ke layanan akses, dan mengganti profil VPN tidak akan memperbaiki uplink yang terus bernegosiasi ulang. Satu pasang entri pada menit yang sama menyelesaikan pertanyaan untuk insiden itu dan memberi garis dasar untuk insiden berikutnya.