Mencegah kelelahan IPv4 di Azure

Artikel ini menjelaskan cara meminimalkan konsumsi ruang alamat privat saat Anda membangun jaringan besar di Azure. Anda mungkin perlu meminimalkan konsumsi ruang alamat jika kebijakan alokasi yang tepat tidak dibuat, dan Anda kehabisan alamat IP privat untuk ditetapkan ke jaringan virtual Azure. Artikel ini menyajikan dua metode untuk manajemen alamat IP yang tepat di Azure.

Detail skenario

Jaringan perusahaan biasanya menggunakan ruang alamat yang berada dalam rentang alamat IPv4 privat yang ditentukan dalam RFC 1918. Rentang alamat adalah 10.0.0.0/8, 172.16.0.0/12, dan 192.168.0.0/16. Di lingkungan lokal, rentang ini menyediakan alamat IP yang cukup untuk memenuhi persyaratan bahkan jaringan terbesar. Akibatnya, banyak organisasi mengembangkan praktik manajemen alamat yang memprioritaskan konfigurasi perutean sederhana dan proses tangkas untuk alokasi IP. Penggunaan ruang alamat yang efisien bukanlah prioritas.

Di cloud, jaringan hibrid besar mudah dibuat, dan beberapa pola arsitektur umum, seperti layanan mikro atau kontainerisasi, dapat menyebabkan peningkatan konsumsi alamat IP. Jadi penting untuk menyesuaikan praktik manajemen alamat tersebut. Di lingkungan cloud, perlakukan alamat IPv4 privat sebagai sumber daya terbatas.

Rentang alamat IP Azure Virtual Network

Di jaringan virtual Azure Anda, kami sarankan Anda menggunakan blok alamat yang ditentukan oleh RFC 1918. Blok alamat ini untuk jaringan privat tujuan umum dan tidak dapat dialihkan di internet publik.

Anda dapat menggunakan rentang lain, tetapi sebelum Anda menggunakan rentang tersebut di jaringan virtual Anda, baca dokumentasi Internet Assigned Numbers Authority (IANA) untuk memahami potensi implikasi ke lingkungan Anda. Anda bisa menggunakan rentang berikut:

• Ruang alamat bersama yang ditentukan oleh RFC 6598 untuk penerjemahan alamat jaringan (NAT) kelas operator yang diperlakukan sebagai ruang alamat privat di Azure Virtual Network. Blok alamat adalah 100.64.0.0/10.
• Alamat IP publik yang dapat dirutekan internet yang tidak dimiliki organisasi Anda. Praktik ini tidak disarankan karena sumber daya di jaringan virtual tidak dapat mengakses titik akhir internet yang diekspos melalui alamat IP publik.
• Blok alamat tujuan khusus yang ditentukan oleh IANA, seperti 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, dan 233.252.0.0/24.

Anda tidak dapat menggunakan rentang alamat IP berikut di jaringan virtual Azure:

• 224.0.0.0/4 (Multicast)
• 255.255.255.255/32 (Broadcast)
• 127.0.0.0/8 (Loopback)
• 169.254.0.0/16 (Link-local)
• 168.63.129.16/32 (DNS Internal)

Perataan zona pendaratan Azure

Rekomendasi dalam artikel ini adalah untuk skenario yang didasarkan pada arsitektur zona pendaratan Azure. Panduan ini mengasumsikan bahwa:

• Setiap wilayah memiliki topologi hub-and-spoke.
• Jaringan hub-and-spoke yang berada di berbagai wilayah terhubung satu sama lain melalui peering jaringan virtual global atau koneksi ke sirkuit atau sirkuit Azure ExpressRoute yang sama.
• Jaringan hub-and-spoke terhubung ke situs lokal melalui kombinasi sirkuit ExpressRoute dan VPN situs-ke-situs.

Diagram berikut menunjukkan contoh arsitektur. Rekomendasi ini sama-sama berlaku untuk jaringan yang dibangun di atas Azure Virtual WAN, yang juga memiliki jaringan hub-and-spoke di setiap wilayah.

Unduh file PowerPoint arsitektur ini.

Dalam skenario yang didasarkan pada arsitektur zona pendaratan Azure, aplikasi disebarkan di zona pendaratan mereka sendiri. Setiap zona pendaratan berisi jaringan virtual spoke yang di-peering ke hub regional. Jaringan virtual spoke adalah bagian integral dari jaringan perusahaan dan diberi alamat IPv4 yang dapat dirutekan. Alamat ini unik di seluruh jaringan perusahaan. Jadi, semua komponen arsitektur yang disebarkan di Azure Virtual Network menggunakan alamat IPv4 di ruang alamat jaringan perusahaan bahkan jika hanya beberapa komponen yang mengekspos titik akhir yang harus dapat dijangkau dari seluruh jaringan perusahaan. Komponen arsitektur ini mungkin merupakan komputer virtual, appliance virtual jaringan pihak pertama atau pihak ketiga (NVA), atau layanan platform-as-a-service (PaaS) yang disuntikkan jaringan virtual.

Untuk sisa artikel ini, komponen front-end mengacu pada komponen aplikasi yang dapat dijangkau dari seluruh jaringan perusahaan, atau dari luar zona pendaratan komponen. Komponen back-end mengacu pada komponen aplikasi yang tidak mengekspos titik akhir di jaringan perusahaan dan hanya perlu dijangkau dari dalam zona pendaratannya sendiri. Misalnya, aplikasi web yang mengekspos titik akhir adalah komponen front-end, dan database yang tidak mengekspos titik akhir adalah komponen back-end.

Bagian berikut menjelaskan dua metode untuk meminimalkan konsumsi ruang alamat privat saat Anda membangun jaringan besar di Azure.

Metode 1: Jaringan virtual spoke zona pendaratan yang tidak dapat dialihkan

RFC 1918 mengukir blok alamat IP dari ruang alamat IPv4 32-bit dan membuatnya tidak dapat dialihkan di internet publik, sehingga Anda dapat menggunakannya kembali di beberapa jaringan privat untuk komunikasi internal. Metode ini didasarkan pada prinsip yang sama yang berlaku untuk ruang alamat privat. Satu atau beberapa rentang alamat diukir dari seluruh ruang alamat privat yang digunakan oleh organisasi Anda dan dinyatakan tidak dapat dialihkan dalam jaringan perusahaan organisasi Anda. Rentang alamat digunakan kembali di beberapa zona pendaratan. Akibatnya, setiap zona pendaratan:

• Diberi ruang alamat yang dapat dirutekan yang terbuat dari satu atau beberapa rentang alamat. Organisasi Anda mengelola rentang alamat secara terpusat dan menetapkannya secara unik ke zona pendaratan untuk berkomunikasi dengan jaringan perusahaan. Alamat di ruang yang dapat dirutekan ditetapkan ke komponen front-end.
• Dapat menggunakan ruang alamat yang tidak dapat dialihkan, yang merupakan rentang alamat yang dinyatakan organisasi Anda tidak dapat dialihkan di jaringan perusahaan. Anda dapat menggunakan rentang yang dipesan ini untuk komunikasi internal di semua zona pendaratan. Alamat dalam ruang yang tidak dapat dialihkan ditetapkan ke komponen back-end.

Dalam jaringan hub dan spoke Azure yang dikelola pelanggan atau berdasarkan Virtual WAN, dua jaringan virtual spoke atau lebih tidak dapat memiliki ruang alamat IP yang tumpang tindih. Blok alamat yang tidak dapat dialihkan tidak dapat ditetapkan ke spoke zona pendaratan. Peering jaringan virtual bersifat nontransitif, sehingga jaringan virtual spoke zona pendaratan dapat melakukan peering dengan jaringan virtual spoke tingkat kedua yang memiliki ruang alamat yang tidak dapat dialihkan. Diagram berikut menunjukkan topologi jaringan virtual ganda untuk zona pendaratan.

Unduh file PowerPoint arsitektur ini.

Setiap zona pendaratan aplikasi berisi dua jaringan virtual yang di-peering. Satu jaringan virtual memiliki alamat IP yang dapat dirutekan dan menghosting komponen front-end. Jaringan virtual lainnya memiliki alamat IP yang tidak dapat dialihkan dan menghosting komponen back-end. Zona pendaratan yang dapat dirutekan berbicara serekan dengan hub regional. Zona pendaratan yang tidak dapat dialihkan berbicara serekan dengan zona pendaratan yang dapat dirutekan berbicara. Peering jaringan virtual bersifat nontransitif, sehingga awalan yang tidak dapat dialihkan tidak terlihat oleh hub regional atau jaringan perusahaan lainnya. Jaringan virtual yang dapat dirutekan tidak dapat menggunakan rentang alamat yang tidak dapat dialihkan. Beberapa organisasi memiliki ruang alamat terfragmentasi yang sudah ditetapkan ke jaringan yang dapat dirutekan. Mungkin sulit untuk mengidentifikasi blok alamat besar yang tidak digunakan dan menyatakannya tidak dapat dialihkan. Dalam hal ini, pertimbangkan alamat yang tidak digunakan yang tidak disertakan dalam ruang alamat RFC 1918. Diagram sebelumnya memberikan contoh alamat NAT kelas operator, seperti RFC 6598, dalam jaringan virtual spoke yang tidak dapat dialihkan.

Migrasi zona pendaratan jaringan virtual tunggal

Peering jaringan virtual menyediakan konektivitas lapisan-3 penuh antara dua jaringan virtual yang di-peering. Komponen aplikasi yang disebarkan di zona pendaratan jaringan virtual tunggal tradisional yang berkomunikasi satu sama lain melalui IP dapat dipindahkan dengan bebas antara jaringan virtual spoke yang dapat dirutekan dan tidak dapat dirutekan di zona pendaratan. Bagian ini menjelaskan dua pola migrasi umum.

Aplikasi berikut diekspos melalui pengontrol pengiriman aplikasi layer-7:

Unduh file PowerPoint arsitektur ini.

Aplikasi yang diekspos melalui pengontrol pengiriman aplikasi lapisan-7 dapat dipindahkan ke spoke yang tidak dapat dialihkan. Pengontrol pengiriman aplikasi adalah satu-satunya komponen front-end yang harus berada di spoke zona pendaratan yang dapat dirutekan.

Aplikasi berikut diekspos melalui penyeimbang muatan Azure:

Unduh file PowerPoint arsitektur ini.

Jika aplikasi mengekspos titik akhirnya melalui load balancer Azure, instans komputasi yang merupakan bagian dari kumpulan back-end penyeimbang beban harus tetap berada di jaringan virtual yang sama. Penyeimbang muatan Azure hanya mendukung instans back-end di jaringan virtual mereka sendiri.

Dependensi keluar

Komponen back-end aplikasi tidak perlu dijangkau, atau menerima koneksi masuk, dari jaringan perusahaan, tetapi sering memiliki dependensi keluar. Komponen back-end mungkin perlu terhubung ke titik akhir yang berada di luar zona pendaratan mereka dalam instans seperti resolusi DNS, Pengendali Domain Active Directory Domain Services, mengakses titik akhir aplikasi yang diekspos oleh zona pendaratan lainnya, atau mengakses fasilitas pengelogan atau pencadangan.

Ketika layanan memulai koneksi di jaringan virtual spoke yang tidak dapat dirutekan, Anda harus menerapkan NAT sumber (SNAT) untuk koneksi di belakang alamat IP yang dapat dirutekan. Untuk menerapkan SNAT, sebarkan perangkat berkemampuan NAT di jaringan virtual spoke yang dapat dirutekan. Setiap zona pendaratan menjalankan NAT NVA khususnya sendiri. Ada dua opsi untuk menerapkan SNAT di zona pendaratan: Azure Firewall atau NVA pihak ketiga. Dalam kedua kasus, semua subnet dalam spoke yang tidak dapat dialihkan harus dikaitkan dengan tabel rute kustom. Seperti yang ditunjukkan dalam diagram berikut, tabel rute meneruskan lalu lintas ke tujuan di luar zona pendaratan ke perangkat SNAT. Azure NAT Gateway tidak mendukung SNAT untuk lalu lintas yang ditujukan untuk ruang alamat IP privat, seperti ruang RFC 1918.

Unduh file PowerPoint arsitektur ini.

Menerapkan SNAT melalui Azure Firewall

Azure Firewall:

• Menyediakan ketersediaan tinggi.
• Menyediakan skalabilitas asli dan tiga SKU yang berbeda. SNAT bukan tugas intensif sumber daya, jadi pertimbangkan SKU dasar terlebih dahulu. Untuk zona pendaratan yang memerlukan volume besar lalu lintas keluar dari ruang alamat yang tidak dapat dialihkan, gunakan SKU standar.
• Melakukan SNAT untuk lalu lintas di belakang alamat IP privat dari salah satu instansnya. Setiap instans dapat menggunakan semua port yang tidak memiliki hak istimewa.

