Cara kerja app gateway

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

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. Gerbang aplikasi menerima lalu lintas masuk pada satu atau beberapa listener. Listener adalah entitas logis yang memeriksa permintaan koneksi. Dikonfigurasi dengan alamat IP frontend, protokol, dan nomor port untuk koneksi dari klien ke app gateway.

4. Jika firewall aplikasi web (WAF) sedang digunakan, gerbang aplikasi memeriksa header dan isi permintaan, jika ada, terhadap 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. Sebuah gateway aplikasi yang menghadap internet menggunakan alamat IP publik. Nama DNS dari gerbang aplikasi yang menghadap internet dapat dipecahkan secara publik ke alamat IP publiknya. Sebagai hasilnya, gerbang aplikasi yang menghadap internet dapat 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 gerbang aplikasi merutekan permintaan

Jika permintaan valid dan tidak diblokir oleh WAF, gerbang aplikasi mengevaluasi aturan perutean permintaan yang terkait dengan pendengar. 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 terdaftar di portal untuk SKU v1.

Ketika gerbang aplikasi memilih kumpulan backend, gerbang aplikasi akan mengirimkan permintaan ke salah satu server backend yang sehat di dalam kumpulan (y.y.y.y). Kesehatan server ditentukan oleh pemeriksaan kesehatan. Jika kumpulan backend berisi beberapa server, aplikasi gateway menggunakan algoritma round-robin untuk mengalokasikan permintaan antara server yang 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 pengaturan perutean lain yang diperlukan untuk memulai sesi baru dengan server belakang.

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 gateway aplikasi mengirim permintaan asli ke server backend, ia akan menghormati konfigurasi kustom apa pun yang dibuat dalam pengaturan HTTP terkait yang menggantikan 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, satu alamat IP publik secara otomatis ditetapkan untuk konektivitas eksternal.
• Berisi FQDN yang dapat dipecahkan secara internal atau alamat IP pribadi, gateway aplikasi merutekan permintaan ke server backend dengan menggunakan alamat IP pribadi dari instansinya.
• Berisi titik akhir eksternal atau FQDN yang dapat diakses secara eksternal, gateway aplikasi merutekan permintaan ke server backend dengan menggunakan alamat IP publik frontend. 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, satu alamat IP ditetapkan untuk konektivitas eksternal keluar.

Resolusi DNS server backend

Ketika server kumpulan backend dikonfigurasi dengan Nama Domain yang Berkualifikasi Penuh (FQDN), Application Gateway melakukan pemeriksaan 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, penting bahwa semua server merespons secara konsisten dengan nilai DNS yang sama. Saat instans Application Gateway Anda mengeluarkan kueri DNS, itu menggunakan nilai dari server yang merespons terlebih dahulu.
• Pengguna server DNS kustom lokal harus memastikan konektivitas ke Azure DNS melalui Azure DNS Private Resolver (disarankan) atau VM 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-forwarded-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 ditambahkan cookie afinitas yang dikelola oleh 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 mengaitkan permintaan yang diterima oleh gateway aplikasi dan dikirim ke anggota himpunan backend melalui properti transactionId di Log Diagnostik.

Anda bisa mengonfigurasi gateway aplikasi untuk memodifikasi header permintaan dan respons serta URL menggunakan Penulisan Ulang header HTTP dan URL atau untuk memodifikasi jalur URI menggunakan pengaturan penimpaan jalur. Tapi, kecuali dikonfigurasi untuk melakukannya, semua permintaan yang masuk diproksikan ke backend.

Langkah berikutnya

• Pelajari tentang komponen app gateway
• Meninjau fitur dari Azure Application Gateway