Menggunakan Azure Firewall untuk merutekan topologi multi-hub dan spoke

Topologi hub-and-spoke adalah pola arsitektur jaringan umum di Azure yang mengonsolidasikan sumber daya jaringan dan memusatkan layanan jaringan. Topologi ini menyediakan konektivitas dan keamanan jaringan ke jaringan virtual yang disebarkan di berbagai langganan atau penyewa.

Anda dapat menerapkan arsitektur hub-and-spoke dengan dua cara:

• Hub dan spoke yang dikelola sendiri (tradisional): Anda mempertahankan kontrol penuh atas jaringan virtual hub dan konfigurasi perutean.
• Virtual WAN: Microsoft mengelola jaringan virtual hub dan menyederhanakan administrasi melalui fitur seperti tujuan perutean dan kebijakan perutean.

Artikel ini berfokus pada topologi hub-and-spoke yang dikelola sendiri di mana Anda memiliki visibilitas dan kontrol penuh atas jaringan virtual hub dan penyebaran Azure Firewall.

Anda dapat mengurangi overhead administrasi implementasi hub-and-spoke yang dikelola sendiri dengan menggunakan Azure Virtual Network Manager (AVNM). AVNM dapat mengotomatiskan konfigurasi Azure Route Tables, tetapi desain dan teknik keseluruhan tidak berubah dibandingkan dengan pendekatan manual. Konten artikel ini berlaku baik Anda menggunakan AVNM atau mengonfigurasi secara manual topologi hub-and-spoke yang dikelola sendiri.

Alternatif untuk Tabel Rute Azure di jaringan virtual spoke adalah menyuntikkan rute ke subnet dengan Azure Route Server, seperti yang didokumenkan dalam Injeksi rute default di jaringan virtual spoke. Namun, pola ini umumnya tidak digunakan karena kompleksitas yang dapat muncul dari interaksi antara Azure Route Server dan VPN atau gateway jaringan virtual ExpressRoute.

Dalam penyiapan hub-and-spoke yang dikelola sendiri:

• Hub: Jaringan virtual yang berfungsi sebagai titik konektivitas pusat ke jaringan lokal Anda melalui VPN, ExpressRoute, atau Software-Defined Wide Area Network (SD-WAN). Perangkat keamanan jaringan seperti firewall disebarkan di jaringan virtual hub.
• Spokes: Jaringan virtual yang melakukan peering dengan hub dan menjadi host untuk beban kerja Anda.

Untuk beban kerja yang tersebar di beberapa wilayah, Anda biasanya menempatkan satu hub di setiap wilayah untuk mengagregasi lalu lintas dari spoke di wilayah tersebut. Diagram di bawah ini menunjukkan arsitektur hub-and-spoke yang dikelola sendiri pada dua wilayah, masing-masing memiliki dua jaringan virtual spoke:

Arsitektur satu wilayah hub-and-spoke

Untuk memahami desain multi-wilayah, Anda harus terlebih dahulu memahami konsep wilayah tunggal. Diagram berikut menunjukkan konfigurasi tabel perutean untuk wilayah pertama:

Pertimbangkan persyaratan perutean untuk setiap potensi arus lalu lintas dalam desain wilayah tunggal untuk memahami konfigurasi rute yang ditentukan pengguna:

• Lalu lintas antar-spoke: Spoke tidak saling terhubung, dan peering jaringan virtual tidak bersifat transitif. Setiap spoke tahu cara merutekan ke jaringan virtual hub secara default, tetapi tidak ke spoke lain. Rute untuk 0.0.0.0/0 yang diterapkan pada semua subnet spoke mencakup lalu lintas spoke-ke-spoke.
• Lalu lintas spoke-ke-internet: Rute 0.0.0.0/0 di tabel rute spoke juga mencakup lalu lintas yang dikirim ke internet publik. Rute ini menggantikan rute sistem yang disertakan dalam subnet publik secara bawaan. Untuk informasi selengkapnya, lihat Akses keluar default di Azure.
• Lalu lintas internet-ke-spoke: Lalu lintas dari internet ke spoke biasanya melalui Azure Firewall terlebih dahulu. Azure Firewall memiliki aturan Destination Network Address Translation (DNAT) yang dikonfigurasi, yang juga menerjemahkan alamat IP sumber (Terjemahan Alamat Jaringan Sumber atau SNAT). Beban kerja di jaringan spoke melihat lalu lintas jaringan sebagai lalu lintas yang berasal dari subnet Azure Firewall. Peering jaringan virtual membuat rute sistem ke hub (10.1.0.0/24), sehingga para spoke tahu cara merutekan lalu lintas kembali.
• Lalu lintas dari lokal ke spoke dan dari spoke ke lokal: Pertimbangkan setiap arah secara terpisah:
  • Lalu lintas lokal ke spoke: Lalu lintas tiba dari jaringan lokal ke gateway VPN atau ExpressRoute. Dengan perutean default di Azure, rute sistem dibuat di GatewaySubnet (dan subnet lain di jaringan virtual hub) untuk setiap spoke. Anda harus menggantikan rute sistem ini dan mengkonfigurasi hop berikutnya ke alamat IP privat Azure Firewall. Dalam contoh ini, Anda memerlukan dua rute dalam tabel rute yang terkait dengan subnet gateway, satu untuk setiap spoke (10.1.1.0/24 dan 10.1.2.0/24). Menggunakan ringkasan seperti 10.1.0.0/16 yang mencakup semua jaringan virtual spoke tidak dapat digunakan karena rute yang disuntikkan oleh sistem oleh hubungan jaringan virtual di subnet gateway lebih spesifik (/24 dibandingkan dengan ringkasan /16). Tabel rute ini harus mengaktifkan tombol menyebarkan rute gateway (diatur ke Ya), jika tidak, perutean gateway bisa menjadi tidak dapat diprediksi.
  • Spoke-ke-trafik di lokasi: Peering jaringan virtual antara hub dan spoke harus Izinkan Transit Gateway di sisi hub dan Gunakan Gerbang Jarak Jauh di sisi spoke. Pengaturan ini diperlukan agar gateway VPN dan ExpressRoute mengiklankan awalan spoke melalui Border Gateway Protocol (BGP) ke jaringan lokal. Pengaturan ini juga menyebabkan spokes mempelajari awalan yang diperkenalkan dari jaringan lokal ke Azure secara default. Karena awalan lokal lebih spesifik daripada rute 0.0.0.0/0 yang ditentukan pengguna dalam tabel rute spoke, lalu lintas dari spoke ke lokal akan melewati firewall secara default. Untuk mencegah situasi ini, atur tombol Menyebarkan Rute Gateway ke Tidak di tabel rute spoke agar awalan pada jaringan internal tidak dipelajari dan rute 0.0.0.0/0 digunakan untuk lalu lintas ke di lokasi.

