Bagikan melalui

Memecahkan masalah kondisi backend di Application Gateway

  • Artikel

Gambaran Umum

Secara default, Azure Application Gateway menyelidiki server backend untuk memeriksa status kesehatan mereka dan untuk memeriksa apakah mereka siap untuk melayani permintaan. Pengguna juga dapat membuat penyelidikan kustom untuk menyebutkan nama host, jalur yang akan diselidiki, dan kode status yang akan diterima sebagai Sehat. Dalam setiap kasus, jika server backend tidak berhasil merespons, Application Gateway menandai server sebagai Tidak Sehat dan berhenti meneruskan permintaan ke server. Setelah server mulai berhasil merespons, Application Gateway melanjutkan penerusan permintaan.

Cara memeriksa kesehatan backend

Untuk memeriksa kesehatan kumpulan backend Anda, Anda dapat menggunakan halaman kesehatan Backend di portal Microsoft Azure. Atau, Anda dapat menggunakan Azure PowerShell, CLI,atau REST API.

Status yang diambil oleh salah satu metode ini dapat menjadi salah satu status berikut:

  • Sehat
  • Tidak sehat
  • Tidak dikenal

Application Gateway meneruskan permintaan ke server dari kumpulan backend jika statusnya sehat. Jika semua server di kumpulan backend tidak sehat atau tidak diketahui, klien dapat mengalami masalah saat mengakses aplikasi backend. Baca lebih lanjut untuk memahami berbagai pesan yang dilaporkan oleh Backend Health, penyebabnya, dan resolusinya.

Catatan

Jika pengguna Anda tidak memiliki izin untuk melihat status kesehatan backend, No results. akan ditampilkan.

Status kesehatan backend: Tidak Sehat

Jika status kesehatan backend Tidak Sehat, tampilan portal menyerupan cuplikan layar berikut:

Application Gateway backend health - Unhealthy

Jika Anda menggunakan kueri Azure PowerShell, CLI, atau Azure REST API, Anda mendapatkan respons yang menyerupai contoh berikut:

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

Setelah Anda menerima status server backend tidak sehat untuk semua server di kumpulan backend, permintaan tidak diteruskan ke server, dan Application Gateway menghasilkan kesalahan "502 Gateway Buruk" ke klien yang meminta. Untuk memecahkan masalah ini, periksa kolom Detail pada tab Kesehatan Backend.

Pesan yang ditampilkan di kolom Detail memberikan wawasan yang lebih rinci tentang masalah ini, dan berdasarkan detail tersebut, Anda dapat mulai memecahkan masalah.

Catatan

Permintaan pemeriksaan default dikirim dalam format <protokol>://127.0.0.1:<port>. Misalnya, http://127.0.0.1:80 untuk pemeriksaan HTTP pada port 80. Hanya kode status HTTP 200 hingga 399 yang dianggap sehat. Port protokol dan tujuan diwariskan dari setelan HTTP. Jika Anda ingin Application Gateway menyelidiki protokol, nama host, atau jalur yang berbeda dan mengenali kode status yang berbeda sebagai Sehat, konfigurasikan pemeriksaan kustom dan kaitkan dengan pengaturan HTTP.

Pesan kesalahan

Waktu server backend habis

Pesan: Waktu yang dibutuhkan backend untuk merespons pemeriksaan kesehatan gateway aplikasi melebihi ambang batas waktu yang ditentukan dalam pengaturan pemeriksaan.

Penyebab: Setelah Application Gateway mengirim permintaan pemeriksaan HTTP ke server backend, gateway menunggu respons dari server backend untuk periode yang dikonfigurasi. Jika server backend tidak merespons dalam periode yang dikonfigurasi (nilai waktu habis), server ditandai sebagai Tidak Sehat hingga mulai merespons dalam periode batas waktu yang dikonfigurasi lagi.

Resolusi: Periksa mengapa server atau aplikasi backend tidak merespons dalam periode waktu habis yang dikonfigurasi, dan periksa juga dependensi aplikasi. Misalnya, periksa apakah database memiliki masalah yang mungkin memicu keterlambatan respons. Jika Anda mengetahui perilaku aplikasi dan harus merespons hanya setelah nilai waktu habis, tingkatkan nilai batas waktu dari pengaturan pemeriksaan kustom. Anda harus memiliki pemeriksaan kustom untuk mengubah nilai waktu habis. Untuk informasi tentang cara mengkonfigurasi pemeriksaan kustom, lihat halaman dokumentasi.

