Bagikan melalui

Injeksi rute default dalam jaringan virtual spoke

  • Artikel

Salah satu arsitektur paling umum di Azure adalah desain hub dan spoke, di mana beban kerja yang disebarkan dalam jaringan virtual spoke (VNet) mengirim lalu lintas melalui perangkat jaringan bersama yang ada di VNet hub. Rute yang ditentukan pengguna (UDR) biasanya perlu dikonfigurasi di VNet spoke untuk mengarahkan lalu lintas ke perangkat keamanan di hub. Namun, desain ini mengharuskan administrator untuk mengelola rute ini di banyak spoke.

Azure Route Server menawarkan titik terpusat di mana appliance virtual jaringan (NVA) dapat mengiklankan rute yang disuntikkannya di VNet spoke. Dengan cara ini, administrator tidak perlu membuat dan memperbarui tabel rute di VNet spoke.

Topologi

Diagram berikut menggambarkan desain hub dan spoke sederhana dengan VNet hub dan dua VNet spoke. Di hub, appliance virtual jaringan dan Route Server telah disebarkan. Tanpa Route Server, rute yang ditentukan pengguna harus dikonfigurasi di setiap spoke. UDR ini biasanya akan berisi rute default untuk 0.0.0.0/0 yang mengirim semua lalu lintas dari VNet spoke melalui NVA. Skenario ini dapat digunakan, misalnya, untuk memeriksa lalu lintas untuk tujuan keamanan.

Diagram memperlihatkan topologi hub dan spoke dasar.

Dengan Route Server di VNet hub, anda tidak perlu menggunakan rute yang ditentukan pengguna. NVA mengiklankan prefiks jaringan ke Route Server, yang menyuntikkannya sehingga muncul di rute efektif komputer virtual apa pun yang disebarkan di VNet hub atau VNet spoke yang di-peering dengan VNet hub dengan pengaturan Gunakan gateway jaringan virtual jarak jauh atau Route Server.

Konektivitas ke lokal melalui NVA

Jika NVA digunakan untuk menyediakan konektivitas ke jaringan lokal melalui VPN IPsec atau teknologi SD-WAN, mekanisme yang sama dapat digunakan untuk menarik lalu lintas dari spoke ke NVA. Selain itu, NVA dapat mempelajari awalan Azure dari Azure Route Server secara dinamis, dan mengiklankannya dengan protokol perutean dinamis ke lokal. Diagram berikut menjelaskan penyiapan ini:

Diagram memperlihatkan topologi hub dan spoke dasar dengan konektivitas lokal melalui NVA.

Memeriksa lalu lintas privat melalui NVA

Bagian sebelumnya menggambarkan lalu lintas yang diperiksa oleh appliance virtual jaringan (NVA) dengan menyuntikkan 0.0.0.0/0 rute default dari NVA ke Route Server. Namun, jika Anda hanya ingin memeriksa lalu lintas spoke-to-spoke dan spoke-to-premises melalui NVA, Anda harus mempertimbangkan bahwa Azure Route Server tidak mengiklankan rute yang awalannya sama atau lebih lama daripada ruang alamat jaringan virtual yang dipelajari dari NVA. Dengan kata lain, Azure Route Server tidak akan menyuntikkan awalan ini ke jaringan virtual dan tidak akan diprogram pada NIC komputer virtual di hub atau VNet spoke.

Namun, Azure Route Server akan mengiklankan subnet yang lebih besar daripada ruang alamat VNet yang dipelajari dari NVA. Dimungkinkan untuk beriklan dari NVA supernet dari apa yang Anda miliki di jaringan virtual Anda. Misalnya, jika jaringan virtual Anda menggunakan ruang 10.0.0.0/16alamat RFC 1918 , NVA Anda dapat beriklan 10.0.0.0/8 ke Azure Route Server dan awalan ini akan disuntikkan ke hub dan spoke VNets. Perilaku VNet ini dirujuk di Tentang BGP dengan VPN Gateway.

Diagram memperlihatkan injeksi awalan privat melalui Azure Route Server dan NVA.

Penting

Jika Anda memiliki skenario di mana awalan dengan panjang yang sama diiklankan dari ExpressRoute dan NVA, Azure akan lebih memilih dan memprogram rute yang dipelajari dari ExpressRoute. Untuk informasi lebih lanjut, lihat bagian berikutnya.

Koneksi ke lokal melalui gateway jaringan virtual

Jika VPN atau gateway ExpressRoute ada di jaringan virtual yang sama dengan Route Server dan NVA untuk menyediakan konektivitas ke jaringan lokal, rute yang dipelajari oleh gateway ini akan diprogram juga di VNet spoke. Rute ini mengambil alih rute default (0.0.0.0/0) yang disuntikkan oleh Route Server, karena rute tersebut akan lebih spesifik (masker jaringan yang lebih panjang). Diagram berikut menjelaskan desain sebelumnya, dengan gateway ExpressRoute telah ditambahkan.

