Failover VPN: saat jalur balik tetap di tunnel lama

Tunnel cadangan naik, tunnel utama turun, dan aplikasi tetap kehabisan waktu. Di kedua situs status tunnel terlihat sehat, dan itulah yang membingungkan. Failover yang memindahkan permintaan ke cadangan tetapi meninggalkan balasan di jalur lama bukanlah failover. Panduan di bawah menguji jalur balik, bukan hanya handshake.

Catat dulu rute di kedua ujung; pandangan dari satu situs tidak bisa menunjukkan jalur asimetris. Ini juga langkah yang paling sering dilewati di bawah tekanan waktu.

Catat rute kedua situs sebelum pengujian

Untuk setiap prefiks yang dilindungi, tuliskan rute utama, rute cadangan, dan preferensi yang memilih di antaranya. Sertakan gateway LAN di belakang setiap endpoint VPN, karena endpoint jarang menjadi lompatan terakhir.

Metrik statis, rute yang dilacak, dan perutean dinamis mengekspresikan kelayakan dengan cara berbeda. Ketahui mana yang dipakai desain Anda, dan apa yang diperlukan agar alternatif menjadi aktif. Tuliskan kondisinya di samping rute, misalnya metrik lebih rendah sampai pemeriksaan gagal.

Lakukan ini di kedua situs. Cadangan yang diutamakan di satu sisi dan diabaikan di sisi lain menghasilkan persis asimetri yang ingin Anda hindari.

Amati permintaan dan balasan di setiap fase

Gunakan aplikasi yang diizinkan dan tidak berbahaya dan amati tiga fase: normal, kegagalan jalur utama, dan pemulihan. Di setiap fase, catat tunnel mana yang membawa permintaan dan mana yang membawa balasan. Alamat peer yang dapat dijangkau tidak membuktikan bahwa jalur aplikasi yang dilindungi bekerja. Catat di kedua situs agar aliran satu arah terlihat.

Jika permintaan berpindah dan balasan tidak, periksa rute situs jauh ke prefiks klien dan preferensinya terhadap cadangan. Itu keputusan perutean, bukan kegagalan tunnel.

Pulihkan kondisi semula setelah pengujian dan pastikan jalur utama kembali diutamakan. Jalur utama yang dipulihkan tetapi tidak diutamakan adalah desain failover yang belum selesai.

Kelola status sesi saat gateway berubah

Firewall dan NAT dapat menyimpan status koneksi di satu gateway, dan perubahan jalur ke gateway lain tidak membawanya. Beberapa aplikasi menyambung ulang sendiri; yang lain gagal sampai sesi dipulihkan. Jika cadangan mengubah sumber publik atau alamat privat yang diterjemahkan, aturan akses jarak jauh juga bisa bereaksi. Dokumentasikan setiap mulai ulang sesi yang diperkirakan alih-alih menjanjikan failover tanpa gangguan.

Pertahankan pengalamatan stabil di tempat aplikasi memerlukannya. Desain failover yang mengubah alamat sumber untuk setiap sesi adalah pilihan desain, dan itu harus dituliskan. Pilihan itu menentukan seberapa besar gangguan yang benar-benar disadari pengguna.

Uji aplikasi yang mempertahankan sesi panjang, bukan hanya permintaan baru.

Pulihkan jalur utama dan periksa flapping

Pastikan pengumuman rute atau preferensi stabil tanpa berosilasi. Jalur utama yang flapping bisa lebih mengganggu daripada gangguan yang jelas, karena setiap transisi mengatur ulang status.

Jaga administrasi gateway tetap terjangkau melalui jalur pemulihan agar pengujian itu sendiri tidak mengunci Anda di luar. Catat fasenya, jalur yang teramati, dan waktu pemulihan; catatan itulah yang membuat failover berikutnya dapat diprediksi. Catatan strongSwan tentang penerusan berguna saat endpoint adalah host Linux.