Memecahkan masalah gateway buruk di Application Gateway

Pelajari bagaimana memecahkan masalah kesalahan gateway buruk (502) di Azure Application Gateway.

Catatan

Sebaiknya Anda menggunakan modul Azure Az PowerShell untuk berinteraksi dengan Azure. Lihat Menginstal Azure PowerShell untuk memulai. Untuk mempelajari cara bermigrasi ke modul Az PowerShell, lihat Memigrasikan Azure PowerShell dari AzureRM ke Az.

Gambaran Umum

Setelah Anda mengonfigurasi gateway aplikasi, salah satu kesalahan yang mungkin Anda lihat adalah Kesalahan Server: 502 - Server web menerima respons yang tidak valid saat bertindak sebagai gateway atau server proksi. Kesalahan ini mungkin terjadi karena alasan utama berikut:

• NSG, UDR, atau DNS Kustom memblokir akses ke anggota kumpulan ujung belakang.
• VM backend atau instans set skala komputer virtual tidak merespons pemeriksaan kesehatan default.
• Konfigurasi pemeriksaan kesehatan kustom tidak valid atau tidak tepat.
• Kumpulan backend Azure Application Gateway tidak dikonfigurasi atau kosong.
• Tidak ada komputer virtual atau instans dalam set skala komputer virtual yang sehat.
• Meminta masalah waktu habis atau konektivitas dengan permintaan pengguna.

Grup Keamanan Jaringan, Rute Yang Ditentukan Pengguna, atau masalah DNS Kustom

Penyebab

Jika akses ke ujung belakang diblokir karena NSG, UDR, atau DNS kustom, instans gateway aplikasi tidak dapat mencapai kumpulan ujung belakang. Masalah ini menyebabkan kegagalan pemeriksaan, mengakibatkan kesalahan 502.

NSG/UDR dapat hadir baik di subnet gateway aplikasi atau subnet tempat aplikasi komputer virtual digunakan.

Demikian pula, kehadiran DNS kustom di VNet juga dapat menyebabkan masalah. FQDN yang digunakan untuk anggota kumpulan backend mungkin tidak diselesaikan dengan benar oleh server DNS yang dikonfigurasi pengguna untuk VNet.

Solusi

Validasi konfigurasi NSG, UDR, dan DNS dengan melalui langkah-langkah berikut:

1. Periksa NSG yang terkait dengan subnet gateway aplikasi. Pastikan bahwa komunikasi ke ujung belakang tidak diblokir. Untuk informasi selengkapnya, lihat Kelompok keamanan jaringan.

2. Periksa NSG yang terkait dengan subnet gateway aplikasi. Pastikan UDR tidak mengarahkan lalu lintas menjauh dari subnet ujung belakang. Misalnya, periksa rute ke peralatan virtual jaringan atau rute default yang diiklankan ke subnet gateway aplikasi melalui Azure ExpressRoute/VPN.

   $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
   Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
   

3. Periksa NSG dan rute yang efektif dengan komputer virtual ujung belakang

   Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
   Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
   

4. Periksa keberadaan DNS kustom di VNet. DNS dapat diperiksa dengan melihat detail properti VNet dalam output.

   Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
   DhcpOptions            : {
                              "DnsServers": [
                                "x.x.x.x"
                              ]
                            }
   

5. Jika ada, pastikan bahwa server DNS dapat menyelesaikan FQDN anggota kumpulan ujung belakang dengan benar.

Masalah dengan pemeriksaan kesehatan default

Penyebab

Kesalahan 502 juga dapat menjadi indikator yang sering bahwa pemeriksaan kesehatan default tidak dapat mencapai VM backend.

Saat instans gateway aplikasi disediakan, ia secara otomatis mengonfigurasi pemeriksaan kesehatan default ke setiap BackendAddressPool menggunakan properti BackendHttpSetting. Tidak diperlukan masukan pengguna untuk menyetel pemeriksaan ini. Secara khusus, saat aturan penyeimbangan muatan dikonfigurasi, sebuah kaitan dibuat antara BackendHttpSetting dan BackendAddressPool. Pemeriksaan default dikonfigurasi untuk setiap asosiasi ini dan gateway aplikasi memulai koneksi pemeriksaan kesehatan berkala untuk setiap contoh di BackendAddressPool di port yang ditentukan dalam elemen BackendHttpSetting.

Tabel berikut ini mencantumkan nilai yang terkait dengan pemeriksaan kesehatan default:

Properti pemeriksaan	Nilai	Deskripsi
URL Pemeriksaan	http://127.0.0.1/	Jalur URL
Interval	30	Jeda pemeriksaan dalam hitungan detik
Waktu habis	30	Pemeriksaan waktu habis dalam hitungan detik
Ambang tidak sehat	3	Menyelidiki jumlah percobaan kembali. Server backend ditandai ke bawah setelah jumlah kegagalan pemeriksaan berturut-turut mencapai ambang tidak sehat.

Solusi

• Nilai host permintaan akan diatur ke 127.0.0.1. Pastikan bahwa situs default dikonfigurasi dan mendengarkan di 127.0.0.1.
• Protokol permintaan ditentukan oleh protokol BackendHttpSetting.
• Jalur URI akan diatur ke /.
• Jika BackendHttpSetting menentukan port selain 80, situs default harus dikonfigurasi untuk mendengarkan di port tersebut.
• Panggilan untuk protocol://127.0.0.1:port mengembalikan kode hasil HTTP 200. Kode ini harus dikembalikan dalam periode batas waktu 30 detik.
• Pastikan port yang dikonfigurasi terbuka dan tidak ada aturan firewall atau Grup Keamanan Jaringan Azure yang memblokir lalu lintas masuk atau keluar pada port yang dikonfigurasi.
• Jika VM klasik Azure atau Cloud Service digunakan dengan FQDN atau IP publik, pastikan titik akhir yang sesuai dibuka.
• Jika komputer virtual dikonfigurasi melalui Azure Resource Manager dan berada di luar VNet tempat gateway aplikasi digunakan, Grup Keamanan Jaringan harus dikonfigurasi untuk mengizinkan akses pada port yang diinginkan.

Untuk info selengkapnya, lihat Konfigurasi infrastruktur Application Gateway.

Masalah dengan pemeriksaan kesehatan kustom

Penyebab

Pemeriksaan kesehatan kustom memungkinkan fleksibilitas tambahan untuk perilaku pemeriksaan default. Saat Anda menggunakan pemeriksaan kustom, Anda dapat mengonfigurasi interval pemeriksaan, URL, jalur untuk menguji, dan berapa banyak respons yang gagal diterima sebelum menandai instans kumpulan backend sebagai tidak sehat.

Properti tambahan berikut ini ditambahkan:

Properti pemeriksaan	Deskripsi
Nama	Nama pemeriksaan. Nama ini digunakan untuk merujuk ke pemeriksaan di pengaturan HTTP backend.
Protokol	Protokol yang digunakan untuk mengirim pemeriksaan. Pemeriksaan menggunakan protokol yang ditentukan dalam pengaturan HTTP backend
Host	Nama host untuk mengirim probe. Hal ini berlaku ketika multi-situs dikonfigurasi di gateway aplikasi. Ini berbeda dengan nama host komputer virtual.
Jalur	Jalur relatif dari pemeriksaan. Jalur valid dimulai dari '/'. Pemeriksaan dikirim ke <protokol>://<host>:<jalur port><>
Interval	Jeda pemeriksaan dalam hitungan detik. Nilai ini adalah jeda waktu antara dua pemeriksaan berturutan.
Waktu habis	Menyelidiki waktu habis dalam hitungan detik. Jika respons yang valid tidak diterima dalam periode waktu habis ini, probe ditandai sebagai gagal.
Ambang tidak sehat	Menyelidiki jumlah percobaan kembali. Server backend ditandai ke bawah setelah jumlah kegagalan pemeriksaan berturut-turut mencapai ambang tidak sehat.

Solusi

Validasi bahwa Pemeriksaan Kesehatan Kustom dikonfigurasi dengan benar, seperti yang ditunjukkan dalam tabel sebelumnya. Selain langkah-langkah pemecahan masalah sebelumnya, pastikan juga hal-hal berikut:

• Pastikan bahwa pemeriksaan ditentukan dengan benar sesuai panduan.
• Jika gateway aplikasi dikonfigurasi untuk satu situs, secara default nama Host harus ditentukan sebagai 127.0.0.1, kecuali dikonfigurasi lain dalam pemeriksaan kustom.
• Pastikan bahwa panggilan ke jalur http://< host>:<port><> mengembalikan kode hasil HTTP 200.
• Pastikan jeda, waktu habis, dan ambang batas tidak sehat berada dalam rentang yang dapat diterima.
• Jika menggunakan pemeriksaan HTTPS, pastikan bahwa server ujung belakang tidak memerlukan SNI dengan mengonfigurasi sertifikat fallback pada server ujung belakang itu sendiri.

Waktu Permintaan

Penyebab

Saat permintaan pengguna diterima, gateway aplikasi menerapkan aturan yang dikonfigurasi ke permintaan dan merutekannya ke instans kumpulan backend. Ini menunggu interval waktu yang dapat dikonfigurasi untuk respons dari instans backend. Secara default, jeda ini adalah 20 detik. Dalam Application Gateway v1, jika gateway aplikasi tidak menerima respons dari aplikasi backend dalam interval ini, permintaan pengguna mendapatkan kesalahan 502. Di Application Gateway v2, jika gateway aplikasi tidak menerima respons dari aplikasi backend dalam interval ini, permintaan akan dicoba terhadap anggota kumpulan backend kedua. Jika permintaan kedua gagal, permintaan pengguna akan mendapatkan kesalahan 504.

Solusi

Application Gateway memungkinkan Anda mengonfigurasi pengaturan ini melalui BackendHttpSetting, yang kemudian bisa diterapkan ke kumpulan yang berbeda. Kumpulan backend yang berbeda dapat memiliki BackendHttpSetting yang berbeda, dan batas waktu permintaan yang berbeda dikonfigurasi.

    New-AzApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -CookieBasedAffinity Enabled -RequestTimeout 60

BackendAddressPool Kosong

Penyebab

Jika gateway aplikasi tidak memiliki VM atau set skala komputer virtual yang dikonfigurasi di kumpulan alamat backend, gateway tidak dapat merutekan permintaan pelanggan apa pun dan mengirim kesalahan gateway yang buruk.

Solusi

Pastikan bahwa kumpulan alamat backend tidak kosong. Ini dapat dilakukan baik melalui PowerShell, CLI, atau portal.

Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"

Output dari cmdlet sebelumnya harus berisi kumpulan alamat backend yang tidak ada. Contoh berikut menunjukkan dua kumpulan yang dikembalikan yang dikonfigurasi dengan FQDN atau alamat IP untuk VM backend. Status penyediaan BackendAddressPool harus 'Berhasil'.

BackendAddressPoolsText:

[{
    "BackendAddresses": [{
        "ipAddress": "10.0.0.10",
        "ipAddress": "10.0.0.11"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool01",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
    "BackendAddresses": [{
        "Fqdn": "xyx.cloudapp.net",
        "Fqdn": "abc.cloudapp.net"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool02",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]

Instans tidak sehat di BackendAddressPool

Penyebab

Jika semua instans BackendAddressPool tidak sehat, gateway aplikasi tidak memiliki backend untuk merutekan permintaan pengguna. Ini juga dapat terjadi ketika instans backend sehat tetapi tidak memiliki aplikasi yang diperlukan yang disebarkan.

Solusi

Pastikan instans sehat dan aplikasi dikonfigurasi dengan benar. Periksa apakah instans backend dapat merespons ping dari VM lain di VNet yang sama. Jika dikonfigurasi dengan titik akhir publik, pastikan permintaan browser ke aplikasi web dapat digunakan.

Sertifikat SSL upstram tidak cocok

Penyebab

Sertifikat TLS yang diinstal pada server backend tidak cocok dengan nama host yang diterima di header permintaan Host.

Dalam skenario di mana TLS End-to-end diaktifkan, konfigurasi yang dicapai dengan mengedit "Backend HTTP Pengaturan" yang sesuai, dan mengubah di sana konfigurasi pengaturan "Protokol backend" ke HTTPS, adalah wajib untuk memastikan bahwa CNAME sertifikat TLS yang diinstal pada server backend cocok dengan nama host yang datang ke backend dalam permintaan header host HTTP.

Sebagai pengingat, efek mengaktifkan pada opsi "Backend HTTP Pengaturan" https protokol daripada HTTP, adalah bahwa bagian kedua dari komunikasi yang terjadi antara instans Application Gateway dan server backend akan dienkripsi dengan TLS.

Karena fakta bahwa secara default Application Gateway mengirim header host HTTP yang sama ke backend seperti yang diterima dari klien, Anda harus memastikan bahwa sertifikat TLS yang diinstal di server backend, dikeluarkan dengan CNAME yang cocok dengan nama host yang diterima oleh server backend tersebut di header host HTTP. Ingatlah bahwa, kecuali ditentukan sebaliknya, nama host ini akan sama dengan yang diterima dari klien.

Contohnya:

Bayangkan Anda memiliki Application Gateway untuk melayani permintaan https untuk www.contoso.com domain. Anda bisa memiliki domain contoso.com didelegasikan ke Zona Publik Azure DNS, dan catatan DNS di zona tersebut yang menunjuk www.contoso.com ke IP publik Application Gateway tertentu yang akan melayani permintaan.

Pada Application Gateway tersebut, Anda harus memiliki pendengar untuk host www.contoso.com dengan aturan yang memiliki "Pengaturan HTTP Yang Didukung" yang dipaksa untuk menggunakan HTTPS protokol (memastikan TLS End-to-end). Aturan yang sama dapat mengonfigurasi kumpulan backend dengan dua VM yang menjalankan IIS sebagai server Web.

Seperti yang kita ketahui mengaktifkan HTTPS di "Pengaturan HTTP yang Didukung" aturan akan membuat bagian kedua dari komunikasi yang terjadi antara instans Application Gateway dan server di backend untuk menggunakan TLS.

Jika server backend tidak memiliki sertifikat TLS yang dikeluarkan untuk www.contoso.com CNAME atau *.contoso.com, permintaan akan gagal dengan Kesalahan Server: 502 - Server web menerima respons yang tidak valid saat bertindak sebagai gateway atau server proksi karena sertifikat SSL upstream (sertifikat yang diinstal pada server backend) tidak akan cocok dengan nama host di header host, dan karenanya negosiasi TLS akan gagal.

www.contoso.com --> IP ujung depan GW APLIKASI --> Listener dengan aturan yang mengonfigurasi "Backend HTTP Pengaturan" untuk menggunakan HTTPS protokol daripada HTTP --> Kumpulan Backend --> Server web (perlu menginstal sertifikat TLS untuk www.contoso.com)

Solusi

diperlukan bahwa CNAME sertifikat TLS yang diinstal di server backend, cocok dengan nama host yang dikonfigurasi dalam pengaturan backend HTTP, jika tidak, bagian kedua dari komunikasi End-to-end yang terjadi antara instans Application Gateway dan backend, akan gagal dengan "Sertifikat SSL Upstream tidak cocok", dan akan mengembalikan Kesalahan Server: 502 - Server web menerima respons yang tidak valid saat bertindak sebagai gateway atau server proksi

Langkah berikutnya

Jika langkah-langkah sebelumnya tidak mengatasi masalah, buka tiket dukungan.