Cara membangun kebijakan failover VPN di router tanpa kebocoran

Failover bekerja persis seperti yang dikonfigurasi, dan itulah masalahnya. Saat tunnel utama putus, router memindahkan rute default ke modem kabel, laptop terus menjelajah, dan tidak ada yang menelepon. Dua hari kemudian seseorang menyadari bahwa folder keuangan bersama telah dapat diakses melalui jalur internet terbuka selama enam jam. Kebijakan failover VPN di router bukan trik perutean; itu adalah keputusan tentang apa yang harus dilakukan lalu lintas saat jalur pilihan hilang, dan keputusan itu harus ada sebelum jalurnya hilang.

Tentukan hasilnya sebelum memilih detektor

Biasanya ada tiga hasil di meja: mengirim klien yang terdampak melalui tunnel cadangan, membiarkan mereka memakai WAN biasa, atau memblokirnya sepenuhnya. Tuliskan mana yang berlaku untuk VLAN, SSID, atau kelas perangkat mana. Satu aturan datar “pindah ke WAN” adalah cara folder keuangan di atas berakhir di jalur publik.

Ketiganya tidak bisa saling menggantikan. Fallback WAN menjaga meja dukungan tetap menjawab telepon sambil mengekspos nama internal ke resolver lokal. Tunnel cadangan mempertahankan kebijakan tetapi bisa mendarat di alamat keluar yang tidak diterima pihak lain. Memblokir benar untuk VLAN penggajian dan salah untuk jaringan tamu yang tidak pernah memakai tunnel.

Cocokkan detektor dengan kegagalan yang benar-benar Anda takuti

Status handshake, status antarmuka, dan penerusan yang dapat dipakai adalah tiga sinyal berbeda, dan hanya yang terakhir yang penting bagi pengguna. Peer WireGuard bisa menunjukkan handshake baru sementara upstream penyedia membuang paket ke lubang hitam. OpenVPN klien bisa tetap di “terhubung” setelah rute yang didorongnya berhenti terurai.

Di pfSense susunan praktisnya adalah grup gateway yang diberi makan dpinger, yang memeriksa alamat pemantauan dan menandai gateway mati saat kehilangan atau latensi melewati ambangnya. Arahkan pemantauan itu ke sesuatu di luar tunnel, seperti host di LAN jauh atau alamat publik yang Anda capai melaluinya. Mengarahkannya ke alamat peer tunnel itu sendiri mengukur bagian yang sudah Anda tahu hidup.

Bangun grup agar cadangan tetap menjadi pilihan terakhir

Gunakan tingkat alih-alih satu daftar anggota datar. Primer di tingkat 1, tunnel cadangan di tingkat 2, WAN di tingkat 3 hanya untuk VLAN yang kebijakannya mengizinkan. Di pfSense ini ada di bawah System > Routing > Gateway Groups: tambahkan kedua gateway, beri tingkat berbeda, setel Trigger Level ke member down plus packet loss, simpan, lalu terapkan grup sebagai default antarmuka atau di kolom Gateway aturan firewall yang membutuhkannya.

Untuk instans klien OpenVPN di pfSense 2.5 dan yang lebih baru, pengaturan Default Gateway instans menentukan apakah tunnel menggantikan rute default sistem atau tidak. Perutean kebijakan per aturan hanya berperilaku seperti yang Anda harapkan bila rute yang Anda asumsikan benar-benar terpasang. Periksa Status > Gateways setelah perubahan alih-alih memercayai ikon status tunnel.

Dua pengaturan menyebabkan sebagian besar kedipan. Salah satunya interval probe yang lebih pendek daripada konvergensi ulang penyedia sendiri. Yang lain adalah grup tempat primer dan cadangan berbagi tingkat, sehingga keduanya tetap memenuhi syarat sepanjang waktu. Tambahkan histeresis melalui ambang kehilangan dan latensi sebelum pengguna Anda merasakan transisi menggantikan Anda.

Tutup jalur yang tidak pernah dimiliki tunnel

Pertama kebocoran DNS. Resolver terus menjawab di WAN dan meneruskan keluar darinya, sehingga nama tetap terurai melalui ISP sementara lalu lintas dipaku ke tunnel. Batasi antarmuka keluar resolver, dorong resolver internal ke klien, dan blokir port 53 untuk semua yang lain di VLAN hanya-VPN.

IPv6 perlu keputusannya sendiri. LAN dual-stack bisa kehilangan tunnel dan tetap memiliki rute default IPv6 global yang berfungsi, sehingga browser lebih memilih IPv6 dan keluar lewat WAN sementara IPv4 tampak sepenuhnya terkendali. Entah rutekan IPv6 ke dalam tunnel atau berhenti mengiklankan prefiks global selama tunnel mati. Setengah kebijakan lebih buruk daripada tidak ada, karena tampak berhasil.

Lalu jalur balik. Jika keluar cadangan memakai alamat sumber berbeda, pihak lain harus tahu cara mengirim lalu lintas kembali ke sana, dan setiap status yang terikat ke alamat lama sudah mati. Sesi yang terbuka saat primer putus tidak bermigrasi; mereka terhenti sampai waktu habis dan aplikasi memutuskan apa yang harus dilakukan.

Uji putusnya, kedipannya, dan jalur masuk kembali

Cabut primer dengan lalu lintas tidak berbahaya berjalan, lalu baca empat hal: Status > Gateways untuk status anggota grup, pfctl -ss untuk status yang masih dipaku ke gateway lama, traceroute dari klien untuk jalur keluar, dan kueri resolver untuk melihat server mana yang menjawab.

Sekarang kedipkan. Naikkan primer tiga puluh detik, turunkan tiga puluh, dua kali. Jika lalu lintas mengejar setiap transisi, ambangnya terlalu ketat atau tingkatnya salah. Perbaiki itu sesuai jadwal Anda, karena jika tidak, penyedia akan melakukannya sesuai jadwal mereka.

Terakhir, pastikan Anda masih bisa mengelola router. Pertahankan jalur di luar band seperti kabel konsol, VLAN manajemen, atau modem seluler. Uji failover yang mengunci Anda di luar adalah uji yang tidak bisa Anda selesaikan, dan router yang tak terjangkau tidak bisa kembali sendiri.

Sebelum menyatakan kebijakan selesai, Anda harus bisa menjawab empat pertanyaan tanpa membuka terminal: VLAN mana yang boleh memakai WAN selama tunnel mati, apa yang dipantau detektor dan berapa lama ia menunggu, server nama dan rute IPv6 mana yang bergerak bersama jalur, dan bagaimana Anda masuk kembali jika cadangan juga gagal. Jika ada jawaban “apa pun default-nya”, kebijakan itu masih milik router, bukan milik Anda.