Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Pengaturan Backend memungkinkan Anda mengelola konfigurasi untuk koneksi backend yang dibuat dari sumber daya gateway aplikasi ke server di kumpulan backend. Konfigurasi Pengaturan Backend dapat dikaitkan dengan satu atau beberapa aturan Perutean.
Jenis Pengaturan Backend di Application Gateway
Meskipun pengguna Portal hanya melihat opsi "Pengaturan Backend", pengguna API memiliki akses ke dua jenis pengaturan. Anda harus menggunakan konfigurasi yang benar, sesuai dengan protokol.
- Pengaturan HTTP backend - Untuk konfigurasi proksi layer 7 yang mendukung protokol HTTP dan HTTPS.
- Pengaturan Backend - Ini ditujukan untuk konfigurasi proksi Lapisan 4 (Pratinjau) yang mendukung protokol TLS dan TCP.
Afinitas berbasis Cookie
Azure Application Gateway menggunakan cookie yang dikelola gateway untuk mempertahankan sesi pengguna. Saat pengguna mengirim permintaan pertama ke Application Gateway, pengguna menetapkan cookie afinitas dalam respons dengan nilai hash yang berisi detail sesi. Proses ini memungkinkan permintaan berikutnya yang membawa cookie afinitas untuk dirutekan ke server backend yang sama, sehingga mempertahankan kelekatan.
Fitur ini berguna ketika Anda ingin mempertahankan sesi pengguna di server yang sama dan ketika status sesi disimpan secara lokal di server untuk sesi pengguna. Jika aplikasi tidak dapat menangani afinitas berbasis cookie, Anda tidak dapat menggunakan fitur ini. Untuk menggunakannya, pastikan bahwa klien mendukung cookie.
Catatan
Beberapa pemindaian kerentanan dapat menandai cookie afinitas Application Gateway karena penanda Secure atau HttpOnly tidak diatur. Pemindaian ini tidak memperhitungkan bahwa data dalam cookie dihasilkan menggunakan hash satu arah. Cookie tidak berisi informasi pengguna apa pun dan digunakan murni untuk perutean.
Pembaruan Chromium browserv80 membawa mandat di mana cookie HTTP tanpa atribut SameSite harus diperlakukan sebagai SameSite=Lax. Untuk permintaan CORS (Berbagi Sumber Daya Lintas Asal), jika cookie harus dikirim dalam konteks pihak ketiga, cookie harus menggunakan SameSite=None; Atribut aman dan harus dikirim melalui HTTPS saja. Jika tidak, dalam skenario HTTP saja, browser tidak mengirim cookies pada konteks pihak ketiga. Tujuan pembaruan dari Chrome ini adalah untuk meningkatkan keamanan dan menghindari serangan Cross-Site Request Forgery (CSRF).
Untuk mendukung perubahan ini, mulai 17 Februari 2020, Application Gateway (semua jenis SKU) akan menyuntikkan cookie lain yang disebut ApplicationGatewayAffinityCORS sebagai tambahan cookie ApplicationGatewayAffinity yang ada. Cookie ApplicationGatewayAffinityCORS memiliki dua atribut lagi yang ditambahkan ("SameSite=None; Secure") sehingga sesi persisten dipertahankan bahkan untuk permintaan lintas asal.
Nama cookie afinitas default adalah ApplicationGatewayAffinity dan Anda dapat mengubahnya. Jika dalam topologi jaringan Anda, Anda menyebarkan beberapa gateway aplikasi dalam satu jalur, Anda harus mengatur nama cookie unik untuk setiap sumber daya. Jika Anda menggunakan nama cookie afinitas kustom, cookie lain ditambahkan dengan CORS sebagai akhiran. Misalnya: CustomCookieNameCORS.
Catatan
Jika atribut SameSite=None diatur, maka cookie wajib menyertakan flag Secure dan harus dikirim melalui HTTPS. Jika afinitas sesi diperlukan melalui CORS, Anda harus memigrasikan beban kerja Anda ke HTTPS. Lihat dokumentasi TLS offload dan End-to-End TLS untuk Application Gateway. Lihat gambaran umum SSL, Konfigurasikan gateway aplikasi dengan penghentian TLS, dan Konfigurasikan TLS end-to-end.
Pengurangan koneksi bertahap
Pemutusan koneksi bertahap membantu Anda menghapus anggota kumpulan backend secara lancar selama pembaruan layanan terencana, penyebaran bergulir, penyempitan skala, atau pembaruan konfigurasi gateway. Gunakan _connection draining_ untuk mengurangi kesalahan 502 intermiten dan kehilangan koneksi saat instance backend dihapus secara eksplisit dari kumpulan backend.
Anda dapat menerapkan pengaturan ini ke semua anggota kumpulan backend dengan mengaktifkan Pengurasan Koneksi di Pengaturan Backend. Ini memastikan bahwa semua instans yang membatalkan pendaftaran di kumpulan backend tidak menerima permintaan/koneksi baru sambil mempertahankan koneksi yang ada hingga nilai batas waktu yang dikonfigurasi. Proses ini juga berlaku untuk koneksi WebSocket.
| Jenis Konfigurasi | Nilai |
|---|---|
| Nilai default saat Pengurasan Koneksi tidak diaktifkan di Pengaturan Backend | 30 detik |
| Nilai yang ditentukan pengguna saat Pengurasan Koneksi diaktifkan di Pengaturan Backend | 1 hingga 3.600 detik |
Satu-satunya pengecualian untuk proses ini adalah permintaan yang ditujukan untuk instans yang dibatalkan pendaftarannya karena afinitas sesi yang diatur oleh gateway. Permintaan ini terus diteruskan ke instans yang membatalkan pendaftaran.
Catatan
Ada batasan di mana pembaruan konfigurasi akan mengakhiri koneksi yang sedang berlangsung setelah batas waktu pengurasan koneksi. Untuk mengatasi batasan ini, Anda harus meningkatkan batas waktu pengurasan koneksi di pengaturan backend ke nilai yang lebih tinggi dari waktu pengunduhan klien maksimum yang diharapkan.
Untuk memperbarui batas waktu pengurasan koneksi dengan Azure CLI, jalankan az network application-gateway http-settings update dan atur --connection-draining-timeout pada pengaturan HTTP backend. Nilai 0 menonaktifkan pengurasan koneksi, dan nilai dari 1 hingga 3.600 detik mengaktifkannya.
Catatan
Jika Anda mengalami error 502 yang muncul sesekali selama penerapan, pembaruan bergulir, atau peristiwa pengurangan skala, waktu tunggu pengosongan koneksi mungkin terlalu singkat. Tingkatkan --connection-draining-timeout ke nilai yang lebih besar dari waktu transfer klien maksimum yang diharapkan.
Protokol
Application Gateway mendukung HTTP dan HTTPS untuk merutekan permintaan ke server backend. Jika Anda memilih HTTP, lalu lintas ke server backend tidak terenkripsi. Jika komunikasi tidak terenkripsi tidak dapat diterima, pilih HTTPS.
Pengaturan ini dikombinasikan dengan HTTPS di pendengar mendukung TLS ujung ke ujung. Ini memungkinkan Anda untuk mengirimkan data sensitif secara aman yang dienkripsi ke ujung belakang. Setiap server backend di kumpulan backend yang mengaktifkan TLS end-to-end harus dikonfigurasi dengan sertifikat untuk memungkinkan komunikasi yang aman.
Pelabuhan
Pengaturan ini menentukan port tempat server backend mendengarkan lalu lintas dari gateway aplikasi. Anda dapat mengonfigurasi port mulai dari 1 hingga 65535.
Sertifikat root tepercaya
Ketika protokol HTTPS dipilih di pengaturan backend, sumber daya gateway aplikasi menggunakan penyimpanan sertifikat CA Akar Tepercaya defaultnya untuk memverifikasi rantai dan keaslian sertifikat yang disediakan oleh server backend.
Secara default, sumber daya Application Gateway menyertakan sertifikat CA populer, memungkinkan koneksi TLS backend yang mulus saat sertifikat server backend dikeluarkan oleh CA Publik. Namun, jika Anda ingin menggunakan CA Privat atau sertifikat yang dibuat sendiri dengan validasi TLS lengkap, Anda harus memberikan sertifikat CA Akar (.cer) yang sesuai dalam konfigurasi Pengaturan Backend.
Pengaturan validasi HTTPS backend
Saat HTTPS dipilih di Pengaturan Backend Azure Application Gateway, gateway melakukan validasi jabat tangan TLS lengkap sambil membuat koneksi aman dengan server backend. Validasi ini meliputi:
- Memverifikasi rantai sertifikat untuk memastikan sertifikat tepercaya.
- Memverifikasi Nama Subjek sertifikat terhadap Indikasi Nama Server (SNI) yang dikirim oleh Application Gateway.
- Memverifikasi kedaluwarsa sertifikat untuk mengonfirmasi apakah sertifikat masih valid.
Pengaturan validasi default memastikan komunikasi TLS yang aman antara gateway dan layanan backend. Dalam skenario tertentu, perlu untuk menyesuaikan satu atau beberapa pengaturan validasi ini. Untuk mengakomodasi beragam persyaratan pelanggan, Application Gateway menawarkan opsi yang dapat dikonfigurasi berikut. Anda dapat menggunakan salah satu atau kedua opsi sesuai kebutuhan.
| Karakteristik | Nilai |
|---|---|
| validateCertChainAndExpiry | Jenis: Boolean (benar atau salah). Pengaturan default adalah true. Ini memverifikasi atau melewati pemeriksaan rantai sertifikat dan verifikasi tanggal kedaluwarsa. |
| validateSNI | Jenis: Boolean (benar atau salah). Pengaturan default adalah true. Ini memverifikasi apakah Nama Umum sertifikat yang disediakan oleh server backend cocok dengan nilai Indikasi Nama Server (SNI) yang dikirim oleh Application Gateway. |
| sniName | Tipe: String. Properti ini hanya diperlukan ketika validateSNI diatur sebagai true. Anda dapat menentukan nilai SNI agar sesuai dengan nama umum sertifikat pada backend. Secara default, gateway aplikasi menggunakan header host permintaan masuk sebagai SNI. |
Catatan
- Kami menyarankan untuk tetap mengaktifkan semua validasi di lingkungan produksi. Menonaktifkan beberapa atau semua validasi disarankan hanya untuk tujuan pengujian dan pengembangan, seperti ketika sertifikat yang ditandatangani sendiri digunakan.
- Pengaturan ini tidak berlaku untuk fungsionalitas probe pengujian saat menambahkan Health Probe kustom. Akibatnya, Anda dapat melihat perbedaan dalam hasil saat membandingkan dengan pemeriksaan kesehatan berkala.
- Saat ini, tidak didukung untuk proksi TLS.
- PowerShell dan CLI akan segera didukung.
Batas waktu permintaan habis
Pengaturan ini adalah jumlah detik gateway aplikasi menunggu untuk menerima respons dari server backend. Nilai defaultnya adalah 20 detik. Namun, Anda dapat menyesuaikan pengaturan ini dengan kebutuhan aplikasi Anda. Nilai yang dapat diterima adalah dari 1 detik hingga 86400 detik (24 jam).
Ambil alih jalur backend
Pengaturan ini memungkinkan Anda mengonfigurasi jalur penerusan kustom opsional untuk digunakan saat permintaan diteruskan ke back end. Setiap bagian dari jalur masuk yang cocok dengan jalur kustom di bidang jalur ujung belakang override disalin ke jalur yang diteruskan. Tabel berikut ini memperlihatkan cara kerja fitur ini:
Ketika pengaturan HTTP dilampirkan ke aturan permintaan perutean dasar:
Permintaan asli Ambil alih jalur backend Permintaan diteruskan ke back-end /rumah/ /Menggantikan/ /override/home/ /home/secondhome/ /Menggantikan/ /override/home/secondhome/ Ketika pengaturan HTTP ditempelkan pada aturan perutean permintaan berbasis jalur:
Permintaan asli Aturan jalur Ambil alih jalur backend Permintaan diteruskan ke back-end /pathrule/home/ /pathrule* /Menggantikan/ /override/home/ /pathrule/home/secondhome/ /pathrule* /Menggantikan/ /override/home/secondhome/ /rumah/ /pathrule* /Menggantikan/ /override/home/ /home/secondhome/ /pathrule* /Menggantikan/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /Menggantikan/ /Menggantikan/ /pathrule/home/secondhome/ /pathrule/home* /Menggantikan/ /override/rumahkedua/ /pathrule/ /pathrule/ /Menggantikan/ /Menggantikan/
Menggunakan pengujian khusus
Pengaturan ini mengaitkan pemeriksaan kustom dengan pengaturan HTTP. Anda hanya dapat mengaitkan satu probe kustom dengan pengaturan HTTP. Jika Anda tidak secara eksplisit mengaitkan probe kustom, probe default digunakan untuk memantau kesehatan backend. Kami menyarankan agar Anda membuat alat uji kustom untuk kendali yang lebih baik atas pemantauan kesehatan lapisan belakang Anda.
Catatan
Pengujian kustom tidak memantau kesehatan kumpulan backend kecuali pengaturan HTTP yang bersangkutan secara eksplisit dihubungkan dengan pendengar.
Mengonfigurasi nama host
Application Gateway memungkinkan koneksi yang dibuat ke backend untuk menggunakan nama host yang berbeda dari yang digunakan oleh klien untuk menyambungkan ke Application Gateway. Meskipun konfigurasi ini dapat berguna dalam beberapa kasus, berhati-hatilah saat mengganti nama host sehingga sekarang berbeda antara gateway aplikasi dan klien dibandingkan dengan target backend.
Di lingkungan produksi, ini adalah praktik terbaik untuk menggunakan nama host yang sama bagi klien ke koneksi gateway aplikasi dan gateway aplikasi ke koneksi target backend. Praktik ini menghindari potensi masalah dengan URL absolut, URL pengalihan, dan cookie yang terikat host.
Sebelum menyiapkan Application Gateway yang menyimpang dari ini, tinjau implikasi konfigurasi tersebut seperti yang dibahas secara lebih rinci di Pusat Arsitektur: Mempertahankan nama host HTTP asli antara proksi terbalik dan aplikasi web backend-nya
Ada dua aspek pengaturan HTTP yang memengaruhi Host header HTTP yang digunakan oleh Application Gateway untuk menyambungkan ke backend:
- "Pilih nama host dari alamat backend"
- Penggantian nama host
Pilih nama host dari alamat backend
Kemampuan ini secara dinamis mengatur header host dalam permintaan agar sesuai dengan nama host dari kumpulan backend. Ini menggunakan alamat IP atau FQDN.
Fitur ini berguna ketika nama domain dari latar belakang berbeda dari nama DNS gateway aplikasi, dan latar belakang bergantung pada header host tertentu untuk mengarahkan ke titik akhir yang benar.
Contoh kasus adalah layanan multi-penyewa sebagai pemrosesan belakang. Layanan aplikasi adalah layanan multipenyewa yang menggunakan ruang bersama dengan satu alamat IP. Jadi, layanan aplikasi hanya dapat diakses melalui nama host yang dikonfigurasi di pengaturan domain kustom.
Secara default, nama domain kustom example.azurewebsites.net. Untuk mengakses layanan aplikasi Anda dengan menggunakan gateway aplikasi melalui nama host yang tidak terdaftar secara eksplisit di layanan aplikasi atau melalui FQDN (Fully Qualified Domain Name) dari gateway aplikasi, Anda dapat mengganti nama host dalam permintaan asli dengan nama host layanan aplikasi. Untuk melakukan ini, aktifkan pengaturan pilih nama host dari alamat backend.
Untuk domain kustom yang nama DNS kustom yang sudah ada dipetakan ke layanan aplikasi, konfigurasi yang direkomendasikan bukan untuk mengaktifkan memilih nama host dari alamat backend.
Catatan
Pengaturan ini tidak diperlukan untuk App Service Environment, yang merupakan penyebaran khusus.
Penggantian nama host
Kemampuan ini menggantikan header host dalam permintaan masuk pada gateway aplikasi dengan nama host yang Anda tentukan.
Misalnya, jika www.contoso.com ditentukan dalam pengaturan Nama host , permintaan asli *https://appgw.eastus.cloudapp.azure.com/path1 diubah menjadi *https://www.contoso.com/path1 ketika permintaan diteruskan ke server backend.
Koneksi Backend Khusus
Azure Application Gateway, secara default, menggunakan ulang sambungan backend tidak aktif untuk mengoptimalkan penggunaan sumber daya sambungan TCP untuk Application Gateway dan server backend. Untuk mendukung fungsi keamanan di jalur data pelanggan yang mengharuskan koneksi backend unik per klien, Azure Application Gateway V2 menyediakan koneksi khusus ke server backend.
Kemampuan ini menetapkan pemetaan langsung satu-ke-satu antara koneksi frontend dan backend, memastikan konektivitas persisten untuk setiap klien individu.
Penting
Tinjau pertimbangan berikut sebelum Anda mengaktifkan Koneksi Backend Khusus di Application Gateway:
- Dukungan NTLM/Kerberos: Autentikasi passthrough NTLM dan Kerberos memerlukan pemetaan satu-ke-satu antara koneksi frontend dan backend untuk mempertahankan integritas sesi. Aktifkan Koneksi Backend Khusus untuk mendukung protokol ini.
- Klien warisan: Klien warisan seperti MSIE6 atau aplikasi yang menggunakan tanda tangan Agen Pengguna yang lebih lama tidak dapat sepenuhnya mendukung fitur HTTP modern dan perilaku manajemen koneksi. Untuk meningkatkan keandalan dan membantu mencegah masalah seperti respons yang tidak lengkap atau rusak, Azure Application Gateway menerapkan penanganan kompatibilitas tambahan secara default. Ketika fitur Koneksi Backend Khusus diaktifkan, penanganan kompatibilitas ini dapat mengakibatkan perbedaan perilaku koneksi untuk klien warisan dengan NTLM, yang berpotensi menyebabkan inkonsistensi konektivitas. Untuk keandalan optimal dan perilaku yang dapat diprediksi, disarankan untuk menggunakan klien modern yang sesuai standar atau meningkatkan klien warisan jika memungkinkan.
- Perencanaan kapasitas: Koneksi backend khusus menyebabkan peningkatan jumlah koneksi backend dan karenanya dapat memerlukan lebih banyak sumber daya untuk mendukung peningkatan koneksi bersamaan di Application Gateway dan server backend. Di Application Gateway, tingkatkan jumlah instans atau aktifkan skala otomatis untuk mengakomodasi beban.
- Konsumsi port SNAT: Ketika backend adalah server jarak jauh, setiap koneksi klien menggunakan port SNAT khusus, yang meningkatkan risiko kelelahan port SNAT. Untuk panduan, lihat praktik terbaik arsitektur.
- Dukungan protokol: Koneksi Backend Khusus tidak didukung dengan HTTP/2.
Pemecahan Masalah Kesalahan 4xx dengan Koneksi Backend Khusus
Ketika Koneksi Backend Khusus diaktifkan dalam pengaturan backend dan aplikasi backend mengembalikan kode status 4xx, gunakan panduan berikut untuk mendiagnosis dan menyelesaikan masalah tersebut.
Verifikasi Konfigurasi Nama Prinsipal Layanan (SPN) - Mekanisme autentikasi seperti NTLM dan Kerberos memerlukan nama perwakilan layanan yang terdaftar dengan benar. Pastikan SPN dikonfigurasi dengan benar dan unik dalam direktori untuk memungkinkan autentikasi yang berhasil. Untuk informasi selengkapnya, lihat dokumentasi Kerberos.
Tinjau Log Server Backend untuk Kode Sub-Status - Application Gateway hanya menampilkan status HTTP utama (misalnya, 401 Unauthorized). Untuk mengidentifikasi penyebab yang mendasar, tinjau log server backend untuk informasi substatus yang lebih rinci. Untuk panduan, lihat konfigurasi Autentikasi Windows.