Artikel ini memberikan praktik terbaik untuk gateway Azure NAT. Panduan ini didasarkan pada lima pilar keunggulan arsitektur: Optimalisasi Biaya, Keunggulan Operasional, Efisiensi Performa, Keandalan, dan Keamanan.
Kami berasumsi bahwa Anda memiliki pengetahuan yang berfungsi tentang Azure NAT Gateway dan bahwa Anda berpengalaman dengan fitur masing-masing. Sebagai penyegaran, tinjau kumpulan lengkap dokumentasi Azure NAT Gateway.
NAT adalah singkatan dari NAT. Lihat Pengantar NAT.
Pengoptimalan biaya
Akses ke layanan PaaS harus melalui Azure Private Link atau titik akhir layanan (termasuk penyimpanan), untuk menghindari penggunaan gateway NAT. Private Link dan titik akhir layanan tidak memerlukan traversal gateway NAT untuk mengakses layanan PaaS. Pendekatan ini akan mengurangi biaya per GB data yang diproses, saat membandingkan biaya gateway NAT ke Private Link atau ke titik akhir layanan. Ada manfaat keamanan tambahan untuk menggunakan Private Link atau titik akhir layanan.
Efisiensi kinerja
Setiap sumber daya gateway NAT menyediakan throughput hingga 50 Gbps. Anda dapat membagi penyebaran menjadi beberapa subnet, lalu menetapkan setiap subnet atau grup subnet gateway NAT untuk meluaskan skala.
Setiap alamat IP publik gateway NAT menyediakan 64.512 port SNAT. Hingga 16 alamat IP dapat ditetapkan ke gateway NAT. Alamat IP dapat menjadi alamat IP Publik Standar individual, awalan IP Publik, atau keduanya. Untuk koneksi yang masuk ke titik akhir tujuan yang sama, gateway NAT dapat mendukung hingga 50.000 alur bersamaan untuk TCP dan UDP masing-masing, per alamat IP keluar yang ditetapkan. Tinjau bagian berikut tentang Source Network Address Translation (SNAT) untuk detailnya. TCP adalah singkatan dari Protokol Kendali Transmisi, dan UDP adalah singkatan dari Protokol Datagram Pengguna.
Kelelahan SNAT
- Sumber daya gateway NAT memiliki batas waktu diam TCP default selama 4 menit yang dapat dikonfigurasi hingga 120 menit. Jika pengaturan ini diubah ke nilai yang lebih tinggi dari default, gateway NAT akan menahan alur lebih lama dan dapat menyebabkan tekanan yang tidak perlu pada inventaris port SNAT.
- Permintaan atomik (satu permintaan per koneksi) adalah pilihan desain yang buruk, karena membatasi skala, mengurangi performa, dan mengurangi keandalan. Sebagai gantinya, gunakan kembali koneksi HTTP/S untuk mengurangi jumlah koneksi dan port SNAT terkait. Penggunaan kembali koneksi akan lebih memungkinkan aplikasi untuk menskalakan. Performa aplikasi akan meningkat, karena berkurangnya jabat tangan, overhead, dan biaya operasi kriptografi saat menggunakan TLS.
- Pencarian Sistem Nama Domain (DNS) dapat memperkenalkan banyak alur individual dalam volume, ketika klien tidak menyimpan cache hasil pemecah masalah DNS. Gunakan penembolokan DNS untuk mengurangi volume aliran dan mengurangi jumlah port SNAT. DNS adalah sistem penamaan yang memetakan nama domain ke alamat IP untuk sumber daya yang terhubung ke Internet atau ke jaringan privat.
- Alur UDP, seperti pencarian DNS, menggunakan port SNAT selama batas waktu saat nonaktif. Timer batas waktu diam UDP diperbaiki pada 4 menit dan tidak dapat diubah.
- Gunakan kumpulan koneksi untuk membentuk volume koneksi Anda.
- Jangan pernah diam-diam meninggalkan alur TCP dan mengandalkan timer TCP untuk membersihkan alur. Jika Anda tidak membiarkan TCP secara eksplisit menutup koneksi, koneksi TCP tetap terbuka. Sistem perantara dan titik akhir akan menjaga koneksi ini tetap digunakan, yang pada gilirannya membuat port SNAT tidak tersedia untuk koneksi lain. Anti-pola ini dapat memicu kegagalan aplikasi dan kehabisan SNAT.
- Jangan mengubah nilai timer yang sangat terkait dengan TCP tingkat OS, tanpa pengetahuan ahli tentang implikasinya. Meskipun tumpukan TCP akan pulih, performa aplikasi Anda dapat terdampak negatif jika titik akhir koneksi tidak sesuai dengan harapan. Mengubah nilai timer biasanya merupakan tanda masalah desain yang mendasarinya. Jika aplikasi yang mendasarinya memiliki anti-pola lain, kelelahan SNAT juga dapat diperkuat jika nilai timer diubah.
Tinjau panduan berikut untuk meningkatkan skala dan keandalan layanan Anda:
- Jelajahi efek mengurangi batas waktu nonaktif TCP ke nilai yang lebih rendah. Batas waktu nonaktif default 4 menit dapat membebaskan inventaris port SNAT sebelumnya.
- Pertimbangkan pola polling asinkron untuk operasi yang telah berjalan lama, untuk membebaskan sumber daya koneksi Anda untuk operasi lain.
- Alur berumur panjang, seperti koneksi TCP yang digunakan kembali, harus menggunakan keepalives TCP atau keepalive lapisan aplikasi untuk menghindari waktu sistem menengah habis. Anda hanya boleh meningkatkan batas waktu diam sebagai upaya terakhir, dan mungkin tidak menyelesaikan akar penyebabnya. Waktu habis yang lama dapat menyebabkan kegagalan laju rendah jika kadaluarsa dan menyebabkan penundaan dan kegagalan yang tidak perlu. Keepalives TCP dapat diaktifkan dari satu sisi koneksi untuk menjaga koneksi tetap hidup dari kedua sisi.
- Untuk arus berumur panjang dengan lalu lintas UDP, Anda dapat mengaktifkan keepalives UDP untuk menjaga koneksi tetap hidup. Perlu diingat bahwa keepalives UDP diaktifkan di satu sisi koneksi hanya menjaga koneksi tetap aktif dari satu sisi. Keepalives UDP harus diaktifkan di kedua sisi koneksi agar koneksi tetap hidup.
- Pola percobaan kembali yang mulus harus digunakan untuk menghindari percobaan kembali/ledakan yang agresif selama kegagalan sementara atau pemulihan kegagalan. Antipattern, yang disebut koneksi atomik, adalah ketika Anda membuat koneksi TCP baru untuk setiap operasi HTTP. Koneksi atomik akan mencegah aplikasi Anda menskalakan dengan baik dan akan membuang sumber daya. Selalu buat alur beberapa operasi ke koneksi yang sama. Aplikasi Anda akan mendapat keuntungan dalam kecepatan transaksi dan biaya sumber daya. Jika aplikasi Anda menggunakan enkripsi lapisan transportasi (misalnya TLS), ada biaya signifikan yang terkait dengan pemrosesan koneksi baru. Lihat Pola Desain Azure Cloud untuk pola praktik terbaik lainnya.
Keunggulan operasional
Meskipun gateway NAT dapat digunakan dengan Azure Kubernetes Service (AKS), gateway ini tidak dikelola sebagai bagian dari AKS. Jika Anda menetapkan gateway NAT ke subnet Antarmuka Jaringan Kontainer (CNI), Anda akan mengaktifkan pod AKS untuk keluar melalui gateway NAT.
Saat menggunakan beberapa gateway NAT di seluruh zona atau di seluruh wilayah, jaga agar real IP keluar dapat dikelola dengan menggunakan awalan IP Publik Azure atau awalan BYOIP. Ukuran awalan IP yang lebih besar dari 16 alamat IP (ukuran awalan/28) tidak dapat ditetapkan ke gateway NAT.
Gunakan pemberitahuan Azure Monitor untuk memantau dan memperingatkan penggunaan port SNAT, paket yang diproses atau dihilangkan, dan jumlah data yang dikirimkan. Gunakan log alur NSG untuk memantau arus lalu lintas keluar dari instans komputer virtual di subnet yang dikonfigurasi gateway NAT.
Ketika subnet dikonfigurasi dengan gateway NAT, gateway NAT akan menggantikan semua konektivitas keluar lainnya ke Internet publik untuk semua VM pada subnet tersebut. Gateway NAT akan lebih diutamakan daripada load balancer dengan atau tanpa aturan keluar, dan melalui alamat IP publik yang ditugaskan langsung ke VM. Azure melacak arah aliran, dan perutean asimetris tidak akan terjadi. Lalu lintas asal masuk akan diterjemahkan dengan benar, seperti IP frontend load balancer, dan akan diterjemahkan secara terpisah dari lalu lintas keluar melalui gateway NAT. Pemisahan ini memungkinkan layanan masuk dan keluar untuk hidup berdampingan dengan lancar.
Nat gateway direkomendasikan sebagai default untuk mengaktifkan konektivitas keluar untuk jaringan virtual. Gateway NAT lebih efisien dan kurang kompleks secara operasional daripada teknik konektivitas keluar lainnya di Azure. Gateway NAT mengalokasikan port SNAT sesuai permintaan dan menggunakan algoritma yang lebih efisien untuk mencegah konflik penggunaan kembali port SNAT. Jangan mengandalkan konektivitas keluar default (anti-pola) untuk properti Anda. Sebaliknya, secara eksplisit mendefinisikannya dengan sumber daya gateway NAT.
Keandalan
Sumber daya gateway NAT sangat tersedia di satu zona ketersediaan dan mencakup beberapa domain kesalahan. Gateway NAT dapat disebarkan ke "tanpa zona" di mana Azure secara otomatis memilih zona untuk menempatkan gateway NAT. Gateway NAT juga dapat diisolasi ke zona tertentu oleh pengguna.
Isolasi zona ketersediaan tidak dapat disediakan, kecuali setiap subnet hanya memiliki sumber daya dalam zona tertentu. Sebagai gantinya, sebarkan subnet untuk masing-masing zona ketersediaan tempat VM digunakan, sejajarkan VM zonal dengan gateway NAT zona yang cocok, dan buat tumpukan zona terpisah. Misalnya, mesin virtual di zona ketersediaan 1 berada di subnet dengan sumber daya lain yang juga hanya ada di zona ketersediaan 1. Gateway NAT dikonfigurasi di zona ketersediaan 1 untuk melayani subnet tersebut. Lihat diagram berikut.
Jaringan virtual dan subnet mencakup semua zona ketersediaan di suatu wilayah. Anda tidak perlu membaginya berdasarkan zona ketersediaan untuk mengakomodasi sumber daya zona.
Keamanan
Dengan gateway NAT, komputer virtual individual (atau sumber daya komputasi lainnya) tidak memerlukan alamat IP publik dan dapat tetap sepenuhnya privat. Sumber daya tanpa alamat IP publik masih dapat menjangkau sumber eksternal di luar jaringan virtual. Anda dapat mengaitkan awalan IP publik untuk memastikan bahwa sekumpulan IP yang berdampingan akan digunakan untuk konektivitas keluar. Aturan firewall tujuan dapat dikonfigurasi berdasarkan daftar IP yang dapat diprediksi ini.
Pendekatan umum adalah merancang skenario alat virtual jaringan keluar saja (NVA) dengan firewall pihak ketiga atau dengan server proksi. Ketika gateway NAT digunakan ke subnet dengan satu set skala mesin virtual NVA, NVA tersebut akan menggunakan alamat gateway NAT untuk konektivitas keluar, yang bertentangan dengan IP load balancer atau IP individual. Untuk menggunakan skenario ini dengan Azure Firewall, lihat Mengintegrasikan Azure Firewall dengan Azure Standard Load Balancer.
Microsoft Defender untuk Cloud dapat memantau konektivitas keluar yang mencurigakan melalui gateway NAT. Ini adalah fitur peringatan di Microsoft Defender untuk Cloud.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Ethan Haslett | Arsitek Solusi Cloud Senior
Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.