Skenario: Merutekan lalu lintas melalui NVA
Saat bekerja dengan perutean hub Virtual WAN virtual, ada beberapa skenario yang tersedia. Dalam skenario NVA ini, tujuannya adalah untuk merutekan lalu lintas melalui NVA (Appliance Virtual Jaringan) untuk cabang ke VNet dan VNet ke cabang. Untuk mengetahui informasi tentang perutean hub virtual, lihat Tentang perutean hub virtual.
Catatan
Jika Anda telah menyiapkan rute sebelum kemampuan baru Cara mengonfigurasi perutean hub virtual tersedia, gunakan langkah-langkah dalam versi artikel berikut:
Rancang
Dalam skenario ini kita akan menggunakan konvensi penamaan berikut:
- "VNet NVA" untuk jaringan virtual di mana pengguna telah menyebarkan NVA dan telah menyambungkan jaringan virtual lain sebagai spoke (VNet 2 dan VNet 4 pada Figur 2 di bagian bawah artikel).
- "Spoke NVA" untuk jaringan virtual yang disambungkan ke VNet NVA (VNet 5, VNet 6, VNet 7, dan VNet 8 pada Figur 2 di bagian bawah artikel).
- "VNet Non-NVA" untuk jaringan virtual yang terhubung ke Virtual WAN yang tidak memiliki NVA atau VNet lain yang di-peering dengan mereka (VNet 1 dan VNet 3 di Gambar 2 lebih lanjut di artikel).
- "Hub" untuk Hub Azure Virtual WAN yang dikelola Microsoft, tempat VNet NVA disambungkan. VNet spoke NVA tidak perlu disambungkan ke hub Azure Virtual WAN, hanya perlu disambungkan ke VNet NVA.
Matriks konektivitas berikut, merangkum alur yang didukung dalam skenario ini:
Matriks konektivitas
| Dari | Kepada: | Spoke NVA | Vnet NVA | VNet Non-NVA | Cabang |
|---|---|---|---|---|---|
| Spoke NVA | → | Di atas Vnet NVA | Peering | Di atas Vnet NVA | Di atas Vnet NVA |
| Vnet NVA | → | Peering | Langsung | Langsung | Langsung |
| VNet Non-NVA | → | Di atas Vnet NVA | Langsung | Langsung | Langsung |
| Cabang | → | Di atas Vnet NVA | Langsung | Langsung | Langsung |
Masing-masing sel dalam matriks konektivitas menjelaskan bagaimana VNet atau cabang (sisi "Dari" alur, header baris dalam tabel) berkomunikasi dengan VNet atau cabang tujuan (sisi "Ke" dari alur, kolom header dalam huruf miring dalam tabel). "Langsung" berarti konektivitas disediakan secara asli oleh WAN Virtual, "Peering" berarti konektivitas disediakan oleh Rute yang Ditentukan Pengguna di VNet, "Over NVA VNet" berarti konektivitas melintasi NVA yang disebarkan di NVA VNet. Pertimbangkan hal berikut:
- NVA Spoke tidak dikelola oleh Virtual WAN. Akibatnya, mekanisme yang akan mereka komunikasikan ke VNet atau cabang lain dikelola oleh pengguna. Konektivitas ke VNet NVA disediakan oleh peering VNet, dan rute Default ke 0.0.0.0/0 menunjuk ke NVA karena lompatan berikutnya harus mencakup konektivitas ke internet, ke spoke lain, dan ke cabang
- VNet NVA tahu tentang spoke NVA mereka sendiri, tetapi tidak tentang spoke NVA yang terhubung ke VNet NVA lainnya. Misalnya, pada Figur 2 di bagian bawah artikel ini, VNet 2 mengetahui tentang VNet 5 dan VNet 6, tetapi tidak mengetahui tentang spoke lain seperti VNet 7 dan VNet 8. Rute statik diperlukan untuk memasukkan awalan spoke lain ke dalam VNet NVA
- Demikian pula, cabang dan VNet non-NVA tidak akan tahu tentang spoke NVA apa pun, karena spoke NVA tidak terhubung ke hub Virtual WAN. Akibatnya, rute statis juga diperlukan di sini.
Dengan mempertimbangkan bahwa spoke NVA tidak dikelola oleh Virtual WAN, semua baris lain menunjukkan pola konektivitas yang sama. Akibatnya, satu tabel rute (default) adalah:
- Jaringan virtual (VNet non-hub dan VNet hub pengguna):
- Tabel rute terkait: Default
- Menyebarkan ke tabel rute: Default
- Cabang:
- Tabel rute terkait: Default
- Menyebarkan ke tabel rute: Default
Namun, dalam skenario ini kita perlu memikirkan rute statik mana yang harus dikonfigurasi. Setiap rute statis memiliki dua komponen, satu bagian di hub Virtual WAN yang memberi tahu komponen Virtual WAN koneksi mana yang akan digunakan untuk setiap spoke, dan satu lagi dalam koneksi tertentu yang menunjuk ke alamat IP konkret yang ditetapkan ke NVA (atau ke load balancer di depan beberapa NVA), seperti yang ditunjukkan Gambar 1 :
Gambar 1
Dengan ini, rute statik yang kami butuhkan di tabel Default untuk mengirim lalu lintas ke spoke NVA di belakang VNet NVA adalah sebagai berikut:
| Deskripsi | Tabel rute | Rute statik |
|---|---|---|
| VNet 2 | Default | 10.2.0.0/16 -> eastusconn |
| VNet 4 | Default | 10.4.0.0/16 -> weconn |
Sekarang, rute statis ini akan diiklankan ke cabang lokal Anda, dan hub Virtual WAN akan mengetahui koneksi VNet mana yang akan diteruskan lalu lintasnya. Namun, koneksi VNet perlu mengetahui apa yang harus dilakukan saat menerima lalu lintas ini: Di sinilah tabel rute koneksi digunakan. Di sini kita akan menggunakan awalan yang lebih pendek (/24 alih-alih yang lebih panjang /16), untuk memastikan bahwa rute ini memiliki preferensi atas rute yang diimpor dari VNet NVA (VNet 2 dan VNet 4):
| Deskripsi | Connection | Rute statik |
|---|---|---|
| VNet 5 | eastusconn | 10.2.1.0/24 -> 10.2.0.5 |
| VNet 6 | eastusconn | 10.2.2.0/24 -> 10.2.0.5 |
| VNet 7 | weconn | 10.4.1.0/24 -> 10.4.0.5 |
| VNet 8 | weconn | 10.4.2.0/24 -> 10.4.0.5 |
Sekarang VNet NVA, VNet non-NVA, dan cabang mengetahui cara menjangkau semua spoke NVA. Untuk informasi selengkapnya tentang perutean hub virtual, lihat Tentang perutean hub virtual.
Sistem
Dalam Figur 2, ada dua hub; Hub1 dan Hub2.
Hub1 dan Hub2 disambungkan langsung ke VNet NVA VNet 2 dan VNet 4.
VNet 5 dan VNet 6 dipasangkan dengan VNet 2.
VNet 7 dan VNet 8 dipasangkan dengan VNet 4.
VNet 5,6,7,8 adalah spoke tidak langsung, tidak tersambung langsung ke hub virtual.
Gambar 2
Alur kerja skenario
Untuk menyiapkan perutean melalui NVA, berikut adalah langkah-langkah yang perlu dipertimbangkan:
Mengidentifikasi koneksi Vnet spoke NVA. Pada Gambar 2, mereka adalah VNet 2 Koneksi ion (eastusconn) dan VNet 4 Koneksi ion (weconn).
Pastikan ada UDR yang disiapkan:
- Dari IP NVA VNet 5 dan VNet 6 ke VNet 2
- Dari IP NVA VNet 7 dan VNet 8 ke VNet 4
Anda tidak perlu menghubungkan VNet 5,6,7,8 ke hub virtual secara langsung. Pastikan bahwa NSG di VNet 5,6,7,8 mengizinkan lalu lintas untuk cabang (VPN/ER/P2S) atau VNet yang disambungkan ke VNet jarak jauh. Misalnya, VNet 5,6 harus memastikan NSG mengizinkan lalu lintas untuk awalan alamat lokal dan VNet 7,8 yang disambungkan ke Hub 2 jarak jauh.
Virtual WAN tidak mendukung skenario di mana VNets 5,6 terhubung ke hub virtual dan berkomunikasi melalui IP NVA VNet 2; oleh karena itu kebutuhan untuk menghubungkan VNet 5,6 ke VNet2 dan demikian pula VNet 7,8 ke VNet 4.
Menambahkan entri rute statik yang diagregat untuk VNet 2,5,6 ke tabel rute Default Hub 1.
Catatan
Untuk menyederhanakan perutean dan mengurangi perubahan dalam tabel rute hub Virtual WAN, kami merekomendasikan peering BGP baru dengan hub Virtual WAN. Untuk informasi lebih lanjut, baca artikel berikut:
Mengonfigurasi rute statik untuk VNet 5,6 dalam koneksi jaringan virtual VNet 2. Untuk menyiapkan konfigurasi perutean untuk koneksi jaringan virtual, lihat perutean hub virtual.
Menambahkan entri rute statik yang diagregat untuk VNet 4,7,8 ke tabel rute Default Hub 1.
Ulangi langkah 2, 3 dan 4 untuk tabel rute Default Hub 2.
Ini menghasilkan perubahan konfigurasi perutean, seperti yang ditunjukkan pada Gambar 3.
Gambar 3
Langkah berikutnya
- Untuk informasi selengkapnya tentang Virtual WAN, lihat FAQ.
- Untuk informasi selengkapnya tentang perutean hub virtual, lihat Tentang perutean hub virtual.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk