Gambaran umum arsitektur Azure Network Virtual Appliances Firewall

Azure API Management
Azure Load Balancer
Azure Virtual Network
Azure VPN Gateway

Cloud mengubah cara desain infrastruktur, termasuk desain firewall, karena jaringan tidak lagi bersifat fisik atau LAN virtual. Tidak semua fitur jaringan fisik tersedia dalam jaringan virtual (VNet). Ini termasuk penggunaan alamat IP mengambang atau lalu lintas siaran dan yang memengaruhi implementasi arsitektur HA. Load balancer untuk Network Virtual Appliance (NVA) dapat/harus diimplementasikan dengan cara tertentu untuk mencapai arsitektur (HA) yang sangat tersedia dalam jaringan virtual. Panduan ini membahas pendekatan terstruktur untuk merancang HA firewall (FW) di Azure menggunakan peralatan virtual pihak ketiga.

Opsi untuk merancang NVA yang sangat tersedia

Saat menyebarkan arsitektur HA, ada beberapa opsi untuk menyediakan failover:

  • Tabel rute terkelola API Azure: Opsi ini menggunakan dua tabel rute, satu aktif, satu pasif untuk mengalihkan IP gateway aktif untuk semua layanan yang berjalan di VNet/subnet.
  • IP mengambang terkelola Azure API: Opsi ini menggunakan alamat IP sekunder pada FW yang dapat dipindahkan antara FW aktif dan siaga.
  • Load Balancer terkelola: Opsi ini menggunakan Azure Load Balancer untuk bertindak sebagai IP gateway untuk subnet, yang kemudian meneruskan lalu lintas ke FW aktif. Bahkan mungkin meneruskan lalu lintas aktif-aktif untuk memberikan load balancing yang sebenarnya.

Masalah dengan dua opsi pertama adalah bahwa failover itu sendiri lambat. FW harus menginstruksikan failover, yang pada dasarnya adalah "konfigurasi ulang" layanan Azure melalui penyebaran baru. Bergantung pada seberapa cepat penyebaran itu selesai, arus lalu lintas akan turun selama beberapa menit. Selain itu, tidak memungkinkan untuk konfigurasi aktif-aktif di mana kedua firewall beroperasi pada waktu yang sama.

Karena itulah opsi ketiga paling disukai. Waktu henti diminimalkan karena load balancer dapat gagal hampir seketika ke firewall siaga (dalam aktif-pasif) atau hanya menghapus beban dari firewall yang gagal (dalam aktif-aktif). Tetapi Anda tidak bisa hanya menggunakan load balancer sebagai "gateway default" karena itu dapat memengaruhi arus lalu lintas dan paket TCP yang harus memiliki status.

Firewall berkaki dua

Gambar berikut dimulai dengan dua FW (FW-1 & FW-2), dengan load balancer eksternal dan server backend S1.

Load Balancer Standar di depan dua NVA

Arsitektur ini adalah pengaturan sederhana, digunakan untuk lalu lintas masuk. Sebuah paket mengenai load balancer, yang memilih FW tujuan dari konfigurasinya. Firewall yang dipilih kemudian mengirimkan lalu lintas ke server backend (web). Jika FW-1 telah mengaktifkan SNAT, server S1 akan melihat lalu lintas yang berasal dari IP internal FW-1, sehingga juga akan mengirimkan balasan paket ke FW-1. Failover dapat terjadi dengan cepat pada FW-2 dalam skenario ini. Untuk lalu lintas keluar, kita bisa menambahkan load balancer lain di sisi internal. Ketika server S1 memulai lalu lintas, prinsip yang sama akan berlaku. Lalu lintas mengenai LB internal (iLB), yang memilih firewall yang kemudian menerjemahkan NAT untuk resolusi eksternal:

Load Balancer Standar di depan dan belakang dua NVA dengan zona tepercaya/tidak tepercaya

Firewall berkaki tiga