Catatan

Gunakan prefiks IP jaringan virtual spoke yang tepat dalam tabel rute yang terkait dengan subnet gateway, bukan ringkasan jaringan. Rute sistem yang diperkenalkan oleh peering antar jaringan virtual dengan spoke menggantikan rute yang ditentukan pengguna Anda karena lebih spesifik.

Anda dapat mengelola kedua tabel rute yang terkait dengan "spoke subnets" dan tabel rute yang terkait dengan "gateway subnet" menggunakan Azure Virtual Network Manager untuk mengurangi beban kerja administratif. Untuk informasi selengkapnya, lihat Menggunakan Azure Firewall sebagai hop berikutnya.

Beban kerja jaringan virtual hub

Jika Anda menyebarkan beban kerja di jaringan virtual hub (seperti pengontrol domain Active Directory, server DNS, atau infrastruktur bersama lainnya), ini meningkatkan kompleksitas desain hub-and-spoke. Kami menyarankan agar Anda menghindari penempatan beban kerja di hub dan sebaliknya menyebarkannya di spoke khusus untuk layanan bersama.

Bagian ini menjelaskan konfigurasi yang diperlukan untuk beban kerja hub sehingga Anda dapat mengevaluasi apakah kompleksitas ini dapat diterima untuk kebutuhan Anda. Kami juga menjelaskan kesalahan umum yang dapat menyebabkan lalu lintas asimetris dan penurunan paket.

Diagram berikut menunjukkan desain wilayah tunggal dengan subnet beban kerja di jaringan virtual hub:

Detail pentingnya adalah bahwa rute yang ditentukan pengguna yang dikonfigurasi di subnet gateway dan subnet spoke ditentukan untuk subnet beban kerja tertentu dan bukan untuk seluruh awalan jaringan virtual hub:

• Konfigurasi subnet gateway: Mengatur rute di subnet gateway untuk seluruh jaringan virtual hub (10.1.0.0/24 dalam contoh ini) menggantikan rute sistem untuk jaringan virtual hub. Hal ini menyebabkan lalu lintas kontrol intra-subnet antara gateway VPN atau ExpressRoute dikirim ke firewall, berpotensi mengganggu operasi gateway.
• Konfigurasi subnet spoke: Mengonfigurasi rute di subnet spoke yang terhubung dengan seluruh jaringan virtual hub (10.1.0.0/24 dalam contoh ini) menggantikan rute sistem yang dibuat oleh peering dengan jaringan virtual hub. Semua lalu lintas yang diarahkan ke hub akan dikirim ke Azure Firewall, termasuk lalu lintas yang bersumber dari Azure Firewall itu sendiri, seperti lalu lintas dari internet ke spoke yang melalui Penerjemahan Alamat Jaringan Sumber (SNAT). Konfigurasi ini memperkenalkan lalu lintas asimetris dan menyebabkan penurunan paket.

Catatan

Jika Anda menyebarkan beban kerja di jaringan virtual hub, jangan gunakan seluruh awalan IP jaringan virtual di rute yang ditentukan pengguna Anda.

Inspeksi lalu lintas antar-subnet

Dalam pengaturan saat ini, lalu lintas antar spoke dikirim ke firewall, tetapi lalu lintas intra-spoke tetap berada dalam jaringan virtual spoke dan dikontrol menggunakan Kelompok Keamanan Jaringan. Desain ini menganggap jaringan virtual sebagai batas keamanan: firewall hanya memeriksa lalu lintas yang keluar atau memasuki jaringan virtual.

Untuk memeriksa lalu lintas antar subnet di jaringan virtual spoke yang sama, ubah tabel rute yang terkait dengan subnet spoke seperti yang ditunjukkan dalam diagram berikut:

Dalam diagram sebelumnya, dua subnet spoke diimplementasikan di setiap jaringan virtual spoke, dan tabel rute untuk spoke dalam jaringan virtual A2 dijelaskan. Mengirim lalu lintas antar-subnet ke firewall mengharuskan setiap subnet memiliki tabel rute terpisah karena rute yang akan diinstal di setiap subnet berbeda.

Untuk subnet A21, Anda memerlukan dua rute tambahan ini:

• Rute ke 10.1.2.0/24: Menggantikan rute sistem untuk lalu lintas internal jaringan virtual. Tanpa rute lain, semua lalu lintas jaringan intra-virtual dikirim ke Azure Firewall, bahkan lalu lintas antara komputer virtual di subnet yang sama.
• Rutekan ke 10.1.2.0/26 dengan Hop Virtual Network berikutnya: Pengecualian untuk rute sebelumnya, sehingga lalu lintas dalam subnet tertentu ini tidak dikirim ke firewall tetapi dirutekan secara lokal dalam jaringan virtual. Rute ini khusus untuk setiap subnet, itulah sebabnya Anda memerlukan tabel rute terpisah untuk setiap subnet.

Appliance virtual jaringan SD-WAN

Jika Anda menggunakan SD-WAN Network Virtual Appliances (NVA) alih-alih gateway VPN atau ExpressRoute, desainnya serupa, seperti yang ditunjukkan dalam diagram berikut:

Ada berbagai cara untuk mengintegrasikan NVA SD-WAN di Azure. Untuk informasi selengkapnya, lihat integrasi SD-WAN dengan topologi jaringan hub-and-spoke Azure. Artikel ini memperlihatkan integrasi menggunakan Azure Route Server, salah satu metode paling umum untuk merutekan lalu lintas ke jaringan SD-WAN. NVA SD-WAN mengiklankan awalan lokal ke Azure Route Server melalui BGP. Azure Route Server menyuntikkan prefiks ini ke subnet Azure Firewall agar Azure Firewall memiliki informasi perutean untuk jaringan di lokasi. Spoke tidak mempelajari awalan lokal karena opsi "Sebarkan rute gateway" dinonaktifkan di tabel rute spoke.

Jika Anda tidak ingin mengonfigurasi awalan setiap jaringan virtual spoke dalam tabel rute yang terkait dengan subnet NVA, Anda dapat menempatkan NVA SD-WAN di jaringan virtual khusus mereka. Jaringan virtual NVA tidak mempelajari awalan spoke karena tidak di-peering secara langsung, dan rute ringkasan dimungkinkan seperti yang ditunjukkan dalam diagram berikut:

Arsitektur hub-and-spoke antar wilayah

Setelah Anda memahami cara kerja lalu lintas di dalam satu wilayah hub-and-spoke, memperluas desain ke arsitektur multi-wilayah cukup mudah. Diagram berikut menunjukkan desain jaringan yang diperbarui dengan hub di dua wilayah (A dan B):

Satu-satunya tambahan untuk konfigurasi adalah tabel rute yang terkait dengan subnet Azure Firewall di setiap wilayah. Setiap jaringan virtual hub hanya tahu prefiks dari jaringan virtual yang dihubungkan secara peering langsung, sehingga tidak ada perutean untuk prefiks spoke yang jauh. Tambahkan rute yang ditentukan pengguna untuk setiap subnet Azure Firewall sehingga lalu lintas untuk setiap wilayah dirutekan ke Azure Firewall yang sesuai.

Dalam contoh ini, setiap wilayah dapat dengan mudah dirangkum:

• Wilayah A berisi awalan di 10.1.0.0/16
• Wilayah B berisi awalan di 10.2.0.0/16

Menentukan alamat IP di setiap wilayah yang dapat dengan mudah diringkas membuat konfigurasi routing Anda lebih sederhana. Jika tidak, Anda perlu membuat satu rute untuk setiap hub jarak jauh.

Aktifkan Propagate gateway routes pada tabel rute subnet Azure Firewall sehingga firewall dapat mempelajari rute di lokasi dari gateway VPN dan ExpressRoute.

Catatan

Jika Azure Firewall disebarkan tanpa NIC manajemen, subnet Azure Firewall memerlukan rute default dengan hop berikutnya "Internet" untuk menambahkan rute yang lebih spesifik seperti yang dijelaskan sebelumnya.

Untuk menyederhanakan manajemen rute yang ditentukan pengguna di lingkungan multi-wilayah, Anda dapat menggunakan Azure Virtual Network Manager. Untuk informasi selengkapnya, lihat Mengelola rute yang ditentukan pengguna di beberapa topologi hub-and-spoke dengan AVNM.

Langkah berikutnya

• Pelajari cara menyebarkan dan mengonfigurasi Azure Firewall.