Tanya jawab umum tentang Application Gateway

Azure Application Gateway menyediakan pengontrol pengiriman aplikasi sebagai layanan. Ini menawarkan berbagai kemampuan penyeimbang beban lapisan 7 untuk aplikasi Anda. Ketersediaan layanan ini tinggi, dapat diskalakan, dan sepenuhnya dikelola oleh Azure.

Application Gateway mendukung penskalaan otomatis, pemindahan TLS, dan TLS end-to-end, firewall aplikasi web (WAF), afinitas sesi berbasis cookie, perutean berbasis jalur URL, hosting multisitus, dan fitur lainnya. Untuk daftar lengkap fitur yang didukung, lihat Pengantar Application Gateway.

Application Gateway adalah load balancer lapisan 7, yang artinya hanya berfungsi dengan lalu lintas web (HTTP, HTTPS, WebSocket, dan HTTP/2). Ini mendukung kemampuan seperti penghentian TLS, afinitas sesi berbasis cookie, dan round robin untuk lalu lintas penyeimbang beban. Load Balancer menyeimbangkan beban lalu lintas pada lapisan 4 (TCP atau UDP).

Application Gateway mendukung HTTP, HTTPS, HTTP/2, dan WebSocket.

Lihat dukungan HTTP/2.

Lihat Sumber daya backend yang didukung.

Application Gateway v1 (Standard dan WAF) tersedia di seluruh wilayah Azure global. Ini juga tersedia di Microsoft Azure yang dioperasikan oleh 21Vianet dan Azure Government.

Untuk ketersediaan Application Gateway v2 (Standard_v2 dan WAF_v2), lihat Wilayah yang didukung untuk Application Gateway v2.

Application Gateway adalah penyebaran khusus di jaringan virtual Anda.

Pengalihan didukung. LihatGambaran umum pengalihan Application Gateway.

Lihat urutan pemrosesan pendengar.

Jika Anda menggunakan alamat IP publik sebagai titik akhir, Anda menemukan informasi IP dan DNS pada sumber daya alamat IP publik. Atau Anda dapat menemukannya di portal Azure, pada halaman gambaran umum untuk gateway aplikasi. Jika Anda menggunakan alamat IP internal, cari informasi di halaman gambaran umum. Untuk SKU v1, gateway yang dibuat setelah 1 Mei 2023, tidak akan memiliki nama DNS default yang secara otomatis terkait dengan sumber daya IP publik. Untuk SKU v2, buka sumber daya IP publik dan pilih Konfigurasi. Bidang Label nama DNS (opsional) disediakan untuk mengonfigurasi nama DNS.

Keep-Alive batas waktu mengatur berapa lama gateway aplikasi menunggu klien mengirim permintaan HTTP lain pada koneksi persisten sebelum menggunakannya kembali atau menutupnya. Batas waktu diam TCP mengatur berapa lama koneksi TCP tetap terbuka jika tidak ada aktivitas.

Untuk koneksi HTTP/1.1, Keep-Alive batas waktu di Application Gateway v1 dan v2 SKU adalah 120 detik. Untuk alamat IP privat, nilai tidak dapat dikonfigurasi dengan batas waktu diam TCP 5 menit. Batas waktu TCP default adalah 4 menit pada IP virtual frontend (VIP) SKU v1 dan v2 Application Gateway. Anda dapat mengonfigurasi nilai batas waktu diam TCP pada instans Application Gateway v1 dan v2 agar berada di mana saja antara 4 menit dan 30 menit. Untuk instans Application Gateway v1 dan v2, Anda perlu membuka IP publik gateway aplikasi dan mengubah batas waktu diam TCP di bawah panel Konfigurasi IP publik di portal. Anda bisa mengatur nilai batas waktu TCP diam dari IP publik melalui PowerShell dengan menjalankan perintah berikut:

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

Untuk koneksi HTTP/2 ke alamat IP frontend pada Application Gateway v2 SKU, batas waktu diam diatur ke 180 detik dan tidak dapat dikonfigurasi.

Untuk mencegah konflik dan perilaku tak terduga, pastikan bahwa batas waktu diam TCP diatur agar sama dengan atau lebih lama dari batas waktu tetap aktif.

Ya. Application Gateway menggunakan kembali koneksi TCP yang ada dengan server backend.

Tidak. Tidak ada cara untuk mengganti nama sumber daya Application Gateway. Anda harus membuat sumber daya baru dengan nama yang berbeda.

Tidak. Tidak ada cara untuk memulihkan sumber daya Application Gateway atau IP publiknya setelah penghapusan. Anda harus membuat sumber daya baru.

Di Application Gateway v1 SKU, VIP dapat berubah jika Anda menghentikan dan memulai gateway aplikasi. Namun, nama DNS yang terkait dengan gateway aplikasi tidak berubah sama masa pakai gateway. Karena nama DNS tidak berubah, Anda sebaiknya menggunakan CNAME alias mengarahkannya ke alamat DNS gateway aplikasi. Di Application Gateway v2 SKU, alamat IP statis, sehingga alamat IP dan nama DNS tidak akan berubah selama masa pakai gateway aplikasi.

Ya. Application Gateway v2 SKU mendukung alamat IP publik statis dan IP internal statis. SKU v1 mendukung IP internal statis.

Gateway aplikasi hanya mendukung satu alamat IP publik per protokol IP. Jika gateway aplikasi dikonfigurasi sebagai DualStack, gateway aplikasi dapat mendukung dua IP Publik, satu untuk IPv4 dan satu untuk IPv6.

Lihat Pertimbangan ukuran subnet Application Gateway.

Ya. Selain beberapa contoh penyebaran Application Gateway yang diberikan, Anda dapat memprovisikan sumber daya Application Gateway unik lainnya ke subnet yang sudah ada yang berisi sumber daya Application Gateway yang berbeda.

Satu subnet tidak dapat mendukung SKU App Application Gateway v2 dan v1.

Ya, tetapi hanya skenario tertentu. Untuk info selengkapnya, lihat Konfigurasi infrastruktur Application Gateway.

Ya. Lihat Modifikasi pada permintaan.

Penyebaran Application Gateway SKU v1 bisa memakan waktu hingga 20 menit untuk diprovisikan. Perubahan ukuran atau jumlah instans tidak mengganggu, dan gateway tetap aktif selama waktu ini.

Sebagian besar penyebaran yang menggunakan SKU v2 membutuhkan waktu sekitar 6 menit untuk diprovisikan. Namun, prosesnya dapat memakan waktu lebih lama tergantung pada jenis penyebaran. Misalnya, penyebaran di beberapa zona ketersediaan dengan banyak instans dapat memakan waktu lebih dari 6 menit.

Pembaruan yang dimulai ke Application Gateway diterapkan satu domain pembaruan sekaligus. Saat setiap instans domain pembaruan sedang diperbarui, instans yang tersisa di domain pembaruan lainnya terus melayani lalu lintas¹. Koneksi aktif dikosongkan dengan anggun dari instans yang diperbarui hingga 5 menit untuk membantu membangun konektivitas ke instans di domain pembaruan yang berbeda sebelum pembaruan dimulai. Selama pembaruan, Application Gateway untuk sementara berjalan pada kapasitas maksimum yang dikurangi, yang ditentukan oleh jumlah instans yang dikonfigurasi. Proses pembaruan berlanjut ke set instans berikutnya hanya jika kumpulan instans saat ini berhasil ditingkatkan.

¹ Kami merekomendasikan jumlah instans minimum 2 yang akan dikonfigurasi untuk penyebaran SKU Application Gateway v1 untuk memastikan setidaknya satu instans dapat melayani lalu lintas saat pembaruan diterapkan.

Application Gateway mendukung proksi protokol TLS/TCP melalui proksi Lapisan 4-nya dalam Pratinjau.

Proksi Lapisan 7 gateway aplikasi dengan protokol HTTP tidak akan mendukung protokol email seperti SMTP, IMAP, dan POP3. Namun, untuk beberapa layanan email pendukung, seperti lalu lintas Outlook Web Access (OWA), ActiveSync, dan AutoDiscovery yang menggunakan protokol HTTP(S), Anda dapat menggunakan proksi Layer 7, dan lalu lintasnya harus mengalir. (Catatan: Pengecualian dalam aturan WAF mungkin diperlukan saat menggunakan SKU WAF).

Ya. Untuk informasi selengkapnya, lihat Memigrasikan Azure Application Gateway dan Web Application Firewall dari v1 ke v2.

Ya. SKU Application Gateway v1 terus didukung. Kami sangat menyarankan pindah ke v2 untuk memanfaatkan pembaruan fitur dalam SKU tersebut. Untuk informasi selengkapnya tentang perbedaan antara fitur v1 dan v2, lihat Penskalaan otomatis dan Application Gateway v2 zona-redundan. Anda dapat memigrasikan penyebaran SKU Application Gateway v1 secara manual ke v2 dengan mengikuti dokumen migrasi v1-v2 kami.

Tidak. Application Gateway v2 tidak mendukung permintaan proksi dengan autentikasi NTLM atau Kerberos.

Nama header permintaan dapat berisi karakter alfanumerik dan tanda hubung. Nama header permintaan yang berisi karakter lain dibuang saat permintaan dikirim ke target backend. Nama header respons dapat berisi karakter alfanumerik dan simbol tertentu seperti yang didefinisikan dalam RFC 7230.

Ya. Pembaruan browser Chromium v80 memperkenalkan mandat pada cookie HTTP tanpa atribut SameSite untuk diperlakukan sebagai SameSite=Lax. Artinya, cookie afinitas Application Gateway tidak akan dikirim oleh browser dalam konteks pihak ketiga.

Untuk mendukung skenario ini, Application Gateway menyuntikkan cookie lain yang disebut ApplicationGatewayAffinityCORS selain cookie yang ada ApplicationGatewayAffinity . Cookie ini serupa, tetapi ApplicationGatewayAffinityCORS cookie memiliki dua atribut lagi yang ditambahkan ke dalamnya: SameSite=None dan Secure. Atribut ini mempertahankan sesi lekat bahkan untuk permintaan lintas asal. Untuk informasi selengkapnya, lihat bagian Afinitas berbasis cookie.

