Rute cadangan VPN mengambang tidak mengambil alih: daftar periksa failover

Rute VPN mengambang Anda sudah dikonfigurasi, jarak cadangan lebih tinggi daripada rute utama, tetapi tidak ada yang pernah berpindah. Atau ia berpindah, lalu kembali beberapa menit kemudian saat tautan nirkabel masih mati. Dalam kedua kasus, ada sesuatu selain kegagalan yang Anda pedulikan yang menentukan kelayakan rute.

Lakukan pemeriksaan ini secara berurutan. Masing-masing punya syarat berhenti, dan pemeriksaan yang gagal tidak bisa diselamatkan oleh pemeriksaan berikutnya. Contohnya memakai sintaks RouterOS karena jarak, keterjangkauan gateway, dan hop berikutnya rekursif semuanya terlihat di konfigurasi sana, tetapi urutannya berlaku untuk router mana pun dengan rute statis yang dilacak.

Namai kegagalan yang harus dicakup cadangan

«Rute utama mati» adalah empat pengamatan berbeda. Radio yang kehilangan pasangannya, antarmuka yang kehilangan pembawanya, gateway jauh yang berhenti menjawab, dan aplikasi yang berhenti bekerja semuanya tampak berbeda dari kursi router. Tuliskan yang mana yang menjadi sasaran rancangan sebelum siapa pun mengubah nilai jarak.

Lalu periksa kemandirian. Jika transport luar VPN berjalan pada jalur nirkabel yang sama, atau pada tautan akses yang berbagi upstream yang sama, cadangan bukan domain kegagalan kedua dan akan mati tepat saat Anda membutuhkannya. Tarik kabel utama di atas kertas: jika transport tunnel itu sendiri ikut mati, rute mengambang hanya mencakup kesalahan konfigurasi, bukan gangguan.

Berhenti meminta jarak mendeteksi apa pun

Jarak yang lebih tinggi membuat rute kurang disukai. Itulah seluruh tugasnya. Selama rute statis utama tetap layak, rute mengambang tetap tidak aktif, dan itu perilaku yang benar, bukan bug. Kegagalan baru terlihat saat rute utama ditarik atau ditandai tidak terjangkau.

Untuk rute statis itu memerlukan pelacak eksplisit:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

Baca apa yang diuji: hop berikutnya, bukan tujuan. Radio yang masih menjawab di sisinya sendiri sementara penerusan di luarnya rusak tetap menjaga rute utama aktif. Itulah kasus senyap, dan jarak plus pemeriksaan gateway tidak akan menangkapnya. Jika kasus itu penting, deteksi harus datang dari sesuatu yang mengamati sisi jauh: ketetanggaan protokol routing, atau probe yang jalur dan aturan hasilnya Anda tentukan sendiri.

Lacak ke mana paket probe itu sendiri pergi

Probe kesehatan juga punya rute. Begitu lalu lintas data pindah ke VPN, probe tanpa batasan ke alamat jauh yang sama dapat mengikutinya, berhasil, dan dibaca sebagai bukti bahwa rute utama pulih. Lalu lintas kembali ke jalur yang rusak dan siklusnya berulang.

Sematkan probe ke jalur yang seharusnya dinilainya. Di RouterOS cara biasanya adalah rute host ke target pemantauan melalui gateway utama, dengan cakupan cukup kecil sehingga tidak ada rute lain yang dapat menyelesaikannya, dan itulah yang dibangun contoh failover rekursif di manual RouterOS. Konfirmasikan pada tabel hidup dengan cadangan aktif, bukan dari komentar konfigurasi:

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

Tentukan arti hasil probe sebelum menambah target

Satu target yang menolak ICMP atau masuk perawatan tampak persis seperti kegagalan jalur, dan tiga target tanpa aturan hanya memberi Anda tiga pendapat. Putuskan aturannya dulu, lalu terapkan: misalnya, rute utama dihitung mati ketika dua dari tiga target gagal selama dua interval berturut-turut, ditulis di buku pedoman operasi tempat orang berikutnya akan menemukannya.

Atur ambang kegagalan dan pemulihan agar satu paket hilang tidak menggeser situs. Histeresis memakan sedikit waktu deteksi dan membeli kembali stabilitas. Pilih intervalnya dari berapa lama gangguan dapat ditoleransi, bukan dari seberapa cepat probe dapat berjalan, dan jaga pengembalian lebih lambat daripada failover agar rute utama harus membuktikan dirinya sebelum mendapat lalu lintas kembali.

Periksa jalur kembali dan kisah sesi

Failover yang hanya bekerja keluar adalah setengah rancangan. Situs jauh memerlukan rute kembali ke rentang sumber Anda melalui VPN, atau lalu lintas balik datang dari alamat tak terduga dan menabrak status firewall yang tidak lagi cocok. Sesi yang ada akan putus bahkan ketika koneksi baru bekerja, jadi masukkan itu ke kriteria penerimaan alih-alih menjanjikan kelangsungan transfer.

Jauhkan akses manajemen dari jalur yang diuji. Jika satu-satunya jalan masuk Anda melalui rute utama, uji failover mengunci Anda di luar perangkat yang berperilaku salah.

Jalankan urutan penerimaan

Tiga uji mencakup sebagian besar wilayah: kehilangan fisik rute utama, kegagalan penerusan senyap dengan antarmuka masih hidup, dan pemulihan rute utama. Untuk masing-masing, catat sumber dan hop berikutnya probe, rute tujuan yang aktif, dan pertukaran aplikasi yang diizinkan yang baru di kedua arah.

Kasus senyap adalah yang memisahkan rancangan. Jika cadangan tidak mengambil alih di sana, Anda membangun pemantau tautan, bukan pemantau jalur. Putuskan apakah itu dapat diterima, dan tuliskan batasannya di tempat insinyur jaga akan membacanya. Tunnel kedua yang tersambung bukan, dengan sendirinya, kebijakan cadangan yang selesai.