Diagram memperlihatkan topologi hub dan spoke dasar dengan konektivitas lokal melalui NVA dan ExpressRoute.

Anda tidak dapat mengonfigurasi subnet di VNet spoke untuk hanya mempelajari rute dari Azure Route Server. Menonaktifkan "Menyebarluaskan rute gateway" dalam tabel rute yang terkait dengan subnet akan mencegah kedua jenis rute (rute dari gateway jaringan virtual dan rute dari Azure Route Server) untuk disuntikkan ke NIC di subnet tersebut.

Secara default, Route Server juga mengiklankan semua prefiks yang dipelajari dari NVA ke ExpressRoute. Ini mungkin tidak diinginkan, misalnya karena batas rute ExpressRoute atau Route Server itu sendiri. Dalam hal ini, NVA dapat mengumumkan rutenya ke Route Server termasuk komunitas no-advertise BGP (dengan nilai 65535:65282). Ketika Route Server menerima rute dengan komunitas BGP ini, Route Server menyuntikkannya ke subnet, tetapi tidak akan mengiklankannya ke rekan-rekan BGP lainnya (seperti gateway ExpressRoute atau VPN, atau NVA lainnya).

Koeksistensi SDWAN dengan ExpressRoute dan Azure Firewall

Kasus tertentu dari desain sebelumnya adalah ketika pelanggan memasukkan Azure Firewall dalam arus lalu lintas untuk memeriksa semua lalu lintas yang menuju jaringan lokal, baik melalui ExpressRoute atau melalui appliance SD-WAN/VPN. Dalam situasi ini, semua subnet spoke memiliki tabel rute yang mencegah spoke mempelajari rute apa pun dari ExpressRoute atau Route Server, dan memiliki rute default (0.0.0.0/0) dengan Azure Firewall sebagai hop berikutnya, seperti yang ditunjukkan diagram berikut:

Diagram memperlihatkan topologi hub dan spoke dengan konektivitas lokal melalui NVA untuk VPN dan ExpressRoute di mana Azure Firewall melakukan breakout.

Subnet Azure Firewall mempelajari rute yang berasal dari ExpressRoute dan VPN/SDWAN NVA, dan memutuskan apakah mengirim lalu lintas satu arah atau yang lain. Seperti yang dijelaskan di bagian sebelumnya, jika appliance NVA mengiklankan lebih dari 200 rute ke Route Server, ia harus mengirim rute BGP-nya yang ditandai dengan komunitas no-advertiseBGP . Dengan cara ini, awalan SDWAN tidak akan disuntikkan kembali ke lokal melalui Express-Route.

Simetri lalu lintas

Jika beberapa instans NVA digunakan dalam skenario aktif/aktif untuk ketahanan atau skalabilitas yang lebih baik, simetri lalu lintas adalah persyaratan jika NVA perlu menjaga status koneksi. Ini, misalnya, kasus Firewall Generasi Berikutnya.

  • Untuk konektivitas dari komputer virtual Azure ke internet publik, NVA menggunakan terjemahan alamat jaringan sumber (SNAT) sehingga lalu lintas keluar akan bersumber dari alamat IP publik NVA, sehingga mencapai simetri lalu lintas.
  • Untuk lalu lintas masuk dari internet ke beban kerja yang berjalan di komputer virtual, tambahan untuk penerjemahan alamat jaringan tujuan (DNAT), NVA harus melakukan terjemahan alamat jaringan sumber (SNAT), untuk memastikan bahwa lalu lintas kembali dari komputer virtual mendarat di instans NVA yang sama yang memproses paket pertama.
  • Untuk konektivitas Azure ke Azure, karena mesin virtual sumber akan mengambil keputusan perutean secara independen dari tujuan, diperlukan SNAT hari ini untuk mencapai simetri lalu lintas.

Beberapa instans NVA juga dapat disebarkan dalam penyiapan aktif/pasif, misalnya jika salah satunya mengiklankan rute yang lebih buruk (dengan jalur AS yang lebih panjang) dari rute yang lain. Dalam hal ini, Azure Route Server hanya akan memasukkan rute yang disukai di mesin virtual VNet, dan rute yang kurang disukai hanya akan digunakan jika instans NVA utama berhenti mengiklankan melalui BGP.

Route Server yang berbeda untuk mengiklankan rute ke Virtual Network Gateway dan ke VNet

Seperti yang diperlihatkan di bagian sebelumnya, Azure Route Server memiliki peran ganda:

  • Ini mempelajari dan mengiklankan rute ke/dari gateway jaringan virtual (VPN dan ExpressRoute)
  • Ini mengonfigurasi rute yang dipelajari di VNet-nya, dan pada VNet yang di-peering secara langsung

Fungsionalitas ganda ini sering kali menarik, tetapi terkadang dapat merugikan persyaratan tertentu. Misalnya, jika Route Server disebarkan di VNet dengan NVA yang mengiklankan rute 0.0.0.0/0 dan awalan iklan gateway ExpressRoute dari lokal, itu akan mengonfigurasi semua rute (baik 0.0.0.0/0 dari NVA dan awalan lokal) pada mesin virtual di VNet-nya dan VNet serekan langsung. Sebagai konsekuensinya, karena awalan lokal akan lebih spesifik daripada 0.0.0.0/0, lalu lintas antara lokal dan Azure akan melewati NVA. Jika ini tidak diinginkan, bagian sebelumnya dalam artikel ini telah menunjukkan cara menonaktifkan penyebaran BGP di subnet VM dan mengonfigurasi UDR.

Namun, ada pendekatan alternatif yang lebih dinamis. Dimungkinkan menggunakan Azure Route Server yang berbeda untuk fungsionalitas yang berbeda: salah satunya akan bertanggung jawab untuk berinteraksi dengan gateway jaringan virtual, dan yang lainnya untuk berinteraksi dengan perutean jaringan virtual. Diagram berikut memperlihatkan kemungkinan desain untuk ini:

Diagram memperlihatkan topologi hub dan spoke dasar dengan konektivitas lokal melalui ExpressRoute dan dua Route Server.

Route Server 1 di hub digunakan untuk menyuntikkan awalan dari SDWAN ke ExpressRoute. Karena VNet spoke di-peering dengan VNet hub tanpa Menggunakan gateway jaringan virtual jarak jauh atau Route Server (dalam peering VNet spoke) dan Gunakan gateway jaringan virtual ini atau Route Server (Transit gateway di hub VNet peering), VNet spoke tidak mempelajari rute ini (baik awalan SDWAN maupun awalan ExpressRoute).

Untuk menyebarluaskan rute ke VNet spoke, NVA menggunakan Route Server 2, yang disebarkan di VNet tambahan baru. NVA hanya akan menyebarkan satu 0.0.0.0/0 rute ke Route Server 2. Karena VNet spoke di-peering dengan VNet tambahan ini dengan Gunakan gateway jaringan virtual jarak jauh atau Route Server (dalam peering VNet spoke) dan Gunakan gateway jaringan virtual ini atau Route Server (Transit gateway di hub peering VNet), 0.0.0.0/0 rute akan dipelajari oleh semua komputer virtual dalam spoke.

Lompatan berikutnya untuk 0.0.0.0/0 rute adalah NVA, sehingga VNet spoke masih perlu di-peering ke VNet hub. Aspek penting lainnya yang perlu diperhatikan adalah bahwa VNet hub perlu di-peering ke VNet tempat Route Server 2 disebarkan, jika tidak, VNet tidak akan dapat membuat kedekatan BGP.

Jika lalu lintas dari ExpressRoute ke VNet spoke akan dikirim ke NVA firewall untuk diperiksa, tabel rute di GatewaySubnet masih diperlukan, jika tidak gateway jaringan virtual ExpressRoute akan mengirim paket ke komputer virtual menggunakan rute yang dipelajari dari peering VNet. Rute dalam tabel rute ini harus cocok dengan awalan spoke, dan hop berikutnya harus menjadi alamat IP NVA firewall (atau load balancer di depan NVA firewall, untuk redundansi). Firewall NVA dapat sama dengan NVA SDWAN dalam diagram di atas, atau dapat menjadi perangkat yang berbeda seperti Azure Firewall, karena SDWAN NVA dapat mengiklankan rute dengan hop berikutnya yang menunjuk ke alamat IP lain. Diagram berikut menunjukkan desain ini dengan penambahan Azure Firewall:

Catatan

Untuk lalu lintas apa pun dari lokal yang ditujukan untuk Titik Akhir Privat, lalu lintas ini akan melewati Firewall NVA atau Azure Firewall di hub. Namun, ini mengakibatkan perutean asimetris (yang dapat menyebabkan hilangnya konektivitas antara Titik Akhir Lokal dan Privat) saat Titik Akhir Privat meneruskan lalu lintas lokal ke Firewall. Untuk memastikan simetri perutean, aktifkan kebijakan jaringan Tabel Rute untuk titik akhir privat pada subnet tempat Titik Akhir Privat disebarkan.

Diagram memperlihatkan topologi hub dan spoke dasar dengan konektivitas lokal melalui ExpressRoute, Azure Firewall, dan dua Route Server.

Desain ini memungkinkan injeksi rute otomatis di VNet spoke tanpa gangguan dari rute lain yang dipelajari dari lingkungan ExpressRoute, VPN atau SDWAN, dan penambahan NVA firewall untuk inspeksi lalu lintas.

Konten terkait