Cara kerja app gateway

Artikel ini menjelaskan bagaimana gateway aplikasi menerima permintaan masuk dan merutekannya ke backend.

How an application gateway accepts a request

Cara app gateway menerima permintaan

  1. Sebelum klien mengirim permintaan ke app gateway, ia menyelesaikan nama domain app gateway menggunakan server Sistem Nama Domain (DNS). Azure mengontrol entri DNS karena semua app gateway berada di domain azure.com.

  2. Azure DNS mengembalikan alamat IP ke klien, yang merupakan alamat IP frontend app gateway.

  3. App gateway menerima lalu lintas masuk pada satu atau beberapa listener. Listener adalah entitas logis yang memeriksa permintaan koneksi masuk. Dikonfigurasi dengan alamat IP frontend, protokol, dan nomor port untuk koneksi dari klien ke app gateway.

  4. Jika aplikasi web firewall (WAF) sedang digunakan, app gateway memeriksa header permintaan dan isi, jika ada, melanggar aturan WAF. Tindakan ini menentukan apakah permintaan tersebut adalah permintaan yang valid atau ancaman keamanan. Jika permintaan valid, permintaan dirutekan ke backend. Jika permintaan tidak valid dan WAF dalam mode Pencegahan, permintaan diblokir sebagai ancaman keamanan. Jika dalam mode Deteksi, permintaan dievaluasi dan dicatat, tapi tetap diteruskan ke server backend.

Azure Application Gateway bisa digunakan sebagai load balancer aplikasi internal atau load balancer aplikasi akses internet. App gateway akses internet menggunakan alamat IP publik. Nama DNS app gateway akses internet bisa ditentukan secara publik ke alamat IP publiknya. Hasilnya, app gateway akses internet bisa merutekan permintaan klien dari internet.

App gateway internal hanya menggunakan alamat IP privat. Jika Anda menggunakan zona DNS Kustom atau Privat, nama domain harus dapat diselesaikan secara internal ke alamat IP privat Application Gateway. Karenanya, load balancer internal hanya bisa merutekan permintaan dari klien dengan akses ke jaringan virtual untuk app gateway.

Bagaimana app gateway merutekan permintaan

Jika permintaan valid dan tidak diblokir oleh WAF, app gateway mengevaluasi aturan perutean permintaan yang terkait dengan listener. Tindakan ini menentukan kumpulan backend mana yang akan merutekan permintaan.

Berdasarkan aturan perutean permintaan, app gateway menentukan apakah akan merutekan semua permintaan di listener ke kumpulan backend tertentu, atau merutekan permintaan ke kumpulan backend yang berbeda berdasarkan jalur URL, atau mengalihkan permintaan ke port atau situs eksternal lain.

Catatan

Aturan diproses sesuai urutan yang tercantum di portal untuk v1 SKU.

Ketika app gateway memilih kumpulan backend, app gateway akan mengirimkan permintaan ke salah satu server backend yang sehat di pool (y.y.y.y). Kesehatan server ditentukan oleh pemeriksaan kesehatan. Jika kumpulan backend berisi beberapa server, app gateway menggunakan algoritma round-robin untuk merutekan permintaan antara server sehat. Muatan ini menyeimbangkan permintaan pada server.

Setelah app gateway menentukan server backend, app gateway akan membuka sesi TCP baru dengan server backend berdasarkan pengaturan HTTP. Pengaturan HTTP menentukan protokol, port, dan setelan terkait perutean lainnya yang diperlukan untuk membuat sesi baru dengan server backend.

Port dan protokol yang digunakan dalam pengaturan HTTP menentukan apakah lalu lintas antara app gateway dan server backend dienkripsi (sehingga menyelesaikan TLS end-to-end) atau tidak terenkripsi.

Ketika app gateway mengirim permintaan asli ke server backend, app gateway akan mematuhi konfigurasi kustom apa pun yang dibuat dalam pengaturan HTTP terkait untuk menimpa nama host, jalur, dan protokol. Tindakan ini mempertahankan afinitas sesi berbasis cookie, pengurasan koneksi, pemilihan nama host dari backend, dan sebagainya.

Catatan

Jika kumpulan backend:

  • Adalah titik akhir publik, app gateway menggunakan IP publik frontend nya untuk mencapai server. Jika tidak ada alamat IP publik frontend, alamat IP publik ditetapkan untuk konektivitas eksternal keluar.
  • Berisi FQDN yang disesuaikan secara internal atau alamat IP pribadi, app gateway merutekan permintaan ke server backend dengan menggunakan alamat IP pribadi instans nya.
  • Berisi titik akhir eksternal atau FQDN yang bisa di-penyelesaian secara eksternal,app gateway merutekan permintaan ke server backend dengan menggunakan alamat IP publik frontend nya. Jika subnet berisi titik akhir layanan, gateway aplikasi akan merutekan permintaan ke layanan melalui alamat IP privatnya. Resolusi DNS didasarkan pada zona DNS privat atau server DNS kustom, jika dikonfigurasi, atau menggunakan DNS default yang disediakan Azure. Jika tidak ada alamat IP publik frontend, alamat IP publik ditetapkan untuk konektivitas eksternal keluar.

Resolusi DNS server backend

Saat server kumpulan backend dikonfigurasi dengan Nama Domain yang Sepenuhnya Memenuhi Syarat (FQDN), Application Gateway melakukan pencarian DNS untuk mendapatkan alamat IP nama domain. Nilai IP disimpan di cache gateway aplikasi Anda untuk memungkinkannya mencapai target lebih cepat saat melayani permintaan masuk.

Application Gateway menyimpan informasi cache ini untuk periode yang setara dengan TTL (waktu hidup) rekaman DNS tersebut dan melakukan pencarian DNS baru setelah TTL kedaluwarsa. Jika gateway mendeteksi perubahan alamat IP untuk kueri DNS berikutnya, gateway akan mulai merutekan lalu lintas ke tujuan yang diperbarui ini. Jika terjadi masalah seperti pencarian DNS yang gagal menerima respons atau catatan tidak ada lagi, gateway terus menggunakan alamat IP terakhir yang diketahui baik. Ini memastikan dampak minimal pada jalur data.

Penting

  • Saat menggunakan server DNS kustom dengan Virtual Network Application Gateway, sangat penting bahwa semua server identik dan merespons secara konsisten dengan nilai DNS yang sama.
  • Pengguna server DNS kustom lokal harus memastikan konektivitas ke Azure DNS melalui Azure DNS Private Resolver (disarankan) atau komputer virtual penerus DNS saat menggunakan zona DNS Privat untuk titik akhir Privat.

Modifikasi pada permintaan

Gateway aplikasi menyisipkan enam header tambahan ke semua permintaan sebelum meneruskan permintaan ke backend. Header ini adalah x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url, dan x-appgw-trace-id. Format untuk header x-forwarded-for adalah daftar IP:port yang dipisahkan koma.

Nilai yang valid untuk x-teruskan-proto adalah HTTP atau HTTPS. X-forwarded-port menentukan port di mana permintaan mencapai app gateway. Header X-original-host berisi header host asli tempat permintaan tiba. Header ini berguna dalam integrasi situs web Azure, di mana header host masuk dimodifikasi sebelum lalu lintas dirutekan ke backend. Jika afinitas sesi diaktifkan sebagai opsi, maka akan menambahkan cookie afinitas yang dikelola gateway.

X-appgw-trace-id adalah guid unik yang dihasilkan oleh gateway aplikasi untuk setiap permintaan klien dan disajikan dalam permintaan yang diteruskan ke anggota kumpulan backend. Guid terdiri dari 32 karakter alfanumerik yang disajikan tanpa tanda hubung (misalnya: ac882cd65a2712a0fe1289ec2bb6aee7). Guid ini dapat digunakan untuk menghubungkan permintaan yang diterima oleh gateway aplikasi dan dimulai ke anggota kumpulan backend melalui properti transactionId di Log Diagnostik.

Anda bisa mengonfigurasi app gateway untuk memodifikasi permintaan dan merespon header dan URL menggunakanRegenerasi HTTP header dan URL atau untuk memodifikasi jalur URI menggunakan pengaturan ambil alih jalur. Tapi, kecuali dikonfigurasi untuk melakukannya, semua permintaan yang masuk diproksikan ke backend.

Langkah berikutnya