Dua terowongan IPsec aktif tetap butuh rencana jalur balik

Buka terminal di stasiun kerja pada satu situs dan sambungkan ke server di situs lain. Percakapan TCP tunggal itu sekarang harus melintasi empat gateway alih-alih dua, dan bagian yang menarik bukanlah apakah ia bekerja pada hari yang baik. Bagian yang menarik adalah pasangan gateway mana yang dipilih arah maju, pasangan mana yang dipilih balasan, dan siapa yang memegang status alur selama itu terjadi. Tidak ada apa pun di tabel perutean yang memutuskan itu untuk Anda.

Gambarlah empat gateway sebelum menggambar rute

Desain aktif ganda dengan dua firewall VPN independen per situs, satu pasang per penyedia, memberi Anda dua jalur yang dapat dipakai dan tiga cara untuk mematahkannya. Catat alamatnya sebelum mengonfigurasi apa pun: klien sebagaimana terlihat sebelum dan sesudah setiap gateway, server juga begitu, hop berikutnya arah maju dan hop berikutnya arah balik.

Tabel itu adalah desainnya. Semua setelahnya adalah pertanyaan apakah perangkat setuju dengan tabel itu.

Bagaimana jalur maju dipilih

Lapisan perutean multipath berbiaya sama menyebarkan alur ke hop berikutnya dengan melakukan hash pada bidang header, yang dijelaskan RFC 2992 secara terperinci. Pemilihan itu bisa sepenuhnya tanpa status: ia tidak perlu entri pelacakan koneksi, hanya hash stabil atas bidang yang tak berubah. Jaga himpunan jalur dan masukan hash tetap konstan, dan setiap paket alur memilih hop berikutnya yang sama.

Pemilihan per alur menghindari penyusunan ulang yang akan ditimbulkan penyeimbangan paket demi paket pada tautan dengan tunda berbeda. Ia tidak menjanjikan bahwa biaya perutean yang sama berarti latensi terukur yang sama, karena memang tidak. Dan ketika keanggotaan jalur berubah, alur dipetakan ulang, jadi bertahannya koneksi selama kegagalan adalah persyaratan terpisah dari pemilihan jalur.

Yang benar-benar dibutuhkan jalur balik

Di sini penelusurannya berhenti bersimetri. Hash maju yang stabil tidak memberi tahu apa pun tentang apa yang akan dilakukan situs jauh dengan balasannya. Jika firewall independen harus melihat kedua arah koneksi untuk memelihara status yang berguna, rute balik yang melewatinya meninggalkan lalu lintas yang tidak cocok dengan apa pun. Dua kotak dengan himpunan aturan serupa bukanlah status bersama.

Konfirmasikan perilaku dua arah yang diterapkan, atau tulis kebijakan eksplisit yang menjaga batas yang diperlukan tetap koheren. Tebakan di sini baru ketahuan saat gangguan, oleh orang-orang yang tidak menikmatinya.

Di mana penerjemahan memutuskan untuk Anda

NAT adalah tuas lainnya, dan sifatnya opsional bukan wajib. Identitas terjemahan khusus jalur dapat mengarahkan balasan kembali ke gateway yang memegang status, dan itu desain yang sah. Namun ia menambah pemetaan, rute balik, dan pemilik untuk status itu, jadi terimalah bebannya hanya untuk persyaratan yang bisa Anda sebutkan dengan lantang.

Jika persyaratannya sekadar kedua jalur membawa lalu lintas dan salah satunya bertahan saat penyedia hilang, multipath per alur biasa dengan perutean balik yang koheren biasanya desain yang lebih kecil.

Jalani penerimaan secara berurutan

Uji dalam urutan ini dan catat alamatnya pada setiap langkah: koneksi baru di jalur A dan jalur balasannya, hal yang sama di jalur B, lalu hilangnya satu penyedia, lalu pemulihan. Untuk setiap hasil, catat alur mana yang sudah mapan berpindah, mana yang harus menyambung ulang, dan ke mana alur baru pergi sesudahnya. Tuliskan nilai yang diharapkan lebih dulu, lalu bandingkan dengan tangkapan. Dua terowongan yang sudah mapan tidak membuktikan satu pun dari itu.

Desain selesai ketika tabel yang Anda tulis cocok dengan apa yang ditunjukkan tangkapan, bukan ketika kedua terowongan menyala.