Pendengar aktif adalah pendengar yang terkait dengan aturan dan mengirim lalu lintas ke kumpulan backend. Pendengar apa pun yang hanya mengalihkan lalu lintas bukan pendengar aktif. Pendengar yang terkait dengan aturan pengalihan tidak dianggap aktif. Jika aturan pengalihan adalah aturan berbasis jalur, semua jalur dalam aturan pengalihan tersebut harus mengalihkan lalu lintas atau pendengar dianggap aktif. Untuk detail batas komponen individual, lihat Batas, kuota, dan batasan langganan dan layanan Azure.

Application Gateway v1 mendukung skenario ketersediaan tinggi ketika Anda menyebarkan dua instans atau lebih. Azure mendistribusikan instans ini ke seluruh domain pembaruan dan kesalahan untuk memastikan bahwa semua instans tidak gagal pada saat yang bersamaan. SKU v1 mendukung skalabilitas dengan menambahkan beberapa instans gateway yang sama untuk berbagi beban.

SKU v2 secara otomatis memastikan bahwa instans baru tersebar di seluruh domain kesalahan dan memperbarui domain. Jika Anda memilih redundansi zona, instans terbaru juga akan tersebar di seluruh zona ketersediaan untuk menawarkan resiliensi kegagalan zona.

Gunakan Azure Traffic Manager untuk mendistribusikan lalu lintas di beberapa gateway aplikasi di pusat data yang berbeda.

Ya. Anda bisa mengatur pengurasan koneksi untuk mengubah anggota dalam kumpulan backend tanpa gangguan. Untuk informasi selengkapnya, lihat bagian Pengurasan koneksi Application Gateway.

Ya, SKU v2 Application Gateway mendukung penskalaan otomatis. Untuk informasi selengkapnya, lihat Penskalaan otomatis dan Application Gateway zona-redundan.

Tidak. Instans didistribusikan di seluruh domain peningkatan dan domain kesalahan.

Ya.

Ya.

Ya. Application Gateway selalu disebarkan di subnet jaringan virtual. Subnet ini hanya bisa berisi gateway aplikasi. Untuk informasi selengkapnya, lihat Persyaratan jaringan virtual dan subnet.

Jika Anda memiliki konektivitas IP, Application Gateway dapat berkomunikasi dengan instans di luar jaringan virtual tempatnya berada. Application Gateway juga dapat berkomunikasi dengan instans di luar langganan tempatnya berada. Jika Anda menggunakan IP internal sebagai anggota kumpulan backend, gunakan serekan jaringan virtual atau Azure VPN Gateway.

Seperti pemecah masalah DNS apa pun, sumber daya Application Gateway menghormati nilai Time to Live (TTL) dari catatan DNS server backend. Setelah TTL kedaluwarsa, gateway melakukan pencarian untuk memperbarui informasi DNS tersebut. Selama pencarian ini, jika gateway aplikasi Anda mengalami masalah saat mendapatkan respons (atau tidak ada catatan DNS yang ditemukan), gateway terus menggunakan nilai DNS terakhir yang diketahui baik untuk melayani lalu lintas. Untuk info selengkapnya, lihat Cara kerja gateway aplikasi.

Instans gateway aplikasi Anda menggunakan konfigurasi DNS jaringan virtual untuk resolusi nama. Setelah mengubah konfigurasi server DNS apa pun, Anda perlu memulai ulang (Hentikan dan Mulai) gateway aplikasi agar server DNS baru ditetapkan. Hingga saat itu, resolusi nama berbasis FQDN untuk konektivitas keluar dapat gagal.

Tidak. Anda juga dapat menyebarkan gateway aplikasi lain di subnet.

Anda dapat memindahkan gateway aplikasi di seluruh subnet hanya dalam jaringan virtual yang sama. Ini didukung dengan v1 dengan frontend publik dan privat (alokasi dinamis) dan v2 hanya dengan frontend publik. Kami tidak dapat memindahkan gateway aplikasi ke subnet lain jika konfigurasi IP frontend privat dialokasikan secara statis. Gateway aplikasi harus dalam status Dihentikan untuk melakukan tindakan ini. Menghentikan atau memulai v1 mengubah IP publik. Operasi ini hanya dapat dilakukan dengan menggunakan Azure PowerShell dan Azure CLI dengan menjalankan perintah berikut:

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

Untuk informasi selengkapnya, lihat Set-AzApplicationGatewayIPConfiguration.

Azure CLI

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

Lihat kelompok keamanan jaringan di subnet Application Gateway.

Lihat Rute yang ditentukan pengguna yang didukung di subnet Application Gateway.

Tidak. Kebijakan titik akhir layanan untuk akun penyimpanan tidak didukung di subnet Application Gateway dan mengonfigurasinya memblokir lalu lintas infrastruktur Azure.

Lihat batasan Application Gateway.

Ya. Application Gateway mendukung satu IP internal dan satu IP eksternal pada setiap gateway aplikasi.

Ya. Serekan jaringan virtual membantu lalu lintas keseimbangan beban di jaringan virtual lainnya.

Ya, selama lalu lintas diizinkan.

Arsitektur layanan mikro didukung. Untuk melakukan pemeriksaan pada port yang berbeda, Anda perlu mengonfigurasi beberapa pengaturan backend.

Tidak.

Lihat Urutan aturan pemrosesan.

Bidang Host menentukan nama untuk mengirim pemeriksaan saat Anda telah mengonfigurasi multisitus di Application Gateway. Jika tidak, gunakan 127.0.0.1. Nilai ini berbeda dari nama host komputer virtual. Formatnya adalah <protokol>://<host>:<jalur> port><.

Ya. Lihat Membatasi akses ke IP sumber tertentu.

Ya, Anda dapat menggunakan listener yang menghadap publik dan menghadap privat dengan nomor port yang sama untuk secara bersamaan mendukung klien publik dan privat. Jika grup keamanan jaringan (NSG) dikaitkan dengan subnet gateway aplikasi Anda, aturan Masuk tertentu mungkin diperlukan tergantung pada konfigurasinya. Ketahui selengkapnya.

Application Gateway v2 mendukung frontend IPv4 dan IPv6. Saat ini, dukungan IPv6 hanya tersedia untuk gateway aplikasi baru. Untuk mendukung IPv6, jaringan virtual harus berupa tumpukan ganda. Application Gateway v1 tidak mendukung jaringan virtual tumpukan ganda.

SKU Application Gateway v1 dapat berjalan dalam mode operasi yang disetujui FIPS 140-2, yang biasanya disebut sebagai "mode FIPS." Mode FIPS memanggil modul kriptografi tervalidasi FIPS 140-2 yang memastikan algoritma yang mematuhi FIPS untuk enkripsi, hash, dan penandatanganan saat diaktifkan. Untuk memastikan mode FIPS diaktifkan, FIPSMode pengaturan harus dikonfigurasi melalui PowerShell, templat Azure Resource Manager, atau REST API setelah langganan terdaftar untuk mengaktifkan konfigurasi FIPSmode.

Catatan: Sebagai bagian dari kepatuhan FedRAMP, Pemerintah AS mengamanatkan bahwa sistem beroperasi dalam mode yang disetujui FIPS setelah Agustus 2024.

Langkah-langkah untuk mengaktifkan Mode FIPS di SKU V1:

Langkah 1: Daftarkan fitur 'AllowApplicationGatewayEnableFIPS' untuk mendaftarkan langganan untuk konfigurasi mode FIPS.

Untuk mendaftar menggunakan Azure PowerShell, buka perintah Cloud Shell dan masukkan yang berikut ini:

Register-AzProviderFeature -FeatureName AllowApplicationGatewayEnableFIPS -ProviderNamespace Microsoft.Network

Untuk mendaftar menggunakan portal Azure:

• Masuk ke portal Azure dan cari fitur Pratinjau.
• Masukkan AllowApplicationGatewayEnableFIPS ke dalam kotak filter. Pilih Application Gateway V1 Izinkan Mode FIPS, lalu pilih Daftar.

Langkah 2: Atur properti enableFips ke True menggunakan PowerShell, templat Azure Resource Manager, atau REST API.

# Get the application gateway
$appgw = Get-AzApplicationGateway -Name <ApplicationGatewayName> -ResourceGroupName <ResourceGroupName>
# Set the EnableFips property
$appgw.EnableFips = $true
# Update the application gateway
Set-AzApplicationGateway -ApplicationGateway $appgw

Mengubah mode FIPS tidak memengaruhi ketersediaan keseluruhan cipher suite di gateway V1. Namun, saat menggunakan kriptografi kurva elips untuk sandi, dengan mode FIPS dinonaktifkan, Anda dapat menggunakan kurva25519, NistP256, dan NistP384 sedangkan dengan mode FIPS yang diaktifkan hanya NistP256 dan NistP384 yang diizinkan dan kurva25519 dinonaktifkan. Karena kurva25519 menjadi tidak tersedia dalam mode FIPS, pastikan klien Anda mendukung NistP256 atau NistP384 untuk komunikasi yang aman sebelum mengaktifkan FIPS.

Application Gateway v2 saat ini hanya mendukung konfigurasi frontend IP privat (tanpa IP publik) melalui pratinjau publik. Untuk informasi selengkapnya, lihat Penyebaran Application Gateway Privat (pratinjau).

Untuk dukungan ketersediaan umum saat ini, Application Gateway v2 mendukung kombinasi berikut:

• IP privat dan IP publik
• Khusus IP publik

Untuk membatasi lalu lintas hanya ke alamat IP privat dengan fungsionalitas saat ini, ikuti proses ini:

1. Buat gateway aplikasi dengan alamat IP frontend publik dan privat.

2. Jangan membuat listener apa pun untuk alamat IP frontend publik. Application Gateway tidak akan mendengarkan lalu lintas apa pun di alamat IP publik jika tidak ada pendengar yang dibuat untuknya.

3. Buat dan lampirkan grup keamanan jaringan untuk subnet Application Gateway dengan konfigurasi berikut dalam urutan prioritas:

   1. Izinkan lalu lintas dari Sumber sebagai tag layanan GatewayManager, Tujuan sebagai Apa Pun, dan Port tujuan sebagai 65200-65535. Rentang port ini diperlukan untuk komunikasi infrastruktur Azure. Port ini dilindungi (dikunci) oleh autentikasi sertifikat. Entitas eksternal, termasuk administrator pengguna gateway, tidak dapat memulai perubahan pada titik akhir tersebut tanpa sertifikat yang sesuai.

   2. Izinkan lalu lintas dari Sumber sebagai tag layanan AzureLoadBalancer dan Port tujuan sebagai Apa pun.

   3. Tolak semua lalu lintas masuk dari Sumber sebagai tag layanan Internet dan Port tujuan sebagai Apa pun. Berikan aturan ini prioritas paling sedikit dalam aturan masuk.

   4. Pertahankan aturan default seperti AllowVNetInBound sehingga akses pada alamat IP privat tidak diblokir.

   5. Konektivitas Internet keluar tidak bisa diblokir. Jika tidak, Anda menghadapi masalah dengan pengelogan dan metrik.

Contoh konfigurasi NSG untuk akses khusus IP privat:

Anda dapat menggunakan Azure PowerShell atau Azure CLI untuk menghentikan dan memulai Application Gateway. Saat Anda menghentikan dan memulai Application Gateway, penagihan juga berhenti dan dimulai. Setiap operasi PUT yang dilakukan pada gateway aplikasi yang dihentikan (seperti menambahkan tag, pemeriksaan kesehatan, atau pendengar) memicu permulaan. Kami menyarankan agar Anda menghentikan gateway aplikasi setelah konfigurasi diperbarui.

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Application Gateway mendukung sertifikat yang ditandatangani sendiri, sertifikat dari otoritas sertifikat (CA), sertifikat Validasi Diperpanjang (EV), sertifikat multi-domain (SAN), dan sertifikat kartubebas.

Application Gateway mendukung cipher suite berikut:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Untuk informasi tentang cara kustomisasi opsi TLS, lihat Mengonfigurasi versi kebijakan TLS dan chiper suite di Application Gateway.

Ya. Application Gateway mendukung offload TLS dan TLS end-to-end, yang mendekripsi ulang lalu lintas ke backend.

Ya. Anda dapat mengonfigurasi App Gateway untuk menolak TLS1.0, TLS1.1, dan TLS1.2. Secara default, SSL 2.0 dan 3.0 sudah dinonaktifkan dan tidak dapat dikonfigurasi.

Ya. Di Application Gateway, Anda dapat mengonfigurasi cipher suites. Untuk menentukan kebijakan kustom, aktifkan setidaknya salah satu suite sandi berikut:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Application Gateway menggunakan SHA256 untuk manajemen backend.

Application Gateway mendukung hingga 100 sertifikat TLS/SSL.

Ya, Application Gateway mendukung sertifikat dengan ekstensi OCSP dan stapling OCSP untuk sertifikat server.

Application Gateway mendukung hingga 100 sertifikat autentikasi.

Ya, SKU v2 Application Gateway mendukung Key Vault. Untuk informasi selengkapnya, lihat penghentian TLS dengan sertifikat Key Vault.

Untuk beberapa perutean berbasis domain (berbasis host), Anda dapat membuat pendengar multisitus, menyiapkan pendengar yang menggunakan HTTPS sebagai protokol, dan mengaitkan pendengar dengan aturan perutean. Untuk informasi selengkapnya, lihat Hosting beberapa situs dengan menggunakan Application Gateway.

Tidak. Gunakan hanya karakter alfanumerik dalam kata sandi file .pfx Anda.

Anggota CA/Browser baru-baru ini menerbitkan laporan yang merinci beberapa sertifikat yang dikeluarkan oleh vendor CA yang digunakan oleh pelanggan kami, Microsoft, dan komunitas teknologi yang lebih besar yang tidak mematuhi standar industri untuk CA tepercaya publik. Laporan mengenai CA yang tidak patuh dapat ditemukan di sini:

• Bug 1649951
• Bug 1650910

Menurut persyaratan kepatuhan industri, vendor CA mulai mencabut CA yang tidak patuh dan mengeluarkan CA yang sesuai, yang mengharuskan pelanggan untuk menerbitkan kembali sertifikat mereka. Microsoft bermitra erat dengan vendor ini untuk meminimalkan dampak potensial terhadap layanan Azure. Namun, sertifikat atau sertifikat yang diterbitkan sendiri yang digunakan dalam skenario Bring Your Own Certificate (BYOC) masih berisiko dicabut secara tak terduga.

Untuk memeriksa apakah sertifikat yang digunakan oleh aplikasi Anda dicabut, lihat pengumuman DigiCert dan Pelacak Pencabutan Sertifikat. Jika sertifikat Anda dicabut, atau akan dicabut, Anda perlu meminta sertifikat baru dari vendor CA yang digunakan dalam aplikasi Anda. Untuk menghindari ketersediaan aplikasi Anda terganggu karena sertifikat dicabut secara tak terduga, atau untuk memperbarui sertifikat yang telah dicabut, lihat Pencabutan Otoritas Sertifikat yang tidak patuh berpotensi memengaruhi layanan Azure pelanggan.

Untuk informasi khusus untuk Application Gateway:

Jika Anda menggunakan sertifikat yang dikeluarkan oleh salah satu ICA yang dicabut, ketersediaan aplikasi Anda mungkin terganggu. Bergantung pada aplikasi Anda, Anda mungkin menerima berbagai pesan kesalahan termasuk tetapi tidak terbatas pada:

• Sertifikat tidak valid/sertifikat yang dicabut
• Waktu sambungan habis
• HTTP 502

Untuk menghindari gangguan pada aplikasi Anda karena masalah ini, atau untuk menerbitkan ulang CA yang telah dicabut, Anda perlu mengambil tindakan berikut:

1. Hubungi penyedia sertifikat Anda tentang cara membuat ulang sertifikat Anda.
2. Setelah diterbitkan kembali, perbarui sertifikat Anda di Application Gateway/WAF dengan rantai kepercayaan lengkap (daun, menengah, dan sertifikat akar). Berdasarkan tempat Anda menggunakan sertifikat, baik pada pendengar atau pengaturan HTTP gateway aplikasi, ikuti langkah-langkah di sini untuk memperbarui sertifikat. Untuk informasi selengkapnya, periksa tautan dokumentasi yang disebutkan.
3. Perbarui server aplikasi backend Anda untuk menggunakan sertifikat yang diterbitkan kembali. Bergantung pada server backend yang Anda gunakan, langkah-langkah pembaruan sertifikat Anda mungkin bervariasi. Periksa dokumentasi dari vendor Anda.

Untuk memperbarui sertifikat pada pendengar Anda:

1. Di portal Azure, buka sumber daya Application Gateway Anda.
2. Buka pengaturan pendengar yang terkait dengan sertifikat Anda.
3. Pilih Perbarui atau edit sertifikat yang dipilih.
4. Unggah sertifikat PFX baru Anda dengan kata sandi dan pilih Simpan.
5. Akses situs web dan verifikasi apakah situs berfungsi seperti yang diharapkan. Untuk informasi selengkapnya, lihat Memperbarui sertifikat Application Gateway.

Jika Anda mereferensikan sertifikat dari Key Vault di pendengar Application Gateway Anda, kami merekomendasikan langkah-langkah berikut untuk perubahan cepat:

1. Di portal Azure, buka pengaturan Key Vault Anda yang terkait dengan gateway aplikasi.
2. Tambahkan atau impor sertifikat yang diterbitkan kembali di penyimpanan Anda. Untuk informasi selengkapnya, lihat Mulai Cepat: Membuat brankas kunci menggunakan portal Azure.
3. Setelah sertifikat diimpor, buka pengaturan pendengar Application Gateway Anda dan di bawah Pilih sertifikat dari Key Vault, pilih menu dropdown Sertifikat dan pilih sertifikat yang baru ditambahkan.
4. Pilih Simpan. Untuk informasi selengkapnya tentang penghentian TLS di Application Gateway dengan sertifikat Key Vault, lihat Penghentian TLS dengan sertifikat Key Vault.

Untuk memperbarui sertifikat di pengaturan HTTP Anda:

Jika Anda menggunakan SKU v1 dari layanan Application Gateway/WAF, Anda harus mengunggah sertifikat baru sebagai sertifikat autentikasi backend Anda.

1. Di portal Azure, buka sumber daya Application Gateway Anda.
2. Buka pengaturan HTTP yang terkait dengan sertifikat Anda.
3. Pilih Tambahkan sertifikat, unggah sertifikat yang diterbitkan kembali, dan pilih Simpan.
4. Anda dapat menghapus sertifikat lama nanti dengan memilih tombol opsi ... di samping sertifikat lama. Pilih Hapus lalu pilih Simpan. Untuk informasi selengkapnya, lihat Mengonfigurasi TLS end-to-end dengan menggunakan Application Gateway dengan portal.

Jika Anda menggunakan SKU V2 dari layanan Application Gateway/WAF, Anda tidak perlu mengunggah sertifikat baru di pengaturan HTTP karena SKU V2 menggunakan "sertifikat akar tepercaya", dan tidak ada tindakan yang perlu diambil di sini.

Ya. Perutean Lapisan 7 dan Lapisan 4 melalui gateway aplikasi menggunakan konfigurasi IP frontend yang sama. Dengan cara ini, Anda dapat mengarahkan semua klien Anda ke satu alamat IP (publik atau privat) dan sumber daya gateway yang sama akan merutekannya berdasarkan protokol pendengar yang dikonfigurasi dan port.

Meskipun lalu lintas HTTP juga dapat dilayani melalui protokol proksi L4, kami tidak menyarankan untuk melakukannya. Solusi proksi L7 Application Gateway menawarkan kontrol dan keamanan yang lebih besar atas protokol HTTP melalui fitur lanjutan seperti Penulisan Ulang, Afinitas Sesi, Pengalihan, WebSocket, WAF, dan banyak lagi.

