Mengapa BGP di atas VPN tidak mengendalikan jalur underlay Anda

Dua situs mem-peer BGP melalui tunnel IPsec, saling mempelajari prefiks, dan diagramnya diganti label menjadi kontrol jalur. Label itulah awal kebingungannya. Sesi memang menukar keterjangkauan dan memang menerapkan kebijakan, tetapi ia tidak punya suara soal penyedia, kabel, atau router mana yang membawa paket terenkripsi. Saya pernah melihat tim membangun ulang tunnel yang berfungsi karena mereka mengharapkan perubahan rute BGP memindahkan lalu lintas ke jalur serat lain yang tidak pernah bisa dipengaruhi sesi itu.

Apa yang orang anggap dibeli sebuah sesi

Sebagian besar ekspektasi datang dari bagaimana perubahan rute terlihat di laboratorium. Anda mengumumkan prefiks melalui tunnel, sisi jauh memasangnya, dan lalu lintas berpindah. Urutan yang sama terjadi pada router yang memang punya tuas rekayasa lalu lintas, jadi keduanya tertukar. Di laboratorium kedua situs biasanya berbagi satu tautan akses, dan itulah sebabnya perbedaannya tidak pernah muncul di sana.

BGP adalah protokol keterjangkauan. Ia memberi tahu peer bahwa Anda dapat mengirimkan paket untuk sebuah prefiks dan membiarkan setiap sisi memeringkat tawaran yang diterimanya. Itu sungguh berguna melalui tunnel: prefiks muncul dan hilang saat situs datang dan pergi, dan Anda dapat menolak sebuah rentang tanpa menulis rute statis di setiap perangkat tepi. Yang tidak dilakukannya adalah menaruh router penyedia di bawah kendali Anda.

Underlay membawa header luar. Endpoint tunnel Anda mengirim paket terenkripsi ke alamat peer, dan jaringan di antara kedua alamat itu meneruskannya memakai rute yang dipasang operatornya. Tidak ada apa pun dalam sesi BGP yang mengubah keputusan itu, kecuali penyedia yang sama menawarkan layanan yang didukung yang melakukannya.

Apa yang sebenarnya dibawa sesi

Speaker BGP membuka koneksi TCP ke port 179 pada peer-nya, memakai format pesan dan atribut jalur yang didefinisikan dalam RFC 4271. Ketika alamat peer berada di dalam tunnel, tunnel harus aktif dan alamat itu harus terjangkau sebelum sesi bahkan bisa dimulai. Pertukaran IKE yang selesai bukan tetangga BGP. Implementasi IPsec berbasis rute hanya meloloskan lalu lintas setelah ada rute tunnel yang cocok, dan yang berbasis kebijakan membutuhkan alamat peer di dalam selektor yang dilindungi. Membalik urutan ini menghasilkan keadaan klasik ketika tunnel hijau dan sesi menganggur.

Setelah sesi aktif, kebijakan menentukan apa yang melintasinya. Daftar prefiks, filter AS-path, plafon prefiks maksimum, dan keputusan eksplisit soal rute default adalah batas minimumnya, dan semuanya berlaku di kedua arah. Peer yang menerima semua yang diterimanya dapat memberi Anda rute default yang diam-diam menggantikan akses internet lokal. Kedua arah memerlukan daftar terpisah, karena apa yang Anda terima dari peer dan apa yang Anda umumkan kepadanya adalah dua keputusan berbeda.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Berikutnya MTU menggigit. Enkapsulasi mengecilkan muatan yang dapat dipakai, sehingga pembaruan besar dapat membuat sesi yang tampak sempurna mandek: peer tetap aktif, prefiks tidak pernah datang, dan tidak ada yang jelas di log. Batasi TCP MSS pada antarmuka tunnel, atau tetapkan MTU tunnel dengan ruang untuk overhead, sebelum menyalahkan filter.

Ke mana paket luar tetap pergi

Paket terenkripsi dari satu situs ke situs lain keluar melalui apa pun yang dipilih router lokal untuk alamat publik peer. Jika kedua situs membeli transit dari penyedia yang sama, melintasi fasilitas metro yang sama, atau satu sisi berada di belakang NAT kelas operator, tunnel hanya bertahan dari kegagalan penyedia secara kebetulan. Menghitung ikon tunnel di alat pemantauan tidak memberi tahu Anda apa pun tentang itu.

Pemilihan rute dan pemasangan penerusan juga peristiwa terpisah. Sebuah prefiks dapat duduk di tabel BGP sebagai yang terbaik dan tetap hilang dari tabel penerusan, karena hop berikutnya tidak dapat diselesaikan atau rute yang lebih spesifik menang. Ketika seseorang melaporkan bahwa BGP mempelajari prefiks itu tetapi lalu lintas tidak mengalir, pertanyaan yang berguna adalah apakah ia terpasang dan ke hop berikutnya mana ia menunjuk.

