Tanya jawab umum tentang Application Gateway

Azure Application Gateway menyediakan pengontrol pengiriman aplikasi (ADC) 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 Azure Tiongkok 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 cari di portal, pada halaman gambaran umum untuk gateway aplikasi. Jika Anda menggunakan alamat IP internal, cari informasi di halaman gambaran umum.

Untuk SKU v2, buka sumber daya IP publik dan pilih Konfigurasi. Bidang Label nama DNS (opsional) disediakan untuk mengonfigurasi nama DNS.

Batas waktu Keep-Alive mengatur berapa lama Application Gateway 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.

Batas waktu Keep-Alive pada SKU v1 Application Gateway adalah 120 detik dan di SKU v2 selama 75 detik. Batas waktu TCP default adalah 4 menit pada IP virtual frontend (VIP) SKU v1 dan v2 Application Gateway. Anda bisa mengonfigurasi nilai batas waktu TCP diam pada Application Gateway v1 dan v2 agar berada di mana saja antara 4 menit dan 30 menit. Untuk Application Gateway v1 dan v2, Anda perlu menavigasi ke IP publik Application Gateway dan mengubah batas waktu diam TCP di bawah bilah "Konfigurasi" IP publik di Portal. Mengubah nilai alamat IP privat tidak didukung. 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 SKU Application Gateway v2, batas waktu diam diatur ke 180 detik dan tidak dapat dikonfigurasi.

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

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

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

Di Application Gateway SKU V1, VIP bisa 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 SKU V2 Application Gateway, alamat IP statis, sehingga alamat IP dan nama DNS tidak akan berubah selama masa pakai gateway aplikasi.

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

Gateway aplikasi mendukung hanya satu alamat IP publik atau pribadi.

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 itu bisa memakan waktu lebih lama tergantung jenis penyebaran. Misalnya, penyebaran di beberapa Zona Ketersediaan dengan banyak instans dapat memakan waktu lebih dari 6 menit.

Updates yang dimulai ke Application Gateway diterapkan satu domain pembaruan sekaligus. Saat setiap instans domain pembaruan sedang diperbarui, instans yang tersisa di domain pembaruan lain akan terus melayani lalu lintas¹. Koneksi aktif dikosongkan dengan lancar 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 akan berjalan sementara pada berkurangnya kapasitas maks, yang ditentukan oleh jumlah instans yang dikonfigurasi. Proses pembaruan akan dilanjutkan ke set instans berikutnya hanya jika set instans saat ini telah berhasil ditingkatkan.

¹ Jumlah instans minimum 2 disarankan untuk dikonfigurasi untuk penyebaran SKU Application Gateway v1 untuk memastikan setidaknya satu instans dapat melayani lalu lintas saat pembaruan diterapkan.

Application Gateway tidak mendukung protokol email seperti SMTP, IMAP, dan POP3. Layanan HTTP/HTTPS seperti lalu lintas OWA, ActiveSync, dan AutoDiscovery dapat mengalir melalui Application Gateway, namun pengecualian WAF mungkin diperlukan jika menggunakan sku WAF.

Ya. Untuk detailnya, lihat Migrasi Azure Application Gateway dan Azure Web Application Firewall dari v1 ke v2.

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

Nomor. 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, kecuali untuk garis bawah (_).

Ya, pembaruan browser Chromiumv80 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 ApplicationGatewayAffinity yang ada. Cookie ini mirip, tetapi cookie ApplicationGatewayAffinityCORS memiliki dua atribut lainnya yang ditambahkan ke: SameSite=None; Secure. Atribut ini mempertahankan sesi lekat bahkan untuk permintaan lintas asal. Lihat bagian afinitas berbasis cookie untuk informasi lainnya.

Pendengar aktif adalah pendengar yang terkait dengan aturan dan yang mengirim lalu lintas ke kumpulan backend. Pendengar apa pun yang hanya mengalihkan lalu lintas bukanlah pendengar aktif. Pendengar yang terkait dengan aturan pengalihan tidak dianggap aktif. Jika aturan pengalihan adalah aturan berbasis jalur, maka semua jalur dalam aturan pengalihan tersebut harus mengalihkan lalu lintas, jika tidak, pendengar dianggap aktif. Lihat Langganan Azure dan batas, kuota, serta batasan layanan untuk mengetahui detail batas komponen individu.

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 Traffic Manager untuk mendistribusikan lalu lintas di beberapa gateway aplikasi pada 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 dari Application Gateway.

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

Nomor. 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 jaringan virtual dan persyaratan subnet.

Selama Anda memiliki konektivitas IP, Application Gateway bisa berkomunikasi dengan instans di luar jaringan virtual tempat gateway 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.

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 untuk server DNS baru yang akan ditetapkan. Sampai saat itu, resolusi nama berbasis FQDN untuk konektivitas keluar bisa gagal.

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

Anda hanya dapat memindahkan Application Gateway di seluruh subnet dalam jaringan virtual yang sama. Ini didukung dengan V1 dengan frontend publik dan privat, dan V2 hanya dengan frontend publik. Penting juga untuk dicatat bahwa Application Gateway harus dalam status Dihentikan untuk melakukan tindakan ini. Perlu diingat bahwa menghentikan/memulai V1 mengubah IP publik. Operasi ini hanya dapat dilakukan menggunakan Azure PowerShell dan Azure CLI dengan menjalankan perintah di bawah ini:

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.

Nomor. 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 memeriksa port yang berbeda, Anda perlu mengonfigurasi beberapa pengaturan HTTP.

Nomor.

Lihat Urutan aturan pemrosesan.

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

Ya. Lihat batasi akses ke IP sumber tertentu.

Ya, Anda dapat menggunakan pendengar yang menghadap publik dan privat dengan nomor port yang sama untuk secara bersamaan mendukung klien publik dan privat (fitur dalam Pratinjau). Perhatikan bahwa jika Kelompok Keamanan Jaringan (NSG) dikaitkan dengan subnet gateway aplikasi Anda, aturan Masuk tertentu mungkin diperlukan tergantung pada konfigurasinya. Ketahui lebih banyak.

Application Gateway v2 saat ini tidak mendukung IPv6. Ini dapat beroperasi dalam tumpukan ganda VNet yang hanya menggunakan IPv4, tetapi subnet gateway harus khusus IPv4. Application Gateway v1 tidak mendukung VNet tumpukan ganda.

Application Gateway SKU v1 dapat berjalan dalam mode operasi yang disetujui FIPS 140-2, yang biasa 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, pengaturan FIPSMode harus dikonfigurasi melalui PowerShell, Templat ARM, atau REST API setelah langganan terdaftar untuk mengaktifkan konfigurasi FIPSmode.

Application Gateway V2 saat ini hanya mendukung konfigurasi frontend IP privat (tanpa IP publik) melalui pratinjau publik. Informasi selengkapnya dapat ditemukan di sini.

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, Anda dapat mengikuti proses di bawah ini:

1. Membuat Application Gateway 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 untuk itu.

3. Buat dan lampirkan Kelompok Keamanan Jaringan untuk subnet Application Gateway dengan konfigurasi berikut dalam tujuan prioritas:

   a. Izinkan lalu lintas dari Sumber sebagagi GatewayManager tag layanan dan Tujuan sebagai Apa saja dan post 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 yang diterapkan

   b. Izinkan lalu lintas dari Sumber sebagai tag layanan AzureLoadBalancer dan port tujuan sebagai Apa pun

   c. Tolak semua lalu lintas masuk dari Sumber sebagai tag layanan Internet dan port tujuan sebagai Apa pun. Beri aturan ini prioritas terakhir dalam aturan masuk

   d. Pertahankan aturan default seperti mengizinkan VirtualNetwork masuk sehingga akses pada alamat IP privat tidak diblokir

   e. Konektivitas Internet keluar tidak bisa diblokir. Jika tidak, Anda menghadapi masalah dengan pengelogan, metrik, dll.

Contoh konfigurasi NSG untuk akses ip privat saja:

Anda dapat menggunakan Azure PowerShell atau Azure CLI untuk menghentikan dan memulai Azure Application Gateway. Saat Anda menghentikan dan memulai Application Gateway, penagihan juga akan berhenti dan dimulai. Setiap operasi PUT yang dilakukan pada Application Gateway Yang Dihentikan (seperti menambahkan tag, pemeriksaan kesehatan, pendengar, dll.) memicu Start. Disarankan untuk 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 chiper suite di bawah ini.

• 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 pemindahan TLS dan TLS end-to-end, yang mengenkripsi 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 chiper suite 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 pengelolaan 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, hanya gunakan karakter alfanumerik dalam kata sandi file .pfx Anda.

Anggota Browser Otoritas Sertifikat (CA) 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

Sesuai 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 tiba-tiba.

Untuk memeriksa apakah sertifikat yang digunakan oleh aplikasi Anda telah dicabut referensi Pengumuman DigiCert dan Pelacak Pencabutan Sertifikat. Jika sertifikat Anda telah 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 tiba-tiba, atau untuk memperbarui sertifikat yang telah dicabut, silakan lihat posting pembaruan Azure kami untuk tautan remediasi dari berbagai layanan Azure yang mendukung BYOC: https://azure.microsoft.com/updates/certificateauthorityrevocation/

Untuk informasi tertentu Application Gateway, lihat di bawah ini -

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

1. Sertifikat tidak valid/sertifikat yang dicabut
2. Waktu sambungan habis
3. 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 Azure Application Gateway/WAF dengan rantai kepercayaan (node leaf, menengah, sertifikat akar). Berdasarkan tempat Anda menggunakan sertifikat, baik pada pendengar atau pengaturan HTTP Application Gateway, ikuti langkah-langkah di bawah ini untuk memperbarui sertifikat dan memeriksa tautan dokumentasi yang disebutkan untuk informasi selengkapnya.
3. Perbarui server aplikasi backend Anda untuk menggunakan sertifikat yang diterbitkan kembali. Bergantung pada server backend yang Anda gunakan, langkah-langkah pembaruan sertifikat Anda dapat 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. Klik "Perbarui atau edit sertifikat yang dipilih."
4. Unggah sertifikat PFX baru Anda dengan kata sandi dan klik 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 Azure KeyVault di pendengar Application Gateway Anda, sebaiknya ikuti langkah-langkah untuk perubahan cepat –

1. Di portal Azure, navigasikan ke pengaturan Azure KeyVault Anda yang terkait dengan Application Gateway.
2. Tambah/impor sertifikat yang diterbitkan ulang dalam penyimpanan Anda. Lihat dokumentasi di sini untuk informasi selengkapnya tentang caranya.
3. Setelah sertifikat diimpor, navigasikan ke pengaturan pendengar Application Gateway Anda dan di bawah "Pilih sertifikat dari Key Vault", klik drop-down "Sertifikat" dan pilih sertifikat yang baru ditambahkan
4. Klik Simpan Untuk informasi selengkapnya tentang penghentian TLS pada Application Gateway dengan sertifikat Key Vault, lihat penghentian TLS dengan sertifikat Key Vault.

Untuk memperbarui sertifikat dalam Pengaturan HTTP:

Jika Anda menggunakan SKU V1 dari layanan Application Gateway/WAF, Maka 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. Klik "Tambahkan sertifikat" dan unggah sertifikat yang diterbitkan kembali dan klik simpan.
4. Anda dapat menghapus sertifikat lama nanti dengan mengklik "..." tombol opsi di samping sertifikat lama dan pilih hapus dan klik 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.

Kube memungkinkan pembuatan sumber daya deployment dan service untuk mengekpos sekelompok pod secara internal di dalam kluster. Untuk mengekspos layanan yang sama secara eksternal, sumber daya Ingress ditentukan yang menyediakan keseimbangan beban, penghentian TLS, dan hosting virtual berbasis nama. Untuk memenuhi sumber daya Ingress ini, Pengontrol Ingress diperlukan yang mendengarkan perubahan apa pun terhadap sumber daya Ingress dan mengonfigurasi kebijakan penyeimbang beban.

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

Saat ini, satu instans Pengontrol Ingress hanya bisa terhubung ke satu Application Gateway.

AGIC mencoba untuk secara otomatis mengaitkan sumber daya tabel rute ke subnet Application Gateway tetapi mungkin gagal melakukannya karena kurangnya izin dari AGIC. Jika AGIC tidak dapat mengaitkan tabel rute ke subnet Application Gateway, akan ada kesalahan dalam log AGIC yang mengatakan demikian, 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 kamu menjalankan AKS dengan kubenet, pastikan untuk mengaitkan tabel rute yang dihasilkan oleh AKS ke subnet Application Gateway.

Lihat perbedaan antara AGIC yang disebarkan melalui Helm versus yang disebarkan sebagai add-on AKS di sini

Lihat perbedaan antara AGIC yang disebarkan melalui Helm dibandingkan yang disebarkan sebagai add-on AKS di sini, terutama tabel yang mendokumentasikan skenario mana yang didukung oleh AGIC yang disebarkan melalui Helm sebagai perbandingan add-on AKS. Secara umum, menyebarkan melalui Helm memungkinkan Anda untuk menguji fitur beta dan merilis kandidat sebelum rilis resmi.

Tidak, add-on AGIC adalah layanan terkelola, yang berarti Microsoft akan 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 Application Gateway. 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 timbal balik saat ini hanya antara klien frontend dan Application Gateway. Autentikasi timbal balik backend 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 backend, 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 bisa dikirim ke log Event Hub atau Azure Monitor. Untuk info selengkapnya, lihat diagnostik Application Gateway.

Di portal, pada bilah 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 lainnya.

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 kelompok keamanan jaringan (NSG), DNS kustom, atau perutean yang ditentukan pengguna (UDR) pada subnet gateway aplikasi. Untuk informasi selengkapnya, lihatKesehatan backend, pengelogan 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 dan skenario ini saat ini tidak didukung.

Application Gateway tidak memindahkan atau menyimpan data pelanggan keluar dari wilayah tempat data 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.