Tiga jenis failover OpenVPN pada pfSense, tiga mekanisme

„OpenVPN failover“ pada pfSense merangkumi sekurang-kurangnya tiga reka bentuk yang tidak berkaitan, dan setiap satunya memerlukan mekanisme berbeza. Mengekalkan terowong hidup melalui pautan internet sandaran, menyambung semula ke pelayan lain dan mengarahkan trafik LAN ke terowong lain yang sudah terbentuk bukan variasi satu ciri. Pilih kegagalan yang anda pertahankan diri daripadanya sebelum membina kumpulan gateway. Kumpulan yang membetulkan satu daripadanya tidak berbuat apa-apa untuk dua yang lain.

Namakan kegagalan sebelum membina kumpulan

Tulis ayat yang anda mahu benar semasa gangguan. „Terowong menyambung semula melalui WAN sandaran“ dan „cawangan masih sampai ke aplikasi melalui terowong lain“ ialah ayat yang berbeza. Hanya yang pertama tentang pengangkutan.

Kemudian padankan dengan sesuatu mekanisme. Kehilangan WAN tempatan ialah masalah pemilihan antara muka, titik hujung jauh yang mati ialah masalah senarai sambungan, dan laluan tidak boleh guna di dalam terowong yang terbentuk ialah masalah penghalaan dan dasar.

WAN tempatan: pindahkan pengangkutan

Bagi klien OpenVPN pfSense, susunan berbilang WAN yang disokong memilih kumpulan gateway yang sesuai sebagai antara muka yang diikat oleh klien. Inilah yang membolehkan sambungan luar keluar melalui pautan sandaran apabila yang utama gagal. Dengan sendirinya ia tidak mengubah cara trafik dalam dihalakan.

Bahagian pelayan bagi reka bentuk yang sama adalah berasingan. Pelayan OpenVPN yang perlu dicapai melalui beberapa alamat awam memerlukan pendengar dan dasar masuk bagi setiap entri itu, bukan hanya klien yang tahu mendail melalui dua pautan. Satu entri awam yang berfungsi bukan bukti bahawa yang kedua telah dikonfigurasikan.

Peraturan penghalaan berasaskan dasar untuk paket LAN yang dimajukan bukan tetapan yang memindahkan sambungan pengangkutan VPN yang dijana secara tempatan. Itu dua carian berbeza, dan mengubah satu tidak mengubah yang lain.

Titik hujung jauh: pelayan lain

Remote alternatif ialah ciri senarai sambungan. Klien mencuba entri seterusnya apabila entri semasa tidak menjawab, yang berguna apabila hos tertentu mati dan bukan apabila uplink anda sendiri mati. Kedua-dua kegagalan kelihatan serupa dari meja pengguna dan memerlukan pembetulan berbeza.

Setiap calon mesti menjadi pengganti sebenar: pengesahan yang serasi, dasar klien yang serasi dan akses kepada sumber peribadi yang sama. Nama hos kedua yang menyelesaikan ke infrastruktur rosak yang sama bukan sandaran. Pelayan tanpa laluan yang diperlukan juga bukan, sesihat mana pun jabat tangan itu kelihatan.

Mekanisme ini juga tidak membuat dua terowong memajukan serentak. Ia menggantikan satu sambungan dengan yang lain, secara berturutan, dan jurang antara keduanya kelihatan kepada apa sahaja yang sedang berjalan.

Laluan terowong: pilih jalan keluar lain

Apabila dua terowong sudah berdiri dan trafik perlu menggunakan yang lebih sihat, mekanismenya ialah antara muka VPN yang diperuntukkan dengan gateway sendiri, ditambah peraturan dasar yang jelas yang menghantar trafik yang betul ke sana. Kumpulan gateway di atas antara muka yang diperuntukkan itu boleh menyatakan keutamaan dan pemantauan.

Reka bentuk itu tentang pemilihan, bukan pemulihan. Memindahkan sambungan baharu ke terowong kedua tidak berkata apa-apa tentang sesi yang sudah terbentuk pada yang pertama, dan tidak berkata apa-apa tentang sama ada pihak jauh akan menerima alamat sumber baharu. Melayaninya sebagai mekanisme pemulihan ialah cara meletakkan jangkaan terlalu tinggi.

Jika keperluannya ialah sesi sedia ada mesti bertahan, katakan dengan jelas. Kebanyakan pelaksanaan tidak memindahkan aliran hidup antara terowong, dan mereka bentuk seolah-olah ia berbuat demikian menghasilkan failover yang kelihatan betul pada rajah dan dalam amalan menjatuhkan setiap sambungan terbuka.

Monitor, NAT dan peraturan fail-closed

Monitor patut menguji sesuatu yang sepatutnya disampaikan oleh terowong. Sasaran yang menjawab dari rakan terowong tetapi bukan dari rangkaian aplikasi di belakangnya akan melaporkan sihat sedangkan pengguna tidak melihat apa-apa. Sasaran diagnostik yang tidak dapat dicapai akan melaporkan mati sedangkan laluan elok. Pilih alamat itu dengan sengaja dan sahkan bahawa ia hanya boleh dicapai melalui terowong yang dimaksudkan.

Periksa NAT keluar untuk kedua-dua jalan keluar. Terjemahan yang berfungsi pada yang utama tidak menerangkan alamat sumber sandaran, dan rangkaian peribadi jauh memerlukan laluan balik yang sepadan dengan sumber yang anda tunjukkan. Terjemahan yang betul pada satu laluan boleh jadi salah secara senyap pada yang lain.

Kemudian tentukan apa yang berlaku kepada trafik yang tidak boleh menggunakan WAN. pfSense mempunyai tingkah laku yang ditakrifkan untuk peraturan yang gateway pilihannya mati, dan peraturan kebenaran luas yang datang kemudian atau laluan lalai boleh membatalkan niat anda. Tulis hasil tersekat sebagai keperluan, kemudian sahkan dengan menurunkan laluan itu.

Uji kehilangan dan pemulihan secara berasingan, dengan trafik yang anda dibenarkan jana, dan perhatikan tiga perkara serentak: WAN yang membawa sambungan luar, terowong yang membawa permintaan aplikasi, dan laluan yang diambil oleh jawapan. Sepasang penunjuk gateway hijau bukan salah satu daripada tiga itu. Panduan berbilang WAN Netgate menerangkan ikatan pengangkutan dan alternatif klien yang dieksport yang menjadi asas kepada ini.