アプリケーション ゲートウェイの動作
この記事では、アプリケーション ゲートウェイで受信要求をどのように受け付け、それらをどのようにバックエンドにルーティングするかについて説明します。
アプリケーション ゲートウェイでの要求の受け付け方法
クライアントからアプリケーション ゲートウェイに要求が送信される前に、ドメイン ネーム システム (DNS) サーバーを使用してアプリケーション ゲートウェイのドメイン名が解決されます。 すべてのアプリケーション ゲートウェイは azure.com ドメインに存在するため、DNS エントリは Azure によって制御されます。
Azure DNS によって、IP アドレス (アプリケーション ゲートウェイのフロントエンド IP アドレス) がクライアントに返されます。
アプリケーション ゲートウェイは、1 つ以上のリスナーで受信トラフィックを受け付けます。 リスナーは、接続要求をチェックする論理エンティティです。 これは、クライアントからアプリケーション ゲートウェイに接続するためのフロントエンド IP アドレス、プロトコル、およびポート番号で構成されています。
Web アプリケーション ファイアウォール (WAF) が使用されている場合、要求のヘッダーと本文が存在していれば、WAF 規則に対するチェックがアプリケーション ゲートウェイで実行されます。 このアクションによって、要求が有効な要求であるかセキュリティ上の脅威であるかが決定されます。 要求が有効な場合は、バックエンドにルーティングされます。 要求が有効ではなく、WAF が防止モードになっている場合は、セキュリティ上の脅威としてブロックされます。 検出モードの場合は、要求は評価されてログに記録されますが、それでもバックエンド サーバーに転送されます。
内部アプリケーション ロード バランサーまたはインターネットに接続しているアプリケーション ロード バランサーとして、Azure Application Gateway を使用できます。 インターネットに接続しているアプリケーション ゲートウェイでは、パブリック IP アドレスが使用されます。 インターネットに接続しているアプリケーション ゲートウェイの DNS 名は、そのパブリック IP アドレスにパブリックに解決できます。 その結果、インターネットに接続しているアプリケーション ゲートウェイで、インターネットからのクライアント要求をルーティングできます。
内部アプリケーション ゲートウェイでは、プライベート IP アドレスだけが使用されます。 カスタムまたはプライベート DNS ゾーンを使用している場合、ドメイン名は、アプリケーション ゲートウェイのプライベート IP アドレスに内部的に解決される必要があります。 そのため、内部ロード バランサーでは、アプリケーション ゲートウェイ用の仮想ネットワークにアクセスできるクライアントからの要求のみルーティングできます。
アプリケーション ゲートウェイでの要求のルーティング方法
要求が有効であり、WAF によってブロックされない場合は、リスナーに関連付けられている要求ルーティング規則がアプリケーション ゲートウェイで評価されます。 このアクションによって、どのバックエンド プールに要求をルーティングするかが決定されます。
要求ルーティング規則に基づいて、アプリケーション ゲートウェイでは、リスナー上のすべての要求を特定のバックエンド プールにルーティングするか、URL パスに基づいて異なるバックエンド プールにルーティングするか、別のポートまたは外部サイトにリダイレクトするかが決定されます。
Note
規則は、v1 SKU に対してポータルに一覧表示される順序で処理されます。
アプリケーション ゲートウェイでバックエンド プールが選択されると、プール内のいずれかの正常なバックエンド サーバー (y.y.y.y) に要求が送信されます。 サーバーの正常性は、正常性プローブによって決定されます。 バックエンド プールに複数のサーバーが含まれている場合、アプリケーション ゲートウェイではラウンド ロビン アルゴリズムを使用して、正常なサーバーに要求がルーティングされます。 これにより、複数のサーバーに要求が負荷分散されます。
アプリケーション ゲートウェイでバックエンド サーバーが決定されると、HTTP 設定に基づいて、そのバックエンド サーバーとの新しい TCP セッションが開かれます。 HTTP 設定には、バックエンド サーバーとの新しいセッションを確立するために必要なプロトコル、ポート、その他のルーティング関連の設定が指定されています。
アプリケーション ゲートウェイとバックエンド サーバーの間でトラフィックが暗号化されるかどうか (またそれによって、エンド ツー エンドの TLS が達成されるかどうか) は、HTTP 設定で使用されているポートとプロトコルによって決まります。
アプリケーション ゲートウェイによって元の要求がバックエンド サーバーに送信されるときに、HTTP 設定内のホスト名、パス、およびプロトコルをオーバーライドするためのカスタム構成が使用されます。 このアクションによって、Cookie ベースのセッション アフィニティ、接続のドレイン、バックエンドからのホスト名の選択が管理されます。
Note
バックエンド プールが、
- パブリック エンドポイントである場合、アプリケーション ゲートウェイでは、フロントエンド パブリック IP を使用してサーバーに到達します。 フロントエンド パブリック IP アドレスが存在しない場合は、送信外部接続用のフロントエンド パブリック IP アドレスが割り当てられます。
- 内部的に解決できる FQDN またはプライベート IP アドレスが含まれている場合、アプリケーション ゲートウェイでは、インスタンスのプライベート IP アドレスを使用して、バックエンド サーバーに要求がルーティングされます。
- 外部エンドポイントまたは外部的に解決できる FQDN が含まれている場合、アプリケーション ゲートウェイでは、フロントエンド パブリック IP アドレスを使用して、要求がバックエンド サーバーにルーティングされます。 サブネットにサービス エンドポイントが含まれる場合、アプリケーション ゲートウェイにより要求がサービスにそのプライベート IP アドレス経由でルーティングされます。 プライベート DNS ゾーンまたはカスタム DNS サーバーが構成されている場合、DNS 解決はそれをペースとします。構成されていない場合、Azure で提供されている既定の DNS が使用されます。 フロントエンド パブリック IP アドレスが存在しない場合は、送信外部接続用のフロントエンド パブリック IP アドレスが割り当てられます。
バックエンド サーバーの DNS 解決
バックエンド プールのサーバーが完全修飾ドメイン名 (FQDN) で構成されている場合、Application Gateway では DNS 参照を実行してドメイン名の IP アドレスを取得します。 IP 値はお使いのアプリケーション ゲートウェイのキャッシュに格納され、受信要求を処理するとき、ターゲットにすばやく到達することを可能にします。
Application Gateway は、その DNS レコードの TTL (有効期間) に相当する期間、このキャッシュされた情報を保持し、TTL の有効期限が切れると新しい DNS 参照を実行します。 ゲートウェイはその後続の DNS クエリの IP アドレスの変更を検出すると、この更新された宛先へのトラフィックのルーティングを開始します。 DNS 参照で応答を受信できない、レコードが存在していないなどの問題が発生した場合、ゲートウェイでは、前回正常に使用できた IP アドレスが引き続き使用されます。 これにより、データ パスへの影響を最小限に抑えることができます。
重要
- Application Gateway の仮想ネットワークでカスタム DNS サーバーを使用するとき、すべてのサーバーが同じ DNS 値で一貫して応答することが重要です。 Application Gateway のインスタンスから DNS クエリが発行されるとき、最初に応答するサーバーからの値が使用されます。
- オンプレミス カスタム DNS サーバーのユーザーは、プライベート エンドポイントにプライベート DNS ゾーンを使用するときは必ず、Azure DNS Private Resolver (推奨) または DNS フォワーダー経由で Azure DNS に接続する必要があります。
要求への変更
アプリケーション ゲートウェイは、要求をバックエンドに転送する前に、すべての要求に 6 つの追加ヘッダーを挿入します。 これらのヘッダーは、x-forwarded-for、x-forwarded-port、x-forwarded-proto、x-original-host、x-original-url、x-appgw-trace-id です。x-forwarded-for ヘッダーの形式は、IP:ポートのコンマ区切りリストです。
x-forwarded-proto の有効な値は、HTTP または HTTPS です。 x-forwarded-port には、要求がアプリケーション ゲートウェイに到達したポートが指定されます。 X-original-host ヘッダーには、到着した要求にあった元のホスト ヘッダーが含まれています。 このヘッダーは、トラフィックがバックエンドにルーティングされる前に受信ホスト ヘッダーが変更される Azure Web サイト統合で役立ちます。 オプションとしてセッション アフィニティが有効になっている場合は、ゲートウェイで管理されるアフィニティ Cookie が挿入されます。
x-appgw-trace-id は、アプリケーション ゲートウェイによってクライアント要求ごとに生成され、バックエンド プール メンバーに転送される要求に示される一意の GUID です。 GUID は、ダッシュなしで示される 32 文字の英数字で構成されます (例: ac882cd65a2712a0fe1289ec2bb6aee7)。 この GUID を使用して、アプリケーション ゲートウェイによって受信され、バックエンド プール メンバーに対して開始された要求を、診断ログ内の transactionId プロパティを介して関連付けることができます。
HTTP ヘッダーと URL を書き換える方法に関するページを使用して、要求および応答ヘッダーを変更したり、path-override 設定を使用して、URI パスを変更したりするようにアプリケーション ゲートウェイを構成できます。 ただし、そのように構成されていない限り、すべての受信要求はバックエンドにプロキシ処理されます。