Konfigurasi pengaturan HTTP Azure Application Gateway
Gateway aplikasi merutekan lalu lintas ke server backend dengan menggunakan konfigurasi yang Anda tentukan di sini. Setelah Anda membuat pengaturan HTTP, Anda harus mengaitkannya dengan satu atau beberapa aturan permintaan perutean.
Afinitas berbasis Cookie
Azure Application Gateway menggunakan cookie yang dikelola gateway untuk mempertahankan sesi pengguna. Ketika pengguna mengirim permintaan pertama ke Application Gateway, ia menetapkan cookie afinitas sebagai respons dengan nilai hash yang berisi detail sesi, sehingga permintaan berikutnya yang membawa cookie afinitas akan dirutekan ke server ujung belakang yang sama untuk 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 bendera Aman 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 cookie dalam 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 ke dalamnya ("SameSite=None; Aman") sehingga sesi lengket dipertahankan bahkan untuk permintaan lintas asal.
Perhatikan bahwa nama cookie afinitas default adalah ApplicationGatewayAffinity dan Anda dapat mengubahnya. Jika Anda menggunakan nama cookie afinitas kustom, cookie tambahan ditambahkan dengan CORS sebagai akhiran. Misalnya, CustomCookieNameCORS.
Catatan
Jika atribut SameSite=None diatur, maka wajib bahwa cookie juga berisi bendera Aman, dan harus dikirim melalui HTTPS. Jika afinitas sesi diperlukan melalui CORS, Anda harus memigrasikan beban kerja Anda ke HTTPS. Silakan lihat offload TLS dan dokumentasi TLS Ujung ke Ujung untuk Application Gateway di sini – Ringkasan, Konfigurasikan gateway aplikasi dengan penghentian TLS menggunakan portal Microsoft Azure, Konfigurasikan TLS ujung ke ujung dengan menggunakan Application Gateway dengan portal.
Pengurasan koneksi
pengurasan Koneksi ion membantu Anda menghapus anggota kumpulan backend dengan anggun selama pembaruan layanan yang direncanakan. Ini berlaku untuk instans backend yang
- secara eksplisit dihapus dari kumpulan backend,
- dihapus selama operasi penyempurnaan skala, atau
- dilaporkan tidak sehat oleh pemeriksaan kesehatan.
Anda dapat menerapkan pengaturan ini ke semua anggota kumpulan backend dengan mengaktifkan pengurasan Koneksi ion 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. Ini juga berlaku untuk koneksi WebSocket.
| Jenis Konfigurasi | Nilai |
|---|---|
| Nilai default saat pengurasan Koneksi ion tidak diaktifkan di Pengaturan Backend | 30 detik |
| Nilai yang ditentukan pengguna saat pengurasan Koneksi ion diaktifkan di Pengaturan Backend | 1 hingga 3600 detik |
Satu-satunya pengecualian untuk ini adalah permintaan yang terikat untuk membatalkan pendaftaran instans karena afinitas sesi yang dikelola gateway dan akan terus diteruskan ke instans yang membatalkan pendaftaran.
Protokol
Application Gateway mendukung HTTP dan HTTPS untuk permintaan perutean 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.
Port
Pengaturan ini menentukan port tempat server backend mendengarkan lalu lintas dari gateway aplikasi. Anda dapat mengonfigurasi port mulai dari 1 hingga 65535.
Sertifikat akar tepercaya
Jika Anda memilih HTTPS sebagai protokol backend, Application Gateway memerlukan sertifikat akar tepercaya untuk mempercayai kumpulan backend untuk SSL end-to-end. Secara default, opsi Gunakan sertifikat CA terkenal diatur ke Tidak. Jika Anda berencana untuk menggunakan sertifikat yang ditandatangani sendiri, atau sertifikat yang ditandatangani oleh Otoritas Sertifikat internal, maka Anda harus memberikan Application Gateway sertifikat publik yang cocok yang akan digunakan oleh kumpulan backend. Sertifikat ini harus diunggah langsung ke Application Gateway di . Format CER.
Jika Anda berencana untuk menggunakan sertifikat pada kumpulan backend yang ditandatangani oleh Otoritas Sertifikat publik tepercaya, maka Anda dapat mengatur opsi Gunakan sertifikat CA terkenal ke Ya dan melewati pengunggahan sertifikat publik.
Waktu permintaan habis
Pengaturan ini adalah jumlah detik gateway aplikasi menunggu untuk menerima respons dari server backend.
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 dasar permintaan perutean:
Permintaan asli Ambil alih jalur backend Permintaan diteruskan ke ujung belakang /home/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ Ketika pengaturan HTTP dilampirkan ke aturan dasar permintaan perutean:
Permintaan asli Aturan jalur Ambil alih jalur backend Permintaan diteruskan ke ujung belakang /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /home/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /override/ /override/ /pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/ /pathrule/ /pathrule/ /override/ /override/
Menggunakan pemeriksaan kustom
Pengaturan ini mengaitkan pemeriksaan kustom dengan pengaturan HTTP. Anda hanya dapat mengaitkan satu pemeriksaan kustom dengan pengaturan HTTP. Jika Anda tidak secara eksplisit mengaitkan pemeriksaan kustom, pemeriksaan default digunakan untuk memantau kesehatan ujung belakang. Kami menyarankan agar Anda membuat pemeriksaan kustom untuk kontrol yang lebih besar atas pemantauan kesehatan ujung belakang Anda.
Catatan
Pemeriksaan kustom tidak memantau kesehatan kumpulan backend kecuali pengaturan HTTP yang sesuai secara eksplisit terkait 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, mengganti nama host agar berbeda antara klien dan gateway aplikasi dan gateway aplikasi ke target backend, harus dilakukan dengan hati-hati.
Dalam produksi, disarankan untuk menyimpan nama host yang digunakan oleh klien menuju gateway aplikasi sebagai nama host yang sama yang digunakan oleh gateway aplikasi ke target backend. Ini menghindari potensi masalah dengan URL absolut, URL pengalihan, dan cookie yang terikat host.
Sebelum menyiapkan Application Gateway yang menyimpang dari ini, silakan tinjau implikasi konfigurasi tersebut seperti yang dibahas secara lebih rinci di Pusat Arsitektur: Pertahankan 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"
- "Penimpaan nama host"
Pilih nama host dari alamat backend
Kemampuan ini secara dinamis mengatur header host dalam permintaan ke nama host kumpulan backend. Ini menggunakan alamat IP atau FQDN.
Fitur ini membantu ketika nama domain ujung belakang berbeda dari nama DNS gateway aplikasi, dan ujung belakang bergantung pada header host tertentu untuk mengatasi titik akhir yang benar.
Contoh kasus adalah layanan multi-penyewa sebagai ujung belakang. Layanan aplikasi adalah layanan multi-penyewa 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 gateway aplikasi, Anda dapat mengganti nama host dalam permintaan asli ke nama host layanan aplikasi. Untuk melakukan ini, aktifkan pengaturan pilih nama host dari alamat backend.
Untuk domain kustom yang nama DNS kustom yang ada dipetakan ke layanan aplikasi, konfigurasi yang direkomendasikan adalah tidak mengaktifkan nama host pilihan dari alamat backend.
Catatan
Pengaturan ini tidak diperlukan untuk Lingkungan Layanan Aplikasi, yang merupakan penyebaran khusus.
Ganti 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.