- 11/16/2019
- 4 minutes to read
-
a -
j - の場合
D -
s -
v -
+2
この記事はアプリケーションゲートウェイが受信要求を受け取り、バックエンドに転送する方法を説明するものである。
How an application gateway accepts a request
-
クライアントがアプリケーション ゲートウェイに要求を送信する前に、アプリケーション ゲートウェイはドメイン名システム（DNS）サーバーを使用して、アプリケーション ゲートウェイのドメイン名を解決します。
-
AzureのDNSは、アプリケーションゲートウェイのフロントエンドIPアドレスであるIPアドレスをクライアントに返します。 リスナーは、接続要求をチェックする論理的なエンティティです。 クライアントからアプリケーションゲートウェイへの接続のために、フロントエンドのIPアドレス、プロトコル、およびポート番号で構成されます。
-
Webアプリケーションファイアウォール（WAF）が使用されている場合、アプリケーションゲートウェイは要求ヘッダーと、存在すれば本体をWAFルールと照らし合わせながらチェックします。 このアクションは、リクエストが有効なリクエストであるか、セキュリティ上の脅威であるかを判断します。 リクエストが有効であれば、バックエンドにルーティングされます。 リクエストが有効でなく、WAF が予防モードである場合、それはセキュリティ上の脅威としてブロックされます。
Azure Application Gatewayは、内部アプリケーションロードバランサーとして、またはインターネットに面したアプリケーションロードバランサーとして使用することができます。 インターネットに面したアプリケーションゲートウェイは、パブリックIPアドレスを使用します。 インターネットに面したアプリケーションゲートウェイのDNS名は、そのパブリックIPアドレスに公的に解決可能です。 その結果、インターネットに面したアプリケーションゲートウェイは、インターネットからのクライアント要求をルーティングできます。
内部アプリケーションゲートウェイは、プライベートIPアドレスのみを使用します。 カスタムまたはプライベートDNSゾーンを使用している場合、ドメイン名はアプリケーションゲートウェイのプライベートIPアドレスに内部的に解決可能である必要があります。 したがって、内部ロードバランサーは、アプリケーションゲートウェイの仮想ネットワークにアクセスできるクライアントからの要求のみをルーティングできます。
How an application gateway routes a request
WAF によってブロックされていない有効な要求であれば、アプリケーションゲートウェイはリスナーと関連付けられた要求ルーティングルールに評価されます。 5526>
リクエストルーティング規則に基づいて、アプリケーションゲートウェイは、リスナー上のすべてのリクエストを特定のバックエンドプールにルーティングするか、URLパスに基づいて異なるバックエンドプールにリクエストをルーティングするか、リクエストを別のポートまたは外部サイトにリダイレクトするかを決定します。
注意
規則は、v1 SKUのポータルにリストされている順に処理されます。
アプリケーションゲートウェイがバックエンドプールを選択すると、プール内の健全なバックエンドサーバーの1つに要求を送ります（y.y. y. y.y）。 サーバーの健全性は、健全性プローブによって判断されます。 バックエンドプールに複数のサーバーがある場合、アプリケーションゲートウェイはラウンドロビンアルゴリズムを使用して、健全なサーバー間でリクエストをルーティングします。 5526>
アプリケーションゲートウェイは、バックエンドサーバーを決定した後、HTTP設定に基づいてバックエンドサーバーとの新しいTCPセッションをオープンします。 HTTP設定は、バックエンドサーバーとの新しいセッションを確立するために必要なプロトコル、ポート、および他のルーティング関連の設定を指定します。
HTTP設定で使用されるポートとプロトコルは、アプリケーションゲートウェイとバックエンドサーバー間のトラフィックが暗号化されるか（したがってエンドツーエンドTLSを達成する）、または非暗号化であるかに関係します。
アプリケーション ゲートウェイがバックエンド サーバーに元の要求を送信するとき、ホスト名、パス、およびプロトコルの上書きに関する HTTP 設定で行われた任意のカスタム構成が尊重されます。 この動作により、Cookie ベースのセッション アフィニティ、接続の枯渇、バックエンドからのホスト名の選択などが維持されます。
Note
- Backend pool: がパブリックエンドポイントの場合、アプリケーション ゲートウェイはサーバーに到達するのにそのフロントエンド パブリック IP を使用します。
- が内部的に解決可能な FQDN またはプライベート IP アドレスを含んでいる場合、アプリケーションゲートウェイはそのインスタンスプライベート IP アドレスを使用してバックエンドサーバーに要求をルーティングします。 DNS の解決は、構成されている場合は、プライベート DNS ゾーンまたはカスタム DNS サーバーに基づくか、Azure が提供するデフォルトの DNS を使用します。 フロントエンドのパブリックIPアドレスがない場合、アウトバウンド外部接続用に割り当てられます。
Modifications to the request
A application gateway is inserted four additional headers to all requests before it forwards the requests to the backend.は、バックエンドにリクエストを転送する前に、4つの追加ヘッダーをすべてのリクエストに挿入します。 これらのヘッダは x-forwarded-for、x-forwarded-proto、x-forwarded-port、および x-original-host である。 x-forwarded-for ヘッダーの形式は、IP:port のカンマ区切りリストです。
x-forwarded-proto の有効な値は HTTP または HTTPS です。 X-forwarded-portは、リクエストがアプリケーションゲートウェイに到達したポートを指定する。 X-original-hostヘッダーは、リクエストが到着した元のホストヘッダを含みます。 このヘッダーは、トラフィックがバックエンドにルーティングされる前に受信ホストヘッダーが変更される、Azure Web サイト統合で便利です。 セッションアフィニティがオプションとして有効になっている場合、ゲートウェイで管理されたアフィニティクッキーが追加されます。
Rewrite HTTP headers and URL を使用してリクエストとレスポンスヘッダーと URL を変更する、または path-override 設定を使用して URI パスを変更するよう application gateway を構成することが可能です。 ただし、そのように設定しない限り、すべての受信リクエストはバックエンドにプロキシされます。
アプリケーションゲートウェイコンポーネントについて学ぶ
。