Jawaban jujur untuk tinjauan desain adalah daftar dependensi bersama: sirkuit akses, penyedia hulu, fasilitas, dan perangkat stateful apa pun di jalur balik. Sesi melalui tunnel tidak dapat menghapus dependensi yang tidak berada di atasnya.

Tiga keputusan yang layak dipisahkan

Ketika sebuah desain mencampurkan hal-hal ini, setiap percakapan gangguan berputar-putar. Pisahkan dulu di atas kertas, lalu petakan masing-masing ke perangkat yang benar-benar menegakkannya.

Setiap baris punya pemilik berbeda. Yang pertama adalah negosiasi, yang kedua adalah konfigurasi pada perangkat Anda, yang ketiga sebagian besar jaringan orang lain. Permintaan perubahan yang menyebut baris yang disentuhnya jauh lebih mudah disetujui daripada yang mengatakan masalah BGP.

Mode kegagalan yang layak direncanakan

Menerima rute ringkasan peer adalah luka yang paling umum ditimbulkan sendiri. Seseorang mengumumkan agregat pendek untuk menyederhanakan pertukaran, sisi jauh menerimanya, dan lalu lintas untuk rentang yang tidak berada di belakang tunnel mengikuti tunnel dan mati. Saring pada prefiks persis yang diharapkan, atau gunakan daftar prefiks dengan batas yang benar, dan jangan pernah menerima agregat telanjang karena itu membuat sesi tampak rapi.

Waktu penarikan adalah yang kedua. Deteksi bergantung pada timer tahan, BFD jika Anda mengaktifkannya, deteksi peer mati tunnel, dan seberapa cepat sisi jauh berhenti mengumumkan. Sesi yang ada adalah masalah terpisah: rute baru dapat memulihkan koneksi baru sementara sesi TCP yang sudah terbentuk tetap memakai alamat basi, dan firewall stateful atau NAT di jalur dapat menahan entri yang tidak lagi cocok. Taruh pemulihan aplikasi dalam kriteria penerimaan alih-alih mengasumsikan perubahan rute menyelesaikan semuanya.

Yang ketiga adalah asimetri jalur balik. Lalu lintas dapat tiba melalui tunnel dan kembali melalui tautan penyedia yang tidak pernah dimaksudkan untuk membawanya, yang muncul sebagai audio satu arah, handshake gagal, atau firewall yang membuang balasan. Periksa kedua arah secara terpisah.

Apa yang ditulis ke kontrak, dan cara memverifikasinya

Minta prefiks yang diizinkan secara tertulis: siapa yang berwenang menciptakan setiap rentang, apakah rute default diizinkan, dan keluarga alamat mana yang didukung layanan tunnel. RFC 8212 menjadikan kebijakan impor dan ekspor eksplisit sebagai ekspektasi untuk eBGP dalam implementasi yang mengikutinya, jadi peer yang masih mengandalkan perilaku implisit menerima apa pun layak dipertanyakan.

Lalu verifikasi dari perangkat, bukan dari diagram. Perintah berguna pada router bergaya FRR:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Tambahkan dua pengamatan yang tidak dapat diberikan tabel rute. Tangkap pada antarmuka luar untuk memastikan alamat mana yang sebenarnya dituju paket terenkapsulasi, misalnya tcpdump -ni eth0 udp port 51820 untuk tunnel WireGuard, atau filter ESP untuk IPsec. Lalu telusuri menuju alamat publik peer dan bandingkan hop dengan trace di dalam tunnel; jika keduanya mengikuti rantai penyedia yang sama, redundansi Anda hidup dalam kebijakan rute, bukan di jaringan.

Terakhir, uji penarikan dengan sengaja. Turunkan tunnel selama jendela pemeliharaan, catat berapa lama prefiks tetap terpasang, apa yang terjadi pada sesi yang ada, dan apakah sisi jauh jatuh ke rute yang benar-benar akan Anda terima. Latihan itu lebih banyak bicara tentang desain daripada diagram mana pun.

Rute bukan otorisasi. Prefiks yang Anda sepakati untuk ditukar tidak mengatakan apa pun tentang pengguna mana yang boleh menjangkau layanan mana di belakang tunnel, jadi pertahankan autentikasi, layanan yang diizinkan, dan firewall host tepat di tempatnya semula. Peer yang terjangkau juga bukan izin untuk transit tanpa batas atau menciptakan alamat sembarangan, dan wewenang semacam itu masuk ke kontrak sebagai pertanyaan komersial, bukan ke baris kebijakan BGP.

• Sebutkan prefiks yang boleh diciptakan setiap sisi, dan yang tidak boleh pernah diterimanya.
• Batasi MSS pada tunnel dan pastikan pembaruan besar benar-benar tiba.
• Daftar dependensi underlay bersama, bukan jumlah tunnel.
• Ukur waktu penarikan nyata dan catat apa yang dilakukan aplikasi.