Memindahkan satu subnet ke tunnel VPN baru tanpa gangguan

Naikkan tunnel baru, pindahkan satu subnet, dan subnet itu kini gagal sesekali sementara semua yang lain benar-benar baik. VPN yang setengah dimigrasikan gagal persis seperti ini, karena tunnel tidak pernah menjadi bagian yang sulit. Jalurnya juga mencakup rute mana yang menang, selektor mana yang cocok, apa yang diizinkan aturan akses, bagaimana balasan kembali, dan terjemahan apa pun yang diterapkan desain lama. Pindahkan tunnelnya saja dan Anda belum memindahkan satu pun dari itu.

Tunnel adalah separuh jalur yang mudah

Kegagalan sesekali setelah migrasi sebagian biasanya berarti dua jalur sama-sama masuk akal. Sebagian aliran memilih tunnel baru, sebagian tetap di yang lama, dan perangkat yang mengingat state lalu melihat balasan datang lewat jalur yang tidak pernah dipakai permintaan itu. Dua jalur tidak otomatis lebih aman daripada satu; keduanya adalah dua hal yang bisa tidak sepakat. Perhatikan laporan flapping, bukan penghitung tunnel, karena penghitung akan tampak sehat sepanjang waktu.

Pertanyaan pertama yang berguna bukan tunnel mana yang lebih baik. Melainkan aliran mana memilih jalur mana hari ini, dan apakah permintaan dan balasannya mendapat jawaban yang sama.

Bangun tujuannya sebelum Anda memilihnya

Pastikan peer-nya kompatibel dan tunnel baru membawa cakupan alamat yang Anda maksud. Tambahkan penerusan dan izin layanan yang dibutuhkannya selagi masih jalur yang tidak dipilih, agar pemotongan itu sendiri hanya mengubah pemilihan dan tidak yang lain.

Tanyakan ke situs jauh bagaimana ia akan mengembalikan lalu lintas. Jika balasan masih keluar lewat tunnel lama, rute lokal baru menimbulkan asimetri atau gagal pada filter yang mengingat state. Terjemahan juga masuk ke desain karena alasan yang sama: alamat sumber yang berubah juga mengubah jalur baliknya.

Potong secara sempit, dan ketahui jalan pulangnya

Sebutkan subnet persisnya dan mekanisme yang didukung platform yang memilih rute atau selektor barunya. Definisi berbasis kebijakan tidak selalu berperilaku seperti metrik rute, jadi baca aturan kebijakan yang tumpang tindih pada implementasi Anda sebelum menganggap kecocokan yang lebih spesifik menang.

Pindahkan satu subnet, bukan satu situs. Pertahankan akses manajemen pada jalur yang tidak Anda sentuh, dan tuliskan pengembalian sebelum Anda menerapkan apa pun: rute atau kebijakan mana yang kembali, siapa yang melakukannya, dan bagaimana mereka tetap terhubung saat melakukannya.

Asimetri dan state basi

Firewall dan perangkat NAT mengingat antarmuka yang dipakai suatu aliran. Ketika permintaan dan balasan melewati tunnel berbeda, perangkat dapat membuang balasannya meski tiap jalur bekerja sendiri-sendiri. Uji dengan aliran yang Anda buka setelah perubahan, karena sesi yang sudah terbentuk bisa terus memakai jalur lama selama berjam-jam.

Jika alamat sumber yang teramati berpindah, temukan setiap kebijakan yang menyebut yang lama. Migrasi yang diam-diam mengubah sumber melanggar aturan yang tidak pernah diklasifikasikan siapa pun sebagai bagian dari desain VPN.

Buktikan kedua jawaban, lalu pensiunkan kebijakan lama

Dari host biasa di subnet yang dimigrasikan, capai layanan yang dimaksud dan periksa sumber yang teramati serta antarmuka balasannya. Lalu uji jaringan yang seharusnya tetap di tunnel lama, karena migrasi baru selesai ketika kedua jawaban benar. Ujian kedua itulah yang dilewatkan orang, dan itulah yang menangkap selektor yang lebih luas dari yang Anda maksud.

Pensiunkan kebijakan usang hanya ketika tidak ada subnet tersisa yang bergantung padanya, dan catat rute akhir beserta pemiliknya di inventaris selektor. Selesai bukanlah tunnel baru melapor bahwa dirinya hidup; selesai adalah setiap jaringan mengikuti jalur yang dimaksudkan.