VPN cloud membutuhkan BGP: mengapa protokol perutean lain gagal

Asosiasi keamanan IPsec sudah aktif, penghitung tunel bergerak, dan lalu lintas ke prefiks cloud menghilang. Operator lalu mencoba mengaktifkan OSPF di router pelanggan, berharap tetangga terbentuk, dan tidak terjadi apa-apa. Tunel bukanlah bagian yang hilang: VPN cloud terkelola menawarkan kontrak perutean yang terdefinisi, dan pada platform besar kontrak itu adalah BGP. Sampai ada sesi dan prefiks diterima, tunel hanyalah jalur terenkripsi tanpa tujuan di belakangnya.

Tunel aktif dan rutenya hilang

Selesainya fase 1 dan fase 2 membuktikan kedua pihak sepakat soal perlindungan, bukan bahwa salah satu pihak tahu ke mana lalu lintas harus dikirim. Keduanya mesin status terpisah dengan mode kegagalan terpisah.

Ajukan tiga pertanyaan berurutan: apakah prefiks diumumkan, apakah diterima oleh tetangga, dan apakah dipasang untuk penerusan? Prefiks yang diumumkan lalu difilter adalah masalah kebijakan. Prefiks yang tidak pernah diumumkan adalah masalah sesi atau konfigurasi. Prefiks yang diterima tetapi tidak dipasang adalah masalah pemilihan rute, dan setiap jawaban menunjuk bagian konfigurasi yang berbeda.

Apa yang sebenarnya diberikan penyedia

Gerbang VPN terkelola bukan router tanpa batas. Penyedia memberi Anda gerbang dengan alamat tetangga yang didukung, pengaturan sistem otonom, batas prefiks, dan perilaku kegagalan yang terdefinisi. Permukaan itulah produknya.

Google Cloud mendokumentasikan perutean BGP dinamis untuk HA VPN, dengan Cloud Router mempelajari rute tetangga dan memasok rute dinamis kustom yang memenuhi syarat ke VPC. AWS Site-to-Site VPN mendokumentasikan pilihan antara perutean statis dan dinamis, serta menjelaskan pemeriksaan keaktifan BGP berguna untuk failover tunel sekaligus mendukung pemeriksaan kesehatan bagi perangkat tanpa BGP. Perilaku salah satu platform tidak boleh disimpulkan dari nama produk platform lain.

Konsekuensi praktisnya, Anda memilih mode terkelola lebih dulu, lalu membaca parameter yang didukung. Rancangan yang mengasumsikan jenis ketetanggaan yang tidak ditawarkan layanan bukanlah masalah konfigurasi yang harus dipecahkan di router pelanggan.

Perlindungan tunel dan keterjangkauan adalah pekerjaan terpisah

IPsec melindungi lalu lintas yang dipilih untuk tunel. BGP memasok informasi keterjangkauan yang membuat prefiks memenuhi syarat. Tunel yang berfungsi tidak membuktikan prefiks yang diharapkan telah diumumkan, diterima, atau dipasang.

Bayangkan cabang yang mengumumkan 10.42.0.0/16 melalui dua jalur tunel yang memenuhi syarat. Hapus satu jalur yang dapat digunakan dan pilihan rute bisa berubah tanpa siapa pun menyunting rute setiap beban kerja. Deteksi, pemilihan rute, dan pemulihan aplikasi tidak seketika, dan tidak identik antar penerapan, jadi uji failover harus mengamati seluruh urutan, bukan paket pertama yang lolos.

Saat prefiks cloud tidak terjangkau, periksa status sesi dan rute yang dipelajari sebelum menyentuh kriptografi. SA yang aktif tanpa rute di belakangnya adalah bentuk paling umum dari gejala ini.

Di mana asumsi OSPF runtuh

OSPF, IS-IS, atau protokol lain di dalam tunel IPsec sepenuhnya mungkin pada perangkat yang dikelola sendiri, tempat Anda memiliki kedua ujung dan rancangan penerusannya. Fakta itu tidak mengatakan apa pun tentang layanan terkelola yang hanya menawarkan BGP sebagai mode perutean dinamisnya.

Jika rancangan yang diusulkan membutuhkan ketetanggaan yang tidak didukung layanan, ubah arsitekturnya secara sengaja. Pilihannya mencakup perangkat yang dikelola sendiri di VPC, perutean statis di tempat layanan mendukungnya, atau produk konektivitas lain. Mengonfigurasi protokol hanya di router pelanggan tidak dapat menambahkan tetangga di sisi cloud yang tidak ada, dan tidak akan membuat prefiks muncul.

Jangan bawa jawaban satu vendor ke gerbang vendor lain. Kata yang sama, seperti perutean dinamis atau failover tunel, bisa menjelaskan mekanisme dan batas yang berbeda.

Baca persyaratan layanan, lalu rancang

Sebelum baris konfigurasi pertama, tuliskan alamat tetangga, nomor sistem otonom, prefiks yang akan Anda umumkan dan terima, batas rute, dan perilaku yang diharapkan saat tunel gagal. Kelima butir itu adalah kontrak yang menjadi dasar rancangan Anda.

Lalu verifikasi dalam urutan yang sama: sesi terbentuk, prefiks diterima, rute ada di tabel rute VPC, dan aliran nyata ke alamat layanan. Ulangi setelah failover paksa, karena sesi yang terbentuk ulang bisa kembali dengan kumpulan rute berbeda. Jika rancangan bergantung pada konvergensi di bawah satu detik, ukurlah alih-alih mengasumsikannya.

Simpan kontrak layanan bersama catatan perubahan. Saat nanti seseorang bertanya mengapa tunel tidak dapat menjalankan OSPF, jawabannya adalah batas produk, bukan batasan protokol, dan catatan itu harus menyebutkannya.