Diagram berikut menunjukkan tata letak zona pendaratan untuk menerapkan SNAT dalam topologi jaringan hub-and-spoke dengan menggunakan Azure Firewall.

Unduh file PowerPoint arsitektur ini.

Anda harus mengaitkan semua subnet di spoke yang tidak dapat dialihkan dengan tabel rute kustom untuk mengirim lalu lintas ke tujuan di luar zona pendaratan ke Azure Firewall.

Diagram berikut menunjukkan tata letak zona pendaratan untuk menerapkan SNAT di jaringan hub-and-spoke berbasis Virtual WAN dengan menggunakan Azure Firewall.

Unduh file PowerPoint arsitektur ini.

Anda harus mengaitkan semua subnet di spoke yang tidak dapat dialihkan, atau spoke yang tidak tersambung ke Virtual WAN, dengan tabel rute kustom untuk mengirim lalu lintas ke tujuan di luar zona pendaratan ke Azure Firewall.

Untuk kedua tata letak, untuk menyediakan sumber daya dalam akses spoke yang tidak dapat dirutekan ke alamat IP yang dapat dirutekan di luar zona pendaratannya, Anda harus menyebarkan Azure Firewall dengan opsi Lakukan SNAT yang diatur ke Always di setiap spoke yang dapat dirutekan di setiap zona pendaratan. Anda dapat menemukan instruksi tentang cara mengonfigurasi Azure Firewall untuk menerapkan SNAT pada semua koneksi yang diterima dalam dokumentasi publik. Cuplikan layar berikut menunjukkan konfigurasi yang diperlukan untuk menggunakan Azure Firewall sebagai perangkat NAT untuk koneksi yang dimulai oleh sumber daya di jaringan virtual spoke yang tidak dapat dialihkan.

Menerapkan SNAT melalui NVA pihak ketiga

NVA pihak ketiga dengan kemampuan NAT tersedia dalam Marketplace Azure. Mereka menyediakan:

• Kontrol terperinci atas penyempurnaan skala dan peluasan skala.
• Kontrol terperinci dari kumpulan NAT.
• Kebijakan NAT kustom, seperti menggunakan alamat NAT yang berbeda tergantung pada properti koneksi masuk, seperti alamat IP sumber atau tujuan.

Pertimbangkan rekomendasi berikut:

• Untuk ketersediaan tinggi, sebarkan kluster dengan setidaknya dua NVA. Gunakan load balancer Azure untuk mendistribusikan koneksi masuk dari jaringan virtual spoke yang tidak dapat dialihkan ke NVA. Aturan penyeimbangan beban port ketersediaan tinggi diperlukan karena kluster mengimplementasikan SNAT pada semua koneksi yang meninggalkan zona pendaratan. Azure Standard Load Balancer mendukung aturan penyeimbangan beban port dengan ketersediaan tinggi.
• Tumpukan Azure SDN mendukung NVA lengan tunggal dan dual-arm. NVA lengan tunggal lebih disukai karena mengurangi konsumsi ruang alamat di jaringan virtual spoke yang dapat dirutekan.

Diagram berikut menunjukkan tata letak zona pendaratan untuk menerapkan SNAT dalam topologi jaringan hub-and-spoke dengan menggunakan NVA pihak ketiga.

Unduh file PowerPoint arsitektur ini.

Diagram berikut menunjukkan tata letak zona pendaratan untuk mengimplementasikan SNAT dalam topologi jaringan hub-and-spoke berbasis Virtual WAN dengan menggunakan NVA pihak ketiga.

Unduh file PowerPoint arsitektur ini.

Untuk kedua tata letak NVA pihak ketiga, Anda harus menyebarkan beberapa instans di belakang penyeimbang muatan Azure untuk memberikan ketersediaan tinggi. SKU Standar Azure Load Balancer diperlukan.

Metode 2: Layanan Azure Private Link