Properti sumber daya untuk fitur Lapisan 4 berbeda dari yang Lapisan 7. Oleh karena itu, saat menggunakan REST API atau CLI, Anda harus menggunakan properti berikut.

• REST API
• CLI

Tidak. Anda tidak dapat menautkan silang properti Layer 4 dan Layer 7. Oleh karena itu, aturan perutean hanya akan memungkinkan Anda untuk menautkan pendengar tipe Lapisan 4 ke pengaturan Backend Layer 4-type.

Anda tidak dapat menggunakan nama yang sama untuk L7 (httpListeners) dan L4 (listener). Ini berlaku untuk properti L4 lainnya seperti backendSettingsCollection dan routingRules juga.

Benar sekali. Mirip dengan proksi Layer 7, Anda dapat menambahkan titik akhir privat ke kumpulan backend gateway aplikasi Anda. Titik akhir privat ini harus disebarkan dalam subnet yang berdekatan dari jaringan virtual yang sama dari gateway aplikasi Anda.

Ini tidak menggunakan Keepalive untuk koneksi backend. Untuk setiap permintaan masuk pada koneksi pendengar frontend, Application Gateway memulai koneksi backend baru untuk memenuhi permintaan tersebut.

Server backend melihat alamat IP gateway aplikasi. Saat ini, kami tidak mendukung "Preservasi IP Klien" di mana aplikasi backend dapat mengetahui alamat IP klien asli.

Konfigurasi kebijakan TLS/SSL yang sama berlaku untuk Layer 7 (HTTPS) serta Layer 4 (TLS). Anda sekarang dapat menggunakan Profil SSL (untuk kebijakan TLS khusus listener dan Autentikasi Timah) untuk pendengar TLS. Namun, saat ini profil SSL hanya dapat dikaitkan dengan pendengar TLS melalui CLI, PowerShell, atau REST API.

Tidak. Perutean klien ke server backend yang sama tidak didukung saat ini. Koneksi akan didistribusikan secara round-robin ke server di kumpulan backend.

Ya, fitur skala otomatis juga akan beroperasi untuk lonjakan dan pengurangan lalu lintas untuk protokol TLS atau TCP.

Kemampuan Web Application Firewall (WAF) tidak akan berfungsi untuk penggunaan Layer 4.

Tidak. Dukungan UDP saat ini tidak tersedia.

Daftar rentang port dan pengecualian yang diizinkan yang sama juga berlaku untuk proksi Lapisan 4.

Penggunaan port umum untuk pendengar TLS/TCP saat ini tidak didukung.

Kubernetes memungkinkan pembuatan deployment sumber daya dan service mengekspos sekelompok pod secara internal dalam kluster. Untuk mengekspos layanan yang sama secara eksternal, Ingress sumber daya didefinisikan, yang menyediakan penyeimbangan beban, penghentian TLS, dan hosting virtual berbasis nama. Untuk memenuhi sumber daya ini Ingress , pengontrol ingress diperlukan, yang mendengarkan perubahan apa pun pada Ingress sumber daya dan mengonfigurasi kebijakan load balancer.

Application Gateway Ingress Controller (AGIC) memungkinkan Application Gateway digunakan sebagai ingress untuk Azure Kubernetes Service, yang juga dikenal sebagai kluster AKS.

Konfigurasi langsung Application Gateway tidak didukung.

Jika ada kebutuhan untuk mengubah pengaturan pada Application Gateway, buat perubahan dengan menggunakan konfigurasi yang diekspos pada pengontrol ingress atau objek Kubernetes lainnya, seperti dengan menggunakan anotasi yang didukung. Setelah Application Gateway ditautkan ke Application Gateway Ingress Controller (AGIC), hampir semua konfigurasi gateway tersebut akan disinkronkan dan dikontrol oleh pengontrol ingress. Jika Anda mencoba mengonfigurasi Application Gateway secara imperatif atau melalui infrastruktur sebagai kode, perubahan tersebut pada akhirnya akan ditimpa oleh pengontrol ingress.

Saat ini, satu instans pengontrol ingress hanya dapat dikaitkan dengan satu gateway aplikasi.

AGIC mencoba mengaitkan sumber daya tabel rute secara otomatis ke subnet Application Gateway tetapi mungkin gagal melakukannya karena kurangnya izin dari AGIC. Jika AGIC tidak dapat mengaitkan tabel rute ke subnet Application Gateway, kesalahan muncul di log AGIC. Dalam hal ini, Anda harus mengaitkan tabel rute yang dibuat secara manual oleh kluster AKS ke subnet Application Gateway. Untuk informasi selengkapnya, lihat Rute yang ditentukan pengguna yang didukung.

Ya, selama jaringan virtual diserekan dan tidak memiliki ruang alamat yang tumpang tindih. Jika Anda menjalankan AKS dengan kubenet, pastikan untuk mengaitkan tabel rute yang dihasilkan oleh AKS ke subnet Application Gateway.

