Tiga jenis failover OpenVPN di pfSense, tiga mekanisme

„OpenVPN failover“ di pfSense mencakup setidaknya tiga rancangan yang tidak saling terkait, dan masing-masing butuh mekanisme berbeda. Menjaga terowongan tetap hidup melalui tautan internet cadangan, menyambung ulang ke server lain, dan mengarahkan lalu lintas LAN ke terowongan lain yang sudah terbentuk bukan variasi dari satu fitur. Pilih kegagalan yang Anda hadapi sebelum membangun grup gateway. Grup yang memperbaiki salah satunya tidak melakukan apa pun untuk dua lainnya.

Sebut kegagalannya sebelum membangun grup

Tulis kalimat yang Anda ingin benar selama gangguan. „Terowongan menyambung ulang lewat WAN cadangan“ dan „cabang tetap mencapai aplikasi lewat terowongan lain“ adalah kalimat yang berbeda. Hanya yang pertama soal transport.

Lalu pasangkan dengan sebuah mekanisme. Hilangnya WAN lokal adalah masalah pemilihan antarmuka, titik akhir jarak jauh yang mati adalah masalah daftar koneksi, dan jalur tak terpakai di dalam terowongan yang sudah terbentuk adalah masalah perutean dan kebijakan.

WAN lokal: pindahkan transport

Untuk klien OpenVPN pfSense, tata letak multi-WAN yang didukung memilih grup gateway yang sesuai sebagai antarmuka tempat klien mengikat. Inilah yang memungkinkan koneksi luar keluar lewat tautan cadangan ketika yang utama gagal. Dengan sendirinya ini tidak mengubah cara lalu lintas dalam dirutekan.

Sisi server dari rancangan yang sama terpisah. Server OpenVPN yang harus dapat dijangkau melalui beberapa alamat publik butuh pendengar dan kebijakan masuk untuk setiap entri itu, bukan hanya klien yang bisa menelepon lewat dua tautan. Satu entri publik yang berfungsi bukan bukti bahwa yang kedua sudah dikonfigurasi.

Aturan perutean berbasis kebijakan untuk paket LAN yang diteruskan bukan pengaturan yang memindahkan koneksi transport VPN yang dibuat secara lokal. Itu dua pencarian berbeda, dan mengubah satu tidak mengubah yang lain.

Titik akhir jarak jauh: server lain

Remote alternatif adalah fitur daftar koneksi. Klien mencoba entri berikutnya ketika yang sekarang tidak menjawab, yang berguna ketika host tertentu mati, bukan ketika uplink Anda sendiri mati. Kedua kegagalan terlihat serupa dari meja pengguna dan butuh perbaikan berbeda.

Setiap kandidat harus menjadi pengganti yang nyata: autentikasi yang cocok, kebijakan klien yang cocok, dan akses ke sumber daya privat yang sama. Nama host kedua yang mengarah ke infrastruktur rusak yang sama bukan cadangan. Server tanpa rute yang dibutuhkan juga bukan, seberapa sehat pun jabat tangannya terlihat.

Mekanisme ini juga tidak membuat dua terowongan meneruskan sekaligus. Ia mengganti satu koneksi dengan yang lain, secara berurutan, dan celah di antaranya terlihat oleh apa pun yang sedang berjalan.

Jalur terowongan: pilih jalan keluar lain

Ketika dua terowongan sudah berdiri dan lalu lintas harus memakai yang lebih sehat, mekanismenya adalah antarmuka VPN yang ditetapkan dengan gateway sendiri, ditambah aturan kebijakan eksplisit yang mengirim lalu lintas yang tepat ke sana. Grup gateway di atas antarmuka yang ditetapkan itu dapat menyatakan prioritas dan pemantauan.

Rancangan itu soal pemilihan, bukan pemulihan. Memindahkan koneksi baru ke terowongan kedua tidak mengatakan apa pun tentang sesi yang sudah terbentuk di yang pertama, dan tidak mengatakan apa pun tentang apakah sisi jauh akan menerima alamat sumber baru. Memperlakukannya sebagai mekanisme pemulihan adalah cara menaruh harapan terlalu tinggi.

Jika syaratnya sesi yang ada harus bertahan, katakan itu secara eksplisit. Sebagian besar implementasi tidak memigrasikan aliran hidup antar terowongan, dan merancang seolah-olah mereka melakukannya menghasilkan failover yang terlihat benar di diagram dan dalam praktik menjatuhkan setiap koneksi terbuka.

Monitor, NAT, dan aturan fail-closed

Monitor harus menguji sesuatu yang seharusnya diberikan terowongan. Target yang menjawab dari rekan terowongan tetapi tidak dari jaringan aplikasi di baliknya akan melaporkan sehat sementara pengguna tidak melihat apa pun. Target diagnostik yang tak terjangkau akan melaporkan mati sementara jalurnya baik. Pilih alamatnya dengan sengaja dan pastikan ia hanya terjangkau melalui terowongan yang dimaksud.

Periksa NAT keluar untuk kedua jalan keluar. Terjemahan yang berfungsi di yang utama tidak menggambarkan alamat sumber cadangan, dan jaringan privat jarak jauh butuh rute balik yang cocok dengan sumber yang Anda tampilkan. Terjemahan yang benar di satu jalur bisa diam-diam salah di jalur lain.

Lalu putuskan apa yang terjadi pada lalu lintas yang tidak boleh memakai WAN. pfSense punya perilaku terdefinisi untuk aturan yang gateway pilihannya mati, dan aturan izin lebar yang datang kemudian atau rute default dapat membatalkan maksud Anda. Tulis hasil terblokir sebagai syarat, lalu verifikasi dengan menurunkan jalurnya.

Uji kehilangan dan pemulihan secara terpisah, dengan lalu lintas yang Anda berwenang hasilkan, dan amati tiga hal sekaligus: WAN yang membawa koneksi luar, terowongan yang membawa permintaan aplikasi, dan jalur yang diambil jawaban. Sepasang indikator gateway hijau bukan salah satu dari ketiga hal itu. Panduan multi-WAN Netgate menjelaskan pengikatan transport dan alternatif klien yang diekspor yang menjadi landasan ini.