Untuk menambah nilai batas waktu, ikuti langkah-langkah berikut:

  1. Akses server backend secara langsung dan periksa waktu yang diambil untuk merespons server di halaman itu. Anda dapat menggunakan alat apa pun untuk mengakses server backend, termasuk browser menggunakan alat pengembang.
  2. Setelah Anda mengetahui waktu yang diperlukan aplikasi untuk merespons, pilih tab Pemeriksaan Kesehatan, lalu pilih pemeriksaan yang terkait dengan pengaturan HTTP Anda.
  3. Masukkan nilai waktu habis apa pun yang lebih besar dari waktu respons aplikasi, dalam detik.
  4. Simpan pengaturan pemeriksaan kustom dan periksa apakah kesehatan backend menunjukkan status Sehat sekarang.

Kesalahan resolusi DNS

Pesan: Application Gateway tak bisa membuat pemeriksaan untuk backend ini. Hal Ini biasanya terjadi ketika FQDN backend belum dimasukkan dengan benar. 

Penyebab: Jika kumpulan backend berjenis Alamat IP, FQDN (nama domain yang sepenuhnya memenuhi syarat) atau App Service, Application Gateway menyelesaikan ke alamat IP FQDN yang dimasukkan melalui DNS (kustom atau default Azure). Gateway aplikasi kemudian mencoba terhubung ke server pada port TCP yang disebutkan dalam pengaturan HTTP. Tetapi jika pesan ini ditampilkan, itu menunjukkan bahwa Application Gateway tidak berhasil menyelesaikan alamat IP FQDN yang dimasukkan.

Resolusi:

  1. Verifikasi bahwa FQDN yang dimasukkan di kumpulan backend sudah benar dan merupakan domain publik, lalu coba tetapkan dari komputer lokal.
  2. Jika Anda dapat menyelesaikan alamat IP, mungkin ada sesuatu yang salah dengan konfigurasi DNS di jaringan virtual.
  3. Periksa apakah jaringan virtual dikonfigurasi dengan server DNS kustom. Jika ya, periksa server DNS tentang mengapa server tidak dapat mengatasi alamat IP dari FQDN yang ditentukan.
  4. Jika Anda menggunakan DNS default Azure, tanyakan kepada pencatat nama domain Anda tentang apakah pemetaan catatan A atau catatan CNAME yang tepat telah selesai.
  5. Jika domain bersifat pribadi atau internal, cobalah untuk menyelesaikannya dari komputer virtual di jaringan virtual yang sama. Jika Anda dapat mengatasinya, hidupkan ulang Application Gateway dan periksa lagi. Untuk memulai ulang Application Gateway, Anda perlu hentikan dan mulai dengan menggunakan perintah PowerShell yang dijelaskan dalam sumber daya yang ditautkan ini.

Kesalahan menyambungkan TCP

Pesan: Application Gateway tak bisa tersambung ke backend. Periksa apakah backend merespons pada port yang digunakan untuk pemeriksaan. Periksa juga apakah ada NSG/UDR/Firewall yang memblokir akses ke IP dan port backend ini.

Penyebab: Setelah fase resolusi DNS, Application Gateway mencoba menyambungkan ke server backend pada port TCP yang dikonfigurasi di pengaturan HTTP. Jika Application Gateway tidak dapat membuat sesi TCP pada port yang ditentukan, pemantauan ditandai sebagai Tidak Sehat dengan pesan ini.

Solusi: Jika Anda menerima kesalahan ini, ikuti langkah-langkah berikut:

  1. Periksa apakah Anda dapat menyambungkan ke server backend pada port yang disebutkan di pengaturan HTTP dengan menggunakan browser atau PowerShell. Misalnya, jalankan perintah berikut: Test-NetConnection -ComputerName www.bing.com -Port 443.

  2. Jika port yang disebutkan bukan port yang diinginkan, masukkan nomor port yang benar untuk Application Gateway untuk menyambungkan ke server backend.

  3. Jika Anda tidak dapat terhubung pada port dari mesin lokal Anda juga, maka:

    a. Periksa pengaturan grup keamanan jaringan (NSG) adapter dan subnet jaringan server backend dan apakah koneksi masuk ke port yang dikonfigurasi tersebut diperbolehkan. Jika tidak, buat aturan baru untuk memperbolehkan koneksi. Untuk mempelajari cara membuat aturan NSG, lihat halaman dokumentasi.

    b. Periksa apakah pengaturan NSG subnet Application Gateway memperbolehkan lalu lintas publik dan pribadi keluar, sehingga koneksi dapat dibuat. Periksa halaman dokumen yang disediakan di langkah 3a untuk mempelajari selengkapnya tentang cara membuat aturan NSG.

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

    c. Periksa pengaturan rute yang ditentukan pengguna (UDR) dari Application Gateway dan subnet server ujung belakang untuk anomali perutean apa pun. Pastikan UDR tidak mengarahkan lalu lintas menjauh dari subnet backend. Misalnya, periksa rute ke peralatan virtual jaringan atau rute default yang diiklankan ke subnet Application Gateway melalui Azure ExpressRoute dan/atau VPN.

    d. Untuk memeriksa rute dan aturan efektif untuk adaptor jaringan, Anda bisa menggunakan perintah PowerShell berikut ini:

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

  4. Jika Anda tidak menemukan masalah dengan NSG atau UDR, periksa server backend Anda untuk masalah terkait aplikasi yang mencegah klien membuat sesi TCP pada port yang dikonfigurasi. Beberapa hal yang perlu diperiksa:

    a. Buka prompt perintah (Win+R -> cmd), masukkan netstat, dan pilih Enter.

    b. Periksa apakah server mendengarkan pada port yang terkonfigurasi. Contohnya:

            Proto Local Address Foreign Address State PID
        TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4

    c. Jika tidak mendengarkan port yang terkonfigurasi, periksa pengaturan server web Anda. Misalnya: pengikatan situs di IIS, blok server di NGINX dan hosting virtual di Apache.

    d. Periksa pengaturan firewall OS Anda untuk memastikan bahwa lalu lintas masuk ke port diperbolehkan.

Kode status HTTP tidak cocok

Pesan: Kode status respons HTTP backend tidak cocok dengan pengaturan pemeriksaan. Diduga:{HTTPStatusCode0} Diterima:{HTTPStatusCode1}.

Penyebab: Setelah koneksi TCP dibuat dan jabat tangan TLS selesai (jika TLS diaktifkan), Application Gateway akan mengirim pemeriksaan sebagai permintaan HTTP GET ke server backend. Seperti yang dijelaskan sebelumnya, pemeriksaan default adalah , <protocol>://127.0.0.1:<port>/dan mempertimbangkan kode status respons dalam rentang 200 hingga 399 sebagai Sehat. Jika server mengembalikan kode status lainnya, server ditandai sebagai Tidak Sehat dengan pesan ini.

Solusi: Bergantung pada kode respons server backend, Anda dapat mengambil langkah-langkah berikut. Beberapa kode status umum tercantum di sini:

Kesalahan Tindakan
Ketidakcocokan kode status probe: Diterima 401 Periksa apakah server ujung belakang memerlukan autentikasi. Probe Application Gateway tidak dapat meneruskan kredensial untuk autentikasi. Izinkan "HTTP 401" dalam kecocokan kode status pemeriksaan atau probe ke jalur di mana server tidak memerlukan autentikasi.
Ketidakcocokan kode status probe: Diterima 403 Akses dilarang. Periksa apakah akses ke jalur tersebut diperbolehkan di server ujung belakang.
Ketidakcocokan kode status probe: Diterima 404 Halaman tidak ditemukan. Periksa apakah jalur nama host dapat diakses di server ujung belakang. Ubah parameter nama host atau jalur ke nilai yang dapat diakses.
Ketidakcocokan kode status probe: Diterima 405 Permintaan penyelidikan untuk Application Gateway menggunakan metode HTTP GET. Periksa apakah server Anda memperbolehkan metode ini.
Ketidakcocokan kode status probe: Diterima 500 Kesalahan Server Internal Periksa kesehatan server ujung belakang dan apakah layanan berjalan.
Ketidakcocokan kode status probe: Diterima 503 Layanan tidak tersedia. Periksa kesehatan server ujung belakang dan apakah layanan berjalan.

Atau, jika Menurut Anda responsnya sah dan Anda ingin Application Gateway menerima kode status lain sebagai Sehat, Anda dapat membuat pemeriksaan kustom. Pendekatan ini berguna dalam situasi di mana situs web backend membutuhkan autentikasi. Karena permintaan probe tidak membawa kredensial pengguna apa pun, mereka akan gagal, dan kode status HTTP 401 akan dikembalikan oleh server ujung belakang.

Untuk membuat pemeriksaan kustom, ikuti langkah-langkah ini.

Ketidakcocokan isi respons HTTP

Pesan: Isi respons HTTP backend tidak cocok dengan pengaturan pemeriksaan. Isi respons yang diterima tidak berisi {string}.

Penyebab: Saat membuat pemeriksaan kustom, Anda dapat menandai server backend sebagai Sehat dengan mencocokkan string dari isi respons. Misalnya, Anda dapat mengkonfigurasi Application Gateway untuk menerima "tidak sah" sebagai string yang cocok. Jika respons server backend untuk permintaan pemeriksaan berisi string yang tidak sah, itu menandainya sebagai Sehat. Jika tidak, itu ditandai sebagai Tidak Sehat dengan pesan yang diberikan.

Solusi:Untuk mengatasi masalah ini, ikuti langkah-langkah berikut:

  1. Akses server ujung belakang secara lokal atau dari mesin klien di jalur pemeriksaan, dan periksa isi respons.
  2. Verifikasi bahwa badan respons dalam konfigurasi pemeriksaan kustom Application Gateway cocok dengan apa yang dikonfigurasi.
  3. Jika tidak cocok, ubah konfigurasi pemeriksaan sehingga memiliki nilai string yang benar untuk diterima.

Pelajari selengkapnya tentang pencocokan pemeriksaan Application Gateway.

Catatan

Untuk semua pesan kesalahan terkait TLS, untuk mempelajari lebih lanjut tentang perilaku dan perbedaan SNI antara SKU v1 dan v2, periksa halaman ikhtisar TLS.

Nama Umum (CN) tidak cocok

Pesan: (Untuk V2) Nama Umum sertifikat daun yang disajikan oleh server backend tidak cocok dengan nama host Probe atau Pengaturan Backend gateway aplikasi.
(Untuk V1) Nama Umum (CN) sertifikat backend tidak cocok.

Penyebab: (Untuk V2) Ini terjadi ketika Anda telah memilih protokol HTTPS di pengaturan backend, dan Probe Kustom atau nama host Pengaturan Backend (dengan urutan tersebut) cocok dengan Nama Umum (CN) sertifikat server backend.
(Untuk V1) FQDN dari target kumpulan backend tidak cocok dengan Nama Umum (CN) sertifikat server backend.

Solusi: Informasi nama host sangat penting untuk koneksi HTTPS backend karena nilai tersebut digunakan untuk mengatur Indikasi Nama Server (SNI) selama jabat tangan TLS. Anda dapat memperbaiki masalah ini dengan cara berikut berdasarkan konfigurasi gateway Anda.

Untuk V2,

  • Jika Anda menggunakan Probe Default – Anda dapat menentukan nama host di pengaturan Backend terkait gateway aplikasi Anda. Anda dapat memilih "Ganti dengan nama host tertentu" atau "Pilih nama host dari target backend" di pengaturan backend.
  • Jika Anda menggunakan Pemeriksaan Kustom – Untuk Pemeriksaan Kustom, Anda dapat menggunakan bidang "host" untuk menentukan Nama Umum sertifikat server backend. Atau, jika Pengaturan Backend sudah dikonfigurasi dengan nama host yang sama, Anda dapat memilih "Pilih nama host dari pengaturan backend" di pengaturan pemeriksaan.

Untuk V1, verifikasi FQDN target kumpulan backend sama dengan Nama Umum (CN).

Tips: Untuk menentukan Nama Umum (CN) sertifikat server backend, Anda dapat menggunakan salah satu metode ini. Perhatikan juga, sesuai RFC 6125 jika SAN ada verifikasi SNI dilakukan hanya terhadap bidang tersebut. Bidang nama umum dicocokkan jika tidak ada SAN dalam sertifikat.

  • Dengan menggunakan browser atau klien apa pun: Akses server backend secara langsung (bukan melalui Application Gateway) dan klik gembok sertifikat di bilah alamat untuk melihat detail sertifikat. Anda akan menemukannya di bawah bagian "Dikeluarkan Ke". Screenshot that shows certificate details in a browser.

  • Dengan masuk ke server backend (Windows):

    1. Masuk ke komputer tempat aplikasi Anda dihosting.
    2. Pilih Win+R atau klik kanan tombol Mulai lalu pilih Jalankan.
    3. Masukkan certlm.msc dan pilih Enter. Anda juga dapat mencari Pengelola Sertifikat pada menu Mulai.
    4. Temukan sertifikat (biasanya di Sertifikat - Komputer Lokal\Pribadi\Sertifikat), dan buka sertifikat.
    5. Pada tab Detail, periksa Subjek sertifikat.

  • Dengan masuk ke server backend (Linux): Jalankan perintah OpenSSL ini dengan menentukan nama file sertifikat yang tepat openssl x509 -in certificate.crt -subject -noout

Sertifikat backend kedaluwarsa

Pesan: Sertifikat backend tidak valid. Tanggal saat ini tidak berada dalam rentang tanggal "Valid dari" dan "Valid ke" pada sertifikat.

Penyebab: Sertifikat yang kedaluwarsa dianggap tidak aman dan karenanya gateway aplikasi menandai server backend dengan sertifikat yang kedaluwarsa sebagai tidak sehat.

Solusi: Solusi tergantung pada bagian mana dari rantai sertifikat yang telah kedaluwarsa di server backend.

Untuk V2 SKU,

  • Sertifikat Expired Leaf (juga dikenal sebagai Domain atau Server) - Perbarui sertifikat server dengan penyedia sertifikat dan instal sertifikat baru di server backend. Pastikan Anda telah menginstal rantai sertifikat lengkap yang terdiri dari Leaf (topmost) > Intermediate(s) > Root. Berdasarkan jenis Otoritas Sertifikat (CA), Anda dapat mengambil tindakan berikut di gateway Anda.

    • CA yang diketahui publik: Jika penerbit sertifikat adalah CA terkenal, Anda tidak perlu mengambil tindakan apa pun di gateway aplikasi.
    • CA Privat: Jika sertifikat daun dikeluarkan oleh CA privat, Anda perlu memeriksa apakah sertifikat CA Akar penandatanganan telah berubah. Dalam kasus seperti itu, Anda harus mengunggah sertifikat OS Akar baru (. CER) ke pengaturan Backend terkait gateway Anda.

  • Sertifikat Menengah atau Akar kedaluwarsa – Biasanya, sertifikat ini memiliki periode validitas yang relatif diperpanjang (satu atau dua dekade). Ketika sertifikat Root/Menengah kedaluwarsa, kami sarankan Anda memeriksa dengan penyedia sertifikat Anda untuk file sertifikat yang diperbarui. Pastikan Anda telah menginstal rantai sertifikat yang diperbarui dan lengkap yang terdiri Leaf (topmost) > Intermediate(s) > Root dari server backend.

    • Jika sertifikat Akar tetap tidak berubah atau jika penerbit adalah CA terkenal, Anda TIDAK perlu mengambil tindakan apa pun di gateway aplikasi.
    • Saat menggunakan CA Privat, jika sertifikat CA Akar itu sendiri atau akar sertifikat Menengah yang diperbarui telah berubah, Anda harus mengunggah sertifikat Akar baru ke Pengaturan Backend gateway aplikasi.

Untuk V1 SKU,

  • Perbarui sertifikat Leaf yang kedaluwarsa (juga dikenal sebagai Domain atau Server) dengan CA Anda dan unggah sertifikat daun yang sama (. CER) ke pengaturan Backend terkait gateway aplikasi Anda.

Sertifikat perantara tidak ditemukan

Pesan: Sertifikat perantara hilang dari rantai sertifikat yang disajikan oleh server backend. Pastikan rantai sertifikat selesai dan diurutkan dengan benar di server backend.

Penyebab: Sertifikat perantara tidak diinstal dalam rantai sertifikat di server backend.

Solusi: Sertifikat perantara digunakan untuk menandatangani sertifikat Leaf dan dengan demikian diperlukan untuk menyelesaikan rantai. Tanyakan kepada Otoritas Sertifikat (CA) Anda untuk sertifikat Perantara yang diperlukan dan instal di server backend Anda. Rantai ini harus dimulai dengan Sertifikat Daun, lalu sertifikat Perantara, dan terakhir, sertifikat OS Akar. Sebaiknya instal rantai yang lengkap di server backend, termasuk sertifikat CA Akar. Sebagai referensi, lihat contoh rantai sertifikat di bawah Daun harus paling atas dalam rantai.

Catatan

Sertifikat yang ditandatangani sendiri yang BUKAN Otoritas Sertifikat juga akan mengakibatkan kesalahan yang sama. Ini karena gateway aplikasi mempertimbangkan sertifikat yang ditandatangani sendiri seperti sertifikat "Leaf" dan mencari sertifikat Menengah penandatanganannya. Anda dapat mengikuti artikel ini untuk membuat sertifikat yang ditandatangani sendiri dengan benar.

Gambar-gambar ini menunjukkan perbedaan antara sertifikat yang ditandatangani sendiri. Screenshot showing difference between self-signed certificates.

Sertifikat daun atau server tidak ditemukan

Pesan: Sertifikat Leaf hilang dari rantai sertifikat yang disajikan oleh server backend. Pastikan rantai selesai dan diurutkan dengan benar di server backend.

Penyebab: Sertifikat Daun (juga dikenal sebagai Domain atau Server) hilang dari rantai sertifikat di server backend.

Solusi: Anda bisa mendapatkan sertifikat daun dari Otoritas Sertifikat (CA) Anda. Instal sertifikat daun ini dan semua sertifikat penandatanganannya (sertifikat OS Akar dan Perantara) di server backend. Rantai ini harus dimulai dengan Sertifikat Daun, lalu sertifikat Perantara, dan terakhir, sertifikat OS Akar. Sebaiknya instal rantai yang lengkap di server backend, termasuk sertifikat CA Akar. Sebagai referensi, lihat contoh rantai sertifikat di bawah Daun harus paling atas dalam rantai.

Sertifikat server tidak dikeluarkan oleh CA yang diketahui publik

Pesan: Sertifikat Server backend tidak ditandatangani oleh Otoritas Sertifikat (CA) terkenal. Untuk menggunakan sertifikat CA yang tidak diketahui, sertifikat Akarnya harus diunggah ke Pengaturan Backend gateway aplikasi.

Penyebab: Anda telah memilih "sertifikat CA terkenal" di pengaturan backend, tetapi sertifikat Akar yang disajikan oleh server backend tidak diketahui secara publik.

Solusi: Ketika sertifikat Leaf dikeluarkan oleh Otoritas Sertifikat (CA) privat, sertifikat CA Akar penandatanganan harus diunggah ke Pengaturan Backend terkait gateway aplikasi. Ini memungkinkan gateway aplikasi Anda untuk membuat koneksi tepercaya dengan server backend tersebut. Untuk memperbaikinya, buka pengaturan backend terkait, pilih "bukan CA yang dikenal" dan unggah sertifikat CA Akar (.CER). Untuk mengidentifikasi dan mengunduh sertifikat akar, Anda dapat mengikuti langkah-langkah yang sama seperti yang dijelaskan di bawah Sertifikat akar tepercaya tidak cocok.

Sertifikat Perantara TIDAK ditandatangani oleh CA yang diketahui publik.

Pesan: Sertifikat perantara tidak ditandatangani oleh Otoritas Sertifikat (CA) terkenal. Pastikan rantai sertifikat selesai dan diurutkan dengan benar di server backend.

Penyebab: Anda telah memilih "sertifikat CA terkenal" di pengaturan backend, tetapi sertifikat Menengah yang disajikan oleh server backend tidak ditandatangani oleh CA yang diketahui publik.

Solusi: Ketika sertifikat dikeluarkan oleh Otoritas Sertifikat (CA) privat, sertifikat CA Akar penandatanganan harus diunggah ke Pengaturan Backend terkait gateway aplikasi. Ini memungkinkan gateway aplikasi Anda untuk membuat koneksi tepercaya dengan server backend tersebut. Untuk memperbaikinya, hubungi CA privat Anda untuk mendapatkan sertifikat CA Akar yang sesuai (. CER) dan unggah bahwa . File CER ke Pengaturan Backend gateway aplikasi Anda dengan memilih "bukan CA terkenal". Kami juga merekomendasikan menginstal rantai yang lengkap di server backend, termasuk sertifikat OS Akar,untuk verifikasi yang mudah.

Sertifikat akar tepercaya tidak cocok (tidak ada sertifikat Akar di server backend)

Pesan: Sertifikat menengah tidak ditandatangani oleh sertifikat Akar apa pun yang diunggah ke gateway aplikasi. Pastikan rantai sertifikat selesai dan diurutkan dengan benar di server backend.

Menyebabkan: Tidak ada sertifikat OS Akar yang diunggah ke Pengaturan Backend terkait yang telah menandatangani sertifikat Menengah yang diinstal pada server backend. Server backend hanya menginstal sertifikat Leaf dan Menengah.

Solusi: Sertifikat Leaf ditandatangani oleh sertifikat Menengah, yang ditandatangani oleh sertifikat CA Akar. Saat menggunakan sertifikat dari Otoritas Sertifikat (CA) Privat, Anda harus mengunggah sertifikat CA Akar yang sesuai ke gateway aplikasi. Hubungi CA privat Anda untuk mendapatkan sertifikat CA Akar (.CER) yang sesuai dan unggah file CER tersebut ke pengaturan Backend gateway aplikasi Anda.

Ketidakcocokan sertifikat akar tepercaya (Sertifikat akar tersedia di server backend)

Pesan: Sertifikat akar sertifikat server yang digunakan oleh backend tidak cocok dengan sertifikat akar tepercaya yang ditambahkan ke gateway aplikasi. Pastikan Anda menambahkan sertifikat akar yang benar untuk mengizinkan daftar backend.

Penyebab: Kesalahan ini terjadi ketika sertifikat Akar yang diunggah ke pengaturan backend gateway aplikasi Anda tidak ada yang cocok dengan sertifikat Akar yang ada di server backend.

Solusi: Ini berlaku untuk sertifikat server backend yang dikeluarkan oleh Otoritas Sertifikat Privat (CA) atau merupakan sertifikat yang ditandatangani sendiri. Identifikasi dan unggah sertifikat OS Akar yang benar ke pengaturan backend terkait.

Tips: Untuk mengidentifikasi dan mengunduh sertifikat akar, Anda dapat menggunakan salah satu metode ini.

  • Menggunakan browser: Akses server backend secara langsung (bukan melalui Application Gateway) dan klik gembok sertifikat di bilah alamat untuk melihat detail sertifikat.

    1. Pilih sertifikat akar dalam rantai dan klik Ekspor. Secara default, ini akan menjadi . File CRT.
    2. Buka bahwa . File CRT.
    3. Buka tab Detail dan klik "Salin ke File",
    4. Pada halaman Wizard Ekspor Sertifikat, klik Berikutnya,
    5. Pilih "Base-64 encoded X.509 (. CER) dan klik Berikutnya,
    6. Beri nama file baru dan klik Berikutnya,
    7. Klik Selesai untuk mendapatkan . File CER.
    8. Unggah sertifikat Akar ini (. CER) dari CA privat Anda ke pengaturan backend gateway aplikasi.

  • Dengan masuk ke server backend (Windows)

    1. Masuk ke komputer tempat aplikasi Anda dihosting.
    2. Pilih Win+R atau klik kanan tombol Mulai, lalu pilih Jalankan.
    3. Masukkan certlm.msc dan pilih Enter. Anda juga dapat mencari Pengelola Sertifikat pada menu Mulai.
    4. Temukan sertifikat, biasanya di Sertifikat - Komputer Lokal\Pribadi\Sertifikat, dan buka.
    5. Pilih sertifikat akar dan klik Lihat Sertifikat.
    6. Di properti Sertifikat, pilih tab Detail dan klik "Salin ke File",
    7. Pada halaman Wizard Ekspor Sertifikat, klik Berikutnya,
    8. Pilih "Base-64 encoded X.509 (. CER) dan klik Berikutnya,
    9. Beri nama file baru dan klik Berikutnya,
    10. Klik Selesai untuk mendapatkan . File CER.
    11. Unggah sertifikat Akar ini (. CER) dari CA privat Anda ke pengaturan backend gateway aplikasi.

Daun harus paling atas dalam rantai.

Pesan: Sertifikat Leaf bukan sertifikat paling atas dalam rantai yang disajikan oleh server backend. Pastikan rantai sertifikat diurutkan dengan benar di server backend.

Penyebab: Sertifikat Leaf (juga dikenal sebagai Domain atau Server) tidak diinstal dalam urutan yang benar di server backend.

Solusi: Penginstalan sertifikat di server backend harus menyertakan daftar sertifikat yang diurutkan yang terdiri dari sertifikat daun dan semua sertifikat penandatanganannya (sertifikat OS Menengah dan Root). Rantai ini harus dimulai dengan sertifikat daun, lalu sertifikat Menengah, dan terakhir, sertifikat CA Akar. Sebaiknya instal rantai yang lengkap di server backend, termasuk sertifikat CA Akar.

Mengingat adalah contoh penginstalan sertifikat Server bersama dengan sertifikat OS Menengah dan Akarnya, ditandai sebagai kedalaman (0, 1, 2, dan sebagainya) di OpenSSL. Anda dapat memverifikasi hal yang sama untuk sertifikat server backend Anda menggunakan perintah OpenSSL berikut.
s_client -connect <FQDN>:443 -showcerts
OR
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

Screenshot showing typical chain of certificates.

Verifikasi sertifikat gagal

Pesan Validitas sertifikat backend tidak dapat diverifikasi. Untuk mengetahui alasannya, centang diagnostik OpenSSL untuk pesan yang terkait dengan kode kesalahan {errorCode}

Penyebab: Kesalahan ini terjadi ketika Application Gateway tidak dapat memverifikasi validitas sertifikat.

Solusi: Untuk mengatasi masalah ini, pastikan bahwa sertifikat pada server Anda dibuat dengan benar. Misalnya, Anda dapat menggunakan OpenSSL untuk memverifikasi sertifikat dan propertinya lalu mencoba memuat ulang sertifikat ke pengaturan HTTP Application Gateway.

Status kesehatan backend: Tidak diketahui

Pembaruan ke entri DNS dari kumpulan backend

Pesan: Status kesehatan ujung belakang tidak dapat diambil. Hal ini terjadi ketika NSG/UDR/Firewall pada subnet gateway aplikasi memblokir lalu lintas pada port 65503-65534 dalam kasus v1 SKU, dan port 65200-65535 dalam kasus v2 SKU atau jika FQDN yang dikonfigurasi di kumpulan ujung belakang tidak dapat diselesaikan ke alamat IP. Untuk mempelajari lebih lanjut kunjungi - https://aka.ms/UnknownBackendHealth.

Penyebab: Untuk target backend berbasis FQDN (Nama Domain yang Sepenuhnya Memenuhi Syarat), Application Gateway menyimpan cache dan menggunakan alamat IP terakhir yang diketahui baik jika gagal mendapatkan respons untuk pencarian DNS berikutnya. Operasi PUT pada gateway dalam status ini akan menghapus cache DNS-nya sama sekali. Akibatnya, tidak akan ada alamat tujuan apa pun yang dapat dijangkau gateway.

Resolusi: Periksa dan perbaiki server DNS untuk memastikan server DNS melayani respons untuk pencarian DNS FDQN yang diberikan. Anda juga harus memeriksa apakah server DNS dapat dijangkau melalui Virtual Network gateway aplikasi Anda.

Alasan lain

Jika status kesehatan backend Tidak Sehat, tampilan portal akan menyerupai cuplikan layar berikut:

Application Gateway backend health - Unknown

Perilaku ini dapat terjadi karena satu atau beberapa alasan berikut:

  1. NSG di subnet Application Gateway memblokir akses masuk ke port 65503-65534 (SKU v1) atau 65200-65535 (SKU v2) dari “Internet.”
  2. UDR pada subnet Application Gateway diatur ke rute default (0.0.0.0/0) dan hop berikutnya tidak ditentukan sebagai "Internet."
  3. Rute default diiklankan oleh koneksi ExpressRoute/VPN ke jaringan virtual Anda melalui BGP.
  4. Server DNS kustom dikonfigurasi di jaringan virtual yang tidak dapat mengatasi nama domain publik.
  5. Application Gateway berada dalam status Tidak Baik.

Solusi:

  1. Periksa apakah NSG Anda memblokir akses ke port 65503-65534 (SKU v1) atau 65200-65535 (SKU v2) dari Internet:

    a. Pada tab Gambaran Umum Application Gateway, pilih tautan Virtual Network/Subnet. b. Pada tab Subnet jaringan virtual Anda, pilih subnet tempat Application Gateway disebarkan. c. Periksa apakah ada NSG yang terkonfigurasi. d. Jika NSG terkonfigurasi, cari sumber daya NSG tersebut pada tab Pencarian atau di bawah Semua sumber daya. e. Di bagian Aturan Masuk, tambahkan aturan masuk untuk mengizinkan rentang port tujuan 65503-65534 untuk SKU v1 atau SKU 65200-65535 v2 dengan Sumber ditetapkan sebagai tag layanan GatewayManager . f. Pilih Simpan dan verifikasi bahwa Anda dapat melihat backend sebagai Sehat. Atau, Anda dapat melakukannya melalui PowerShell/CLI.

  2. Periksa apakah UDR Anda memiliki rute default (0.0.0.0/0) dengan hop berikutnya yang tidak ditetapkan sebagai Internet:

    a. Ikuti langkah 1a dan 1b untuk menentukan subnet Anda. b. Periksa untuk melihat apakah UDR dikonfigurasi. Jika ada, cari sumber daya di bilah pencarian atau di bawah Semua sumber daya. c. Periksa untuk melihat apakah ada rute default (0.0.0.0/0) dengan hop berikutnya yang tidak ditetapkan sebagai Internet. Jika pengaturannya adalah Virtual Appliance atau Virtual Network Gateway, Anda harus memastikan bahwa appliance virtual Anda, atau perangkat lokal, dapat merutekan paket kembali ke tujuan Internet dengan benar tanpa memodifikasi paket. Jika pemeriksaan dirutekan melalui appliance virtual dan dimodifikasi, sumber daya backend akan menampilkan kode status 200 dan status kesehatan Application Gateway dapat ditampilkan sebagai Tidak Diketahui. Ini tidak menunjukkan kesalahan. Lalu lintas masih harus merutekan melalui Application Gateway tanpa masalah. d. Jika tidak, ubah hop berikutnya ke Internet, pilihSimpan, dan verifikasi kesehatan backend.

  3. Rute default yang diiklankan oleh koneksi ExpressRoute/VPN ke jaringan virtual melalui BGP (Border Gateway Protocol):

    a. Jika Anda memiliki koneksi ExpressRoute/VPN ke jaringan virtual melalui BGP, dan jika Anda mengiklankan rute default, Anda harus memastikan bahwa paket dirutekan kembali ke tujuan internet tanpa memodifikasinya. Anda dapat memverifikasi dengan menggunakan opsi Pemecahan Masalah Koneksi di portal Application Gateway. b. Pilih tujuan secara manual sebagai alamat IP yang dapat di-rutekan ke internet seperti 1.1.1.1. Atur port tujuan sebagai apa pun, dan verifikasi konektivitas. c. Jika hop berikutnya adalah gateway jaringan virtual, mungkin ada rute default yang diiklankan melalui ExpressRoute atau VPN.

  4. Jika ada server DNS kustom yang dikonfigurasi di jaringan virtual, verifikasi bahwa server dapat menyelesaikan domain publik. Resolusi nama domain publik mungkin diperlukan dalam skenario di mana Application Gateway harus menjangkau domain eksternal seperti server OCSP (Protokol Status Sertifikat Online) atau untuk memeriksa status pencabutan sertifikat.

  5. Untuk memverifikasi bahwa Application Gateway sehat dan berjalan, buka opsi Kesehatan Sumber Daya di portal, dan verifikasi bahwa statusnya Sehat. Jika Anda melihat status Tidak Sehat atau Terdegradasi, hubungi dukungan.

  6. Jika Internet dan lalu lintas privat melalui Azure Firewall yang dihosting di hub Virtual aman (menggunakan Azure Virtual WAN Hub):

    a. Untuk memastikan gateway aplikasi dapat mengirim lalu lintas langsung ke Internet, konfigurasikan rute yang ditentukan pengguna berikut:

    Prefiks alamat : 0.0.0.0/0
    Hop berikutnya: Internet

    b. Untuk memastikan gateway aplikasi dapat mengirim lalu lintas ke kumpulan backend melalui Azure Firewall di hub Virtual WAN, konfigurasikan rute yang ditentukan pengguna berikut:

    Awalan Alamat: Subnet kumpulan backend
    Hop berikutnya: Alamat IP privat Azure Firewall

Langkah berikutnya

Pelajari selengkapnya tentang diagnostik dan pembuatan log Application Gateway.