Private Link menyediakan akses ke aplikasi yang disebarkan di jaringan virtual yang tidak terhubung ke jaringan virtual Anda. Di sisi server, atau aplikasi, jaringan virtual, layanan Private Link disebarkan dan dikaitkan dengan titik akhir aplikasi yang diekspos pada alamat IP front-end dari load balancer SKU standar Azure internal. Di jaringan virtual sisi klien, sumber daya titik akhir privat disebarkan dan dikaitkan dengan layanan Private Link. Titik akhir privat mengekspos titik akhir aplikasi di jaringan virtual Anda. Private Link menyediakan penerowongan dan logika NAT untuk merutekan lalu lintas antara sisi klien dan sisi server. Untuk informasi selengkapnya, lihat Apa itu Azure Private Link?

Private Link tidak memerlukan koneksi lapisan-3 antara jaringan virtual sisi klien dan jaringan virtual sisi server. Dua jaringan virtual dapat memiliki ruang alamat IP yang tumpang tindih. Private Link memungkinkan penyebaran aplikasi dalam jaringan virtual khusus yang terisolasi, semuanya menggunakan ruang alamat yang tidak dapat dialihkan yang sama. Aplikasi diekspos sebagai layanan Private Link di jaringan perusahaan, yang menggunakan ruang alamat yang dapat dirutekan. Dalam konteks arsitektur zona pendaratan Azure, topologi zona pendaratan yang dihasilkan memiliki:

• Jaringan virtual terisolasi yang menghosting seluruh aplikasi dan layanan Private Link yang terkait dengan titik akhir aplikasi. Tim aplikasi mendefinisikan ruang alamat jaringan virtual.
• Jaringan virtual spoke dengan ruang alamat yang dapat dirutekan yang menghosting titik akhir privat yang terkait dengan layanan Private Link. Jaringan virtual spoke langsung di-peering dengan hub regional.

Diagram berikut menunjukkan topologi zona pendaratan yang diaktifkan Private Link.

Unduh file PowerPoint arsitektur ini.

Menggunakan layanan Private Link untuk dependensi keluar

Saat Anda menyebarkan aplikasi di jaringan virtual spoke terisolasi, gunakan layanan Private Link untuk dependensi keluar. Tentukan titik akhir privat di jaringan virtual spoke yang terisolasi dan kaitkan dengan layanan Private Link di jaringan virtual yang dapat dirutekan. Diagram berikut menunjukkan pendekatan konseptual.

Unduh file PowerPoint arsitektur ini.

Di dunia nyata, implementasi skala besar, metode Private Link mungkin tidak berlaku:

• Jika aplikasi yang disebarkan di jaringan virtual terisolasi memiliki beberapa dependensi keluar. Saat Anda menyebarkan layanan Private Link dan titik akhir privat untuk setiap dependensi keluar, layanan tersebut meningkatkan kompleksitas dan kebutuhan manajemen.
• Jika dependensi keluar menyertakan titik akhir di jaringan yang dapat dirutekan yang tidak dapat menjadi bagian dari kumpulan backend Azure Load Balancer, Private Link tidak berlaku.

Untuk mengatasi kedua batasan ini, sebarkan solusi proksi/NAT dalam spoke yang dapat dirutekan dan membuatnya dapat diakses dari jaringan virtual yang terisolasi dengan menggunakan Private Link.

Unduh file PowerPoint arsitektur ini.

Gunakan satu titik akhir privat atau layanan Private Link untuk mengekspos solusi proksi/NAT yang disebarkan di jaringan yang dapat dirutekan. Aturan terjemahan port dan terjemahan alamat ditentukan pada NVA. Aturan ini memungkinkan penggunaan satu titik akhir privat di jaringan virtual terisolasi untuk mengakses beberapa dependensi dalam jaringan yang dapat dirutekan.

Kontributor

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

Penulis utama:

• Federico Guerrini | Prospek Teknis EMEA
• Khush Kaviraj | Arsitek Solusi Cloud
• Jack Tracey | Arsitek Solusi Cloud Senior

Kontributor lain:

• Jodi Martis | Penulis Teknis

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

• Menyebarkan Azure Firewall di jaringan virtual
• Mengonfigurasi SNAT di Azure Firewall
• Alamat IP yang didukung di Azure Virtual Network
• Tautan Privat Azure
• Penyeimbang Beban Azure
• Rekanan jaringan virtual

Sumber daya terkait

• Desain arsitektur jaringan
• Pendekatan arsitektural untuk jaringan dalam solusi multipenyewa
• Topologi jaringan hub-and-spoke