Rute statis atau protokol perutean di atas VPN situs-ke-situs?

Kedua opsi membawa paket antar situs, jadi keputusannya bukan soal protokol mana yang lebih baru, dan ukuran terowongan juga tidak menyelesaikannya. Tiga kondisi yang menentukan: berapa banyak prefiks berubah dan seberapa sering, apakah desain membutuhkan failover otomatis antar jalur, dan berapa banyak mesin bidang kendali yang mampu dioperasikan tim pada pukul tiga pagi. Jawab itu dengan jujur dan pilihannya biasanya terjadi sendiri. Sisa tulisan ini adalah berapa biaya setiap jawaban.

Tiga kondisi yang menentukan

Kondisi pertama adalah gejolak. Beberapa subnet stabil dengan kepemilikan yang jelas dapat dirawat dengan tangan selama bertahun-tahun, dan setiap rute tetap menjadi baris yang bisa dibaca dan diperiksa seseorang. Lusinan prefiks yang berpindah seiring proyek datang dan pergi adalah masalah lain, karena setiap perpindahan harus sampai ke setiap perangkat yang masih mengingat jalur lama.

Kedua adalah perilaku kegagalan. Ketika jalur cadangan harus menjadi aktif tanpa disadari manusia, sesuatu harus mendeteksi kegagalan dan menarik rute. Perutean statis hanya dapat melakukannya melalui pelacakan atau pemasangan bersyarat, dan hanya untuk kegagalan yang sudah Anda pikirkan sebelumnya.

Ketiga adalah selera terhadap bidang kendali kedua. Protokol perutean menambahkan sesi, autentikasi, filter, dan kebijakan pemilihan, dan setiap hal itu memerlukan pemantauan plus proses perubahan. Itu biaya operasional permanen, bukan tugas konfigurasi sekali jalan.

Tabel di bawah paragraf ketiga adalah versi singkatnya, dan tiga bagian sesudahnya menjelaskan mengapa setiap baris berada di tempatnya. Bacalah baris-baris itu terhadap jumlah situs Anda sendiri sebelum memilih, karena keputusan yang mengabaikan biaya operasional hanyalah setengah keputusan.

Berapa biaya perutean statis sebenarnya

Rute statis harus benar di kedua sisi terowongan. Menambahkan subnet berarti menyunting gateway jauh, gateway lokal, dan biasanya jalur balik, dan melupakan salah satunya menghasilkan kegagalan satu arah yang tampak seperti bug aplikasi. Tim aplikasi melihat waktu habis sementara tim jaringan melihat rute yang ada dan tampak sehat. Tidak ada tim yang salah, dan itulah sebabnya kegagalan ini butuh waktu lama untuk dilacak.

Entri statis juga tetap terpasang setelah jalur di bawahnya hilang. Kecuali platform menyediakan pelacakan, rute terus menunjuk ke hop berikutnya yang tidak lagi meneruskan, dan lalu lintas menghilang alih-alih beralih. Keheningan itulah biaya yang Anda terima ketika memilih opsi sederhana.

Tuliskan metode pelacakan di samping setiap rute, catat kegagalan mana yang dicakupnya, dan simpan daftarnya bersama konfigurasi terowongan. Jika tidak, gangguan berikutnya ditemukan oleh pengguna alih-alih oleh jaringan, yang selalu merupakan penemuan yang lebih mahal.

Berapa biaya perutean dinamis sebenarnya

Protokol mengumumkan prefiks baru, menarik yang tidak terjangkau, dan menyatakan preferensi antar jalur. Itu sangat berguna ketika beberapa situs atau terowongan redundan jika tidak demikian memerlukan penyuntingan terkoordinasi pada setiap perubahan. Itu juga alasan protokol dapat mengejutkan Anda pada saat terburuk. Setiap tindakan itu adalah perubahan keadaan yang tidak Anda buat sendiri.

Protokol itu menciptakan dua keadaan yang dapat berselisih. Terowongan dapat naik sementara sesi perutean turun, dan sesi dapat naik sementara pengumumannya melewatkan subnet yang dibutuhkan aplikasi. Keduanya tampak seperti jaringan yang bekerja separuh, dan tidak satu pun terlihat dari halaman status terowongan.

Filter dan kebijakan karena itu menjadi bagian dari desain, bukan renungan belakangan. Protokol yang mengumumkan segala hal pada akhirnya akan mengumumkan sesuatu yang salah, dan prefiks yang salah bergerak lebih cepat daripada orang yang dapat memperbaikinya. Tulis filter sebelum sesi pertama diaktifkan agar pengumuman pertama sudah disengaja.

Kendalikan apa yang boleh dikatakan sesi perutean

Tetapkan daftar prefiks yang diizinkan per peer dan tegakkan di sisi masuk, karena filter keluar tidak dapat mencegah peer mengirimkan rute default kepada Anda. Rute default dan agregat adalah kesalahan mahal di sini: keduanya dapat diam-diam mengganti jalur tak terkait dengan satu entri yang dipelajari yang tampak sah. Tolak secara eksplisit kecuali desain memang menginginkannya.

Tuliskan situs pemilik di samping setiap jaringan sebelum sesi pertama naik, karena pemetaan itulah sumber daftar filter, bukan hiasan dokumentasi. Tanpanya, orang yang menyunting filter harus menebak situs mana yang seharusnya mengumumkan prefiks.

Redistribusi antara dua protokol adalah tempat loop dimulai, dan tempat prefiks yang sama datang dua kali dengan atribut yang tidak dapat dibandingkan dengan bersih. Jauhkan redistribusi dari desain sampai kebutuhan tertentu memaksanya, dan bila harus ada, tandai dan filter rute di batas.

Antarmuka terowongan berbasis rute membuat perutean dinamis lebih mudah diwakili, karena terowongan menjadi antarmuka dengan rute alih-alih kebijakan yang mencocokkan selektor. Itu tidak menghapus pertanyaan cakupan peer: selektor IPsec tetap harus mengizinkan lalu lintas yang ingin Anda rutekan.

Uji jalur kegagalan, bukan jalur bahagia

Apa pun yang Anda pilih, matikan satu uplink dan pastikan lalu lintas berpindah, atau bahwa ia gagal seperti yang Anda dokumentasikan. Desain yang hanya diuji dengan kedua jalur sehat adalah desain yang belum diuji sama sekali. Ukur waktu deteksi saat Anda di sana, karena angka yang Anda ukur adalah angka yang akan dialami pengguna.

Lalu pastikan jalur balik secara mandiri, karena perutean asimetris di atas VPN lazim dan tidak terlihat sampai perangkat yang menyimpan keadaan menjatuhkan balasannya. Aliran yang bekerja satu arah hanya membuktikan separuh jalur.

Urutan kerja: hitung prefiks, putuskan bagaimana kegagalan harus dideteksi, periksa siapa yang dapat mengoperasikan protokol, kendalikan apa yang diumumkan, lalu uji satu gangguan dari awal hingga akhir. Setiap langkah menghasilkan fakta yang dibutuhkan langkah berikutnya.