Untuk perbedaan antara AGIC yang disebarkan melalui Helm versus yang disebarkan sebagai add-on AKS, lihat Perbedaan antara penyebaran Helm dan add-on AKS.

Untuk perbedaan antara AGIC yang disebarkan melalui Helm versus yang disebarkan sebagai add-on AKS, lihat Perbedaan antara penyebaran Helm dan add-on AKS, terutama tabel yang mendokumentasikan skenario mana yang didukung oleh AGIC yang disebarkan melalui Helm dibandingkan dengan add-on AKS. Secara umum, menyebarkan melalui Helm memungkinkan Anda menguji fitur beta dan merilis kandidat sebelum rilis resmi.

Tidak. Add-on AGIC adalah layanan terkelola, yang berarti Microsoft secara otomatis memperbarui add-on ke versi stabil terbaru.

Otentikasi timbal balik adalah autentikasi dua arah antara klien dan server. Autentikasi timbal balik dengan Application Gateway saat ini memungkinkan gateway untuk memverifikasi klien yang mengirim permintaan, yaitu autentikasi klien. Biasanya, klien adalah satu-satunya yang mengautentikasi gateway aplikasi. Karena Application Gateway sekarang juga dapat mengautentikasi klien, maka itu menjadi autentikasi timbal balik di mana Application Gateway dan klien saling mengautentikasi satu sama lain.

Tidak, autentikasi timah saat ini hanya antara klien frontend dan gateway aplikasi. Autentikasi timnas back-end saat ini tidak didukung.

Application Gateway menyediakan tiga log:

• ApplicationGatewayAccessLog: Log akses berisi setiap permintaan yang dikirimkan ke frontend gateway aplikasi. Data termasuk IP penelepon, URL yang diminta, latensi tanggapan, kode pengembalian, dan byte masuk dan keluar. Ini berisi satu rekaman per gateway aplikasi.
• ApplicationGatewayPerformanceLog: Log kinerja yang mencatat informasi kinerja untuk setiap gateway aplikasi. Informasi termasuk throughput dalam byte, total permintaan yang dilayani, jumlah permintaan gagal, dan jumlah instans backend yang sehat dan tidak sehat.
• ApplicationGatewayFirewallLog: Untuk gateway aplikasi yang Anda konfigurasi dengan WAF, log firewall berisi permintaan yang masuk melalui mode deteksi atau mode pencegahan.

Log firewall dikumpulkan setiap 60 detik. Untuk informasi selengkapnya, lihat Kesehatan back-end, log diagnostik, dan metrik untuk Application Gateway.

Verifikasi kesehatan menggunakan cmdlet PowerShell Get-AzApplicationGatewayBackendHealth atau portal. Untuk info selengkapnya, lihat Diagnostik Application Gateway.

Log diagnostik berjalan ke akun penyimpanan pelanggan. Pelanggan dapat mengatur kebijakan penyimpanan sesuai preferensinya. Log diagnostik juga dapat dikirim ke pusat aktivitas atau Log Azure Monitor. Untuk info selengkapnya, lihat Diagnostik Application Gateway.

Di portal, pada panel menu gateway aplikasi, pilih Log Aktivitas untuk mengakses log audit.

Ya. Di Application Gateway, pemberitahuan dikonfigurasi pada metrik. Untuk informasi selengkapnya, lihat Metrik Application Gateway dan Menerima notifikasi pemberitahuan.

Anda bisa melihat dan menganalisis log akses dengan beberapa cara. Gunakan Log Azure Monitor, Excel, Power BI, dan sebagainya.

Anda juga bisa menggunakan templat Resource Manager yang menginstal dan menjalankan pada penganalisis log populer GoAccess untuk log akses Application Gateway. GoAccess menyediakan statistik lalu lintas HTTP penting seperti pengunjung unik, file yang diminta, host, sistem operasi, browser, dan kode status HTTP. Untuk informasi selengkapnya, pada GitHub, lihat File Readme dalam folder templat Resource Manager.

Biasanya, Anda melihat status yang tidak diketahui saat akses ke backend diblokir oleh NSG, DNS kustom, atau perutean yang ditentukan pengguna pada subnet Application Gateway. Untuk informasi selengkapnya, lihat Kesehatan back-end, pembuatan log diagnostik, dan metrik untuk Application Gateway.

Karena keterbatasan platform saat ini, jika Anda memiliki NSG pada subnet Application Gateway v2 (Standard_v2, WAF_v2) dan jika Anda telah mengaktifkan log alur NSG di dalamnya, Anda akan melihat perilaku nondeterministik. Skenario ini saat ini tidak didukung.

Application Gateway tidak memindahkan atau menyimpan data pelanggan ke luar wilayah tempat data tersebut disebarkan.

Langkah berikutnya

• Untuk mempelajari selengkapnya tentang Application Gateway, lihat Apa itu Azure Application Gateway.
• Untuk mempelajari tentang penghentian TLS dan TLS end-to-end dengan Application Gateway, lihat Mengaktifkan TLS end-to-end di Azure Application Gateway.