Masalah muncul saat kami menambahkan antarmuka lain ke firewall, dan Anda perlu menonaktifkan terjemahan NAT di antara zona internal. Dalam hal ini, lihat Subnet-B dan Subnet-C:

Load Balancer Standar di depan dan belakang dua NVA dengan tiga zona

Perutean L3 antara zona internal (Subnet-B dan Subnet-C) keduanya akan seimbang beban tanpa NAT. Pengaturan ini menjadi lebih jelas dengan melihat arus lalu lintas termasuk load-balancer dalam tampilan yang berbeda. Diagram di bawah ini menunjukkan tampilan di mana Load Balancer [iLB] internal ditautkan ke NIC tertentu pada FW:

Arus lalu lintas mendetail dengan FW berkaki 3 dengan Load Balancer

Dengan lalu lintas L3 (tanpa NAT), S2 akan melihat alamat IP S1 sebagai alamat sumber. S2 kemudian akan mengirimkan lalu lintas kembali untuk subnet B (yang dimiliki S1-IP) ke iLB di Subnet-C. Karena iLB di Subnet-B dan iLB di Subnet-C tidak menyinkronkan status sesinya, bergantung pada lalu lintas algoritme load-balancing dapat berakhir di FW-2. FW-2 secara default tidak tahu apa-apa tentang paket awal (hijau), sehingga akan memutuskan koneksi.

Beberapa vendor firewall mencoba untuk menjaga status koneksi antara firewall, tetapi mereka akan membutuhkan sinkronisasi yang hampir instan untuk memperbarui status koneksi. Periksa dengan vendor firewall Anda jika mereka merekomendasikan pengaturan ini.

Cara terbaik untuk mengatasi masalah ini adalah dengan menghilangkannya. Dalam contoh di atas, solusi ini berarti menghilangkan Subnet-C, yang membawa kita pada keunggulan VNet Virtual.

Mengisolasi host di subnet dengan Kelompok Keamanan Jaringan

Jika ada dua VM dalam satu subnet, Anda dapat menerapkan NSG yang mengisolasi lalu lintas di antara keduanya. Secara default, lalu lintas di dalam VNet sepenuhnya diizinkan. Menambahkan aturan Tolak semua di NSG, mengisolasi semua VM satu sama lain.

Memblokir lalu lintas subnet internet dengan NSG

VNet menggunakan router backend (virtual) yang sama

VNet/subnet menggunakan sistem router backend tunggal dari Azure dan dengan demikian, tidak perlu menentukan IP router untuk setiap subnet. Tujuan rute bisa di mana saja di VNET yang sama atau bahkan di luar.

NVA dengan NIC tunggal dan bagaimana lalu lintas mengalir

Dengan jaringan virtual, Anda dapat mengontrol rute di setiap subnet. Rute-rute ini juga dapat menunjuk ke satu IP di subnet lain. Pada gambar di atas, itu akan menjadi iLB di Subnet-D, yang memuat keseimbangan kedua firewall. Saat S1 memulai lalu lintas (hijau), bebannya akan seimbang, misalnya, FW-1. FW-1 kemudian akan tersambung ke S2 (masih hijau). S2 akan mengirimkan lalu lintas respons ke IP S1 (karena NAT dinonaktifkan). Karena tabel rute, S2 menggunakan IP iLB yang sama sebagai gatewaynya. iLB mungkin mencocokkan lalu lintas ke sesi awal, sehingga akan selalu mengarahkan lalu lintas ini kembali ke FW-1. FW-1 kemudian mengirimkannya ke S1, membentuk arus lalu lintas yang sinkron.

Agar pengaturan ini berfungsi, FW harus memiliki tabel rute (secara internal) yang mengarahkan Subnet-B dan Subnet-C ke subnet default GW. Subnet GW itu adalah IP pertama yang tersedia secara logis dalam rentang subnet di VNET itu.

Dampak pada layanan proksi terbalik

Saat Anda menyebarkan layanan proksi terbalik, biasanya layanan tersebut berada di belakang FW. Anda dapat meletakkannya sejajar dengan FW dan benar-benar merutekan lalu lintas melalui FW. Keuntungan dari penyiapan ini adalah bahwa layanan proksi terbalik akan melihat IP asli dari klien penghubung:

Diagram yang menunjukkan layanan proksi terbalik sejalan dengan NVA dan merutekan lalu lintas melalui firewall.

Untuk konfigurasi ini, tabel rute pada Subnet-E perlu mengarahkan Subnet-B dan Subnet-C melalui load balancer internal. Beberapa layanan proksi terbalik memiliki firewall bawaan yang memungkinkan Anda menghapus FW bersama-sama dalam alur jaringan ini. Firewall internal mengarah dari proksi terbalik langsung ke server Subnet-B/C.

Dalam skenario ini, SNAT akan diperlukan pada proksi terbalik juga untuk menghindari lalu lintas kembali mengalir dan ditolak oleh FW ke Subnet-A.

VPN/ER

Azure menyediakan layanan VPN/ER berkemampuan BGP/sangat tersedia melalui Gateway Azure Virtual Network. Sebagian besar arsitek menyimpannya untuk koneksi backend atau non-internet. Pengaturan ini berarti tabel perutean perlu mengakomodasi subnet di belakang koneksi ini juga. Meskipun tidak ada perbedaan besar pada konektivitas subnet-B/C, ada dalam desain lalu lintas kembali, melengkapi gambarannya:

Diagram yang menunjukkan layanan proksi terbalik yang mendukung layanan VPN/ER yang mendukung BGP/sangat tersedia melalui Gateway Azure Virtual Network.

Dalam arsitektur ini, lalu lintas yang mencapai FW dari, misalnya Subnet-B ke Subnet-X akan dikirim ke iLB, yang pada gilirannya mengirimkannya ke salah satu firewall. Rute internal di dalam FW akan mengirimkan lalu lintas kembali ke Subnet-GW (IP pertama yang tersedia di Subnet-D). Anda tidak harus mengirimkan lalu lintas langsung ke perangkat Gateway itu sendiri, karena rute lain di Subnet-D akan memiliki rute untuk Subnet-X yang mengarahkannya ke Gateway Virtual Network. Azure Networking akan menangani perutean yang sebenarnya.

Lalu lintas kembali yang berasal dari Subnet-X akan diteruskan ke iLB di Subnet-D. GatewaySubnet juga akan memiliki rute kustom yang mengarahkan Subnet-B-C ke iLB. Subnet-D tidak melalui iLB. Ini akan diperlakukan sebagai perutean antar-VNET reguler.

Meskipun tidak dalam gambar, masuk akal jika Subnet-B/C/D/Gateway juga menyertakan rute untuk Subnet-A yang mengarahkannya ke iLB. Pengaturan ini menghindari perutean VNET "biasa" untuk melewati FW. Ini karena Subnet-A hanyalah subnet lain di VNET menurut tumpukan jaringan Azure. Itu tidak akan memperlakukan Subnet-A berbeda, meskipun Anda memperlakukannya sebagai DMZ/Internet/dll.

Ringkasan

Singkatnya, cara Anda memperlakukan firewall di jaringan lokal (berbasis fisik/VLAN), dengan banyak antarmuka (virtual atau fisik) tidak sama dengan yang Anda lakukan di Azure. Jika perlu Anda masih bisa (sampai tingkat tertentu), tetapi ada cara yang lebih baik untuk memastikan Anda dapat meminimalkan waktu henti fail-over; memiliki implementasi aktif-aktif dan tabel perutean bersih.

Informasi selengkapnya tentang menggunakan load balancer sebagai gateway untuk semua lalu lintas dapat ditemukan di Ringkasan port ketersediaan tinggi.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Langkah berikutnya

Pelajari selengkapnya tentang teknologi komponen:

Jelajahi arsitektur terkait: