Application Gateway の HTTP 設定の構成
アプリケーション ゲートウェイは、ここで指定した構成を使用してトラフィックをバックエンド サーバーにルーティングします。 HTTP 設定を作成したら、それを 1 つ以上の要求ルーティング規則に関連付ける必要があります。
Cookie ベースのアフィニティ
Azure Application Gateway では、ユーザー セッションを維持するために、ゲートウェイで管理される Cookie を使用します。 ユーザーが最初の要求を Application Gateway に送信すると、セッションの詳細を含むハッシュ値を使用して、応答にアフィニティ Cookie が設定されます。これにより、このアフィニティ Cookie を持つ後続の要求は、持続性を維持するために同じバックエンド サーバーにルーティングされるようになります。
この機能は、ユーザー セッションを同じサーバー上に維持する必要があり、ユーザー セッションのセッション状態がサーバー上にローカル保存される場合に便利です。 アプリケーションが Cookie ベースのアフィニティを処理できない場合は、この機能を使用できません。 使用するには、クライアントが Cookie をサポートしている必要があります。
Note
一部の脆弱性スキャンでは、Application Gateway アフィニティ Cookie にフラグが設定されることがあります。Secure フラグまたは HttpOnly フラグが設定されないためです。 これらのスキャンでは、Cookie のデータが一方向のハッシュで生成されることが考慮されません。 Cookie にはユーザー情報が含まれず、ルーティング目的でのみ使用されます。
Chromium ブラウザー v80 の更新では、SameSite 属性のない HTTP Cookie を SameSite=Lax として扱うことが必須になりました。 CORS (クロス オリジン リソース共有) 要求の際に Cookie をサードパーティのコンテキストで送信する必要がある場合は、SameSite=None; Secure 属性を使用する必要があり、HTTPS 経由でのみ送信する必要があります。 それ以外の場合、HTTP のみのシナリオでは、ブラウザーはサードパーティのコンテキストで Cookie を送信しません。 Chrome のこの更新の目的は、セキュリティを強化し、クロスサイト リクエスト フォージェリ (CSRF) 攻撃を回避することです。
この変更をサポートするために、2020 年 2 月 17 日以降、Application Gateway (すべての SKU タイプ) は、既存の ApplicationGatewayAffinity Cookie に加えて、ApplicationGatewayAffinityCORS と呼ばれる別の Cookie を挿入します。 ApplicationGatewayAffinityCORS Cookie には、クロス オリジン要求に対してもスティッキー セッションが維持されるように、2 つの属性が追加されています ("SameSite = None; Secure")。
既定のアフィニティ Cookie 名は ApplicationGatewayAffinity であり、変更することができます。 ネットワーク トポロジに複数のアプリケーション ゲートウェイをインラインでデプロイする場合は、リソースごとに一意の Cookie 名を設定する必要があります。 カスタムのアフィニティ Cookie 名を使用する場合、サフィックスとして CORS を付加した別の Cookie も追加されます。 たとえば、CustomCookieNameCORS です。
Note
属性 SameSite=None が設定されている場合は、Cookie に Secure フラグも含まれていて、HTTPS 経由で送信される必要があります。 CORS 経由のセッション アフィニティが必要な場合は、ワークロードを HTTPS に移行する必要があります。 Application Gateway での TLS オフロードとエンドツーエンド TLS のドキュメントについては、概要に関するページ、Azure portal を使用して TLS ターミネーションでアプリケーション ゲートウェイを構成する方法に関するページ、「ポータルで Application Gateway を使用してエンド ツー エンド TLS を構成する」を参照してください。
接続のドレイン
接続ドレインを使用すると、計画されたサービスの更新中にバックエンド プール メンバーを正常に削除できます。 これは、
- バックエンド プールから明示的に削除された、または
- 正常性プローブによって異常として報告されたバックエンド インスタンスに適用されます。
バックエンドの設定で接続ドレインを有効にすると、この設定をすべてのバックエンド プール メンバーに適用できます。 これで、バックエンド プール内の登録を解除するすべてのインスタンスが、構成されたタイムアウト値まで既存の接続を維持しながら、新しい要求や接続を受信しなくなります。 これは WebSocket 接続にも当てはまります。
| [構成の種類] | 値 |
|---|---|
| [バックエンド設定] で [接続ドレイン] が有効になっていない場合の既定値 | 30 秒 |
| [バックエンド設定] で [接続ドレイン] が有効になっている場合のユーザー定義値 | 1 秒から 3,600 秒 |
この唯一の例外は、ゲートウェイで管理されるセッション アフィニティが原因で、登録解除中のインスタンスに送信される要求です。 これらの要求は、登録解除中のインスタンスに引き続き転送されます。
Protocol
Application Gateway は、要求をバックエンド サーバーにルーティングする際に HTTP と HTTPS の両方をサポートします。 HTTP を選択した場合、バックエンド サーバーへのトラフィックは暗号化されません。 暗号化されていない通信を許容できない場合は、HTTPS を選択してください。
リスナーで HTTPS と組み合わせたこの設定は、エンド ツー エンド TLS をサポートします。 これによって、機密データを暗号化して安全にバックエンドに送信することができます。 エンド ツー エンド TLS が有効になったバックエンド プール内の各バックエンド サーバーは、セキュリティで保護された通信が可能になるように証明書で構成する必要があります。
Port
この設定では、バックエンド サーバーがアプリケーション ゲートウェイからのトラフィックをリッスンするポートを指定します。 1 から 65535 までの範囲のポートを構成できます。
信頼されたルート証明書
バックエンド プロトコルとして HTTPS を選択した場合、Application Gateway には、エンド ツー エンド SSL のバックエンド プールを信頼するために信頼されたルート証明書が必要です。 既定では、[ 既知の CA 証明書を使用する] オプションは [いいえ] に設定されています。 自己署名証明書または内部の証明機関によって署名された証明書を使用する場合は、バックエンド プールが使用する一致する公開証明書を Application Gateway に対して指定する必要があります。 この証明書は、 .CER formatのApplication Gatewayに直接アップロードする必要があります。
信頼された公的な証明機関によって署名されたバックエンド プールで証明書を使用する場合は、[既知の CA 証明書を使用する] オプションを [はい ] に設定することで、公開証明書のアップロードをスキップできます。
要求タイムアウト
この設定は、アプリケーション ゲートウェイがバックエンド サーバーからの応答の受信を待機する秒数です。
バックエンド パスのオーバーライド
この設定を使用すると、要求がバックエンドに転送されるときに使用できる、オプションのカスタム転送パスを構成できます。 [バックエンド パスのオーバーライド] フィールドに指定したカスタム パスと一致する受信パスの部分が、転送先パスにコピーされます。 次の表は、この機能のしくみを示しています。
HTTP 設定が基本の要求ルーティング規則に関連付けられている場合:
元の要求 バックエンド パスのオーバーライド バックエンドに転送される要求 /home/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ HTTP 設定がパスベースの要求ルーティング規則に関連付けられている場合:
元の要求 パスの規則 バックエンド パスのオーバーライド バックエンドに転送される要求 /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/
[カスタム プローブの使用]
この設定で、カスタム プローブが HTTP 設定と関連付けられます。 カスタム プローブを 1 つだけ HTTP 設定と関連付けることができます。 カスタム プローブを明示的に関連付けないと、バックエンドの正常性を監視するために既定のプローブが使用されます。 バック エンドの正常性監視をきめ細かく制御するには、カスタム プローブを作成することをお勧めします。
Note
対応する HTTP 設定が明示的にリスナーに関連付けられていない限り、カスタム プローブはバックエンド プールの正常性を監視しません。
ホスト名の構成
Application Gateway を使うと、バックエンドとの確立した接続に、クライアントが Application Gateway への接続に使ったホスト名とは異なるホスト名を使用できます。 この構成は便利な場合もありますが、アプリケーション ゲートウェイとクライアント間で、バックエンド ターゲットに対するホスト名が異なる場合、ホスト名のオーバーライドは慎重に行ってください。
運用環境では、クライアントがアプリケーション ゲートウェイに対して使うホスト名を、アプリケーション ゲートウェイがバックエンド ターゲットに対して使うホスト名と同じにしておくことをお勧めします。 これにより、絶対 URL、リダイレクト URL、ホストにバインドされた Cookie に関する潜在的な問題を回避できます。
ここから逸脱する Application Gateway を設定する前に、Architecture Center の「リバース プロキシとそのバックエンド Web アプリケーションの間で、元の HTTP ホスト名を維持する」で詳しく説明されているこのような構成の意味を確認してください。
HTTP 設定には、Application Gateway がバックエンドへの接続に使う Host HTTP ヘッダーに影響する 2 つの側面があります。
- [バックエンド アドレスからホスト名を選択します]
- [ホスト名の上書き]
[バックエンド アドレスからホスト名を選択します]
この機能によって、要求の host ヘッダーが、バックエンド プールのホスト名に動的に設定されます。 これには IP アドレスまたは FQDN が使用されます。
この機能が役立つのは、バックエンドのドメイン名がアプリケーション ゲートウェイの DNS 名と異なっており、バックエンドが特定のホスト ヘッダーを利用して正しいエンドポイントに解決される場合です。
たとえば、バックエンドとしてのマルチテナント サービスのケースなどです。 アプリ サービスは、単一の IP アドレスを持つ共有領域を使用するマルチテナント サービスです。 そのため、アプリ サービスにアクセスするには、カスタム ドメイン設定で構成されているホスト名を使用する必要があります。
既定ではカスタム ドメイン名は example.azurewebsites.net です。 アプリケーション ゲートウェイを使用して、App Service に明示的に登録されていないホスト名またはアプリケーション ゲートウェイの FQDN によって App Service にアクセスするには、元の要求のホスト名をオーバーライドして、アプリ サービスのホスト名にすることができます。 これを行うために、[バックエンド アドレスからホスト名を選択します] 設定を有効にします。
既存のカスタム DNS 名がアプリ サービスにマップされているカスタム ドメインの場合、[バックエンド アドレスからホスト名を選択します] を有効にしない構成をお勧めします。
Note
この設定は、専用のデプロイである App Service Environment には必要ありません。
[ホスト名の上書き]
この機能によって、アプリケーション ゲートウェイの着信要求の host ヘッダーが、指定するホスト名に置き換えられます。
たとえば、www.contoso.com が [ホスト名] 設定に指定されている場合、元の要求 *https://appgw.eastus.cloudapp.azure.com/path1 は、バックエンド サーバーに転送されるときに *https://www.contoso.com/path1 に変更されます。