Merutekan lalu lintas antara dua cabang melalui gateway VPN Azure
Dua koneksi Site-to-Site pada satu gateway VPN Azure dapat meneruskan lalu lintas cabang, tetapi hanya ketika kedua ujung mempelajari prefiks dan jalur balik LAN tersedia.
Dua cabang dapat bertukar lalu lintas melalui gateway VPN Azure tanpa terowongan langsung di antara keduanya. Setiap cabang membuka koneksi Site-to-Site ke gateway yang sama, dan gateway meneruskan prefiks yang dipelajari antara kedua koneksi. Yang membuat ini bekerja bukan terowongan kedua, melainkan pertukaran rute: cabang A harus mempelajari prefiks cabang B, dan B mempelajari prefiks A. Telusuri pemeriksaan di bawah ini secara berurutan dan berhenti pada pemeriksaan pertama yang gagal, karena setiap langkah berikutnya bergantung padanya.
Prasyarat, sebelum Anda mengonfigurasi apa pun
Empat kondisi menentukan apakah desain ini dapat bekerja sama sekali. Gateway harus berbasis rute dan berada pada SKU yang mendukung BGP, kedua koneksi harus memiliki BGP aktif, ruang alamat cabang tidak boleh tumpang tindih, dan tidak ada pihak yang boleh mengandalkan NAT untuk menyembunyikan prefiks aslinya.
Rencanakan ASN dengan sengaja. Nilai bawaan terdokumentasi Azure adalah 65515, dan setiap router cabang memerlukan ASN privatnya sendiri yang tidak bentrok dengan gateway atau cabang lainnya. Menggunakan kembali nilai bawaan tanpa memeriksa konfigurasi gateway yang ada adalah cara sebuah jalur AS ditolak nanti.
Pastikan juga Anda tidak mengharapkan perilaku peering VNet. Gateway menukar rute antara dua koneksi yang Anda konfigurasi; gateway tidak membuat peering arbitrer menjadi transitif. Jika jaringan ketiga harus menjangkau kedua cabang, jaringan itu memerlukan koneksinya sendiri atau jalur rutenya sendiri, bukan asumsi bahwa gateway akan menyebarkan lalu lintas. Tuliskan batas itu sebelum jendela perubahan pertama, karena itulah keputusan desain yang orang-orang tinjau kembali saat situs baru ditambahkan nanti.
Konfigurasikan dalam urutan ini
Setiap langkah memiliki hasil yang dapat diamati, jadi jangan lanjut sampai hasil itu muncul.
- Aktifkan BGP pada gateway jaringan virtual dan catat ASN serta alamat peer-nya.
- Buat gateway jaringan lokal per cabang dengan ruang alamat asli cabang itu, ASN-nya, dan alamat peer BGP-nya.
- Buat setiap koneksi Site-to-Site dan aktifkan BGP pada koneksi itu sendiri.
- Konfigurasikan router cabang untuk melakukan peering dengan alamat gateway yang ditetapkan Azure, bukan dengan titik akhir IKE publik gateway berdasarkan asumsi.
Langkah keempat adalah tempat sebagian besar upaya tersendat. Alamat peer BGP yang dilaporkan Azure adalah yang harus digunakan router cabang sebagai tetangga, dan itu tidak selalu alamat yang diharapkan orang dari diagram terowongan.
Umumkan prefiks cabang itu sendiri, misalnya 10.10.0.0/16 dari A dan 10.20.0.0/16 dari B. Jangan mengumumkan rute bawaan atau agregat lebar untuk menutupi jaringan spesifik yang hilang; celah itu kembali nanti sebagai lubang hitam yang sunyi.
Verifikasi pertukaran rute di kedua ujung
Status koneksi bukanlah pemeriksaannya. IPsec dapat aktif di kedua koneksi sementara tidak ada prefiks yang menyeberang di antaranya. Baca peer BGP gateway dan rute yang dipelajarinya, lalu pastikan rute menuju cabang lain muncul sebagai jalur yang dapat digunakan.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Prefiks yang ada di tabel BGP masih dapat kalah dalam keputusan penerusan dari rute statis atau prefiks yang lebih spesifik. Periksa rute yang dipilih, bukan hanya yang diterima.
Ikuti jalur balik di sisi LAN
Inilah bagian yang tampak benar di Azure dan gagal di lokasi. Host di cabang A mengirim paketnya ke router VPN A hanya jika router itu adalah gateway bawaannya, atau jika host atau gateway-nya memiliki rute untuk prefiks B. Hal yang sama harus berlaku di arah sebaliknya.
Jika sakelar inti terpisah adalah gateway bawaan LAN, sakelar itu memerlukan rute menuju cabang lain yang menunjuk ke router VPN. Tanpanya, permintaan datang dan balasan keluar melalui jalur internet, dan pengguna melihat koneksi yang terbuka lalu menggantung.
Jangan beralih ke grup keamanan jaringan pada subnet gateway untuk memperbaiki ini. Subnet itu memiliki persyaratannya sendiri dan NSG di sana bukan pengganti yang didukung untuk kebijakan sisi cabang. Penyaringan seharusnya berada di firewall cabang dan pada beban kerja itu sendiri, tempat aturannya dapat ditinjau oleh pemiliknya. Memindahkan aturan itu ke NSG subnet juga menyembunyikannya dari tim yang akan men-debug gangguan berikutnya.
Izinkan operasinya, lalu buktikan dengan uji yang ditolak
Rute yang dipelajari bukan izin. Izinkan sumber, tujuan, dan layanan yang benar-benar Anda butuhkan melalui firewall cabang dan kebijakan titik akhir, dan biarkan sisanya ditolak.
Uji dari beban kerja biasa di cabang A ke layanan nyata di cabang B, pastikan balasannya, lalu coba operasi yang seharusnya tetap dilarang. Lalu lintas yang dihasilkan perangkat VPN itu sendiri dapat memakai alamat sumber berbeda dan melewati tahap perutean LAN, jadi ping yang berhasil dari router membuktikan lebih sedikit daripada yang tampak.
Akhiri dengan menuliskan empat fakta: prefiks yang dipertukarkan, ASN yang digunakan, jalur balik LAN untuk setiap sisi, dan kebijakan yang mengizinkan layanan. Jika salah satunya hilang, penyiapan berfungsi sampai perubahan pertama, lalu tidak ada yang bisa menjelaskan mengapa.