Application Gateway リスナーの構成

リスナーは、ポート、プロトコル、ホストおよび IP アドレスを使用して着信接続要求をチェックする論理エンティティです。 リスナーを設定する際は、ゲートウェイの受信リクエストに対応する値と一致する設定の値を入力する必要があります。

Azure portal を使用してアプリケーション ゲートウェイを作成するときにも、リスナーのプロトコルとポートを選択して既定のリスナーを作成します。 リスナー上で HTTP2 のサポートを有効にするかどうかを選択できます。 アプリケーション ゲートウェイを作成した後、この既定リスナー (appGatewayHttpListener) の設定を編集することや、新しいリスナーを作成することができます。

リスナーの種類

新しいリスナーを作成するときは、"基本" または "マルチサイト" を選択します。 ルーティングが受信リクエストのホスト名に依存するかどうかによります。

マルチサイトリスナーについて詳しく知りたい方は、「 アプリケーションゲートウェイを使った複数サイトホスティング」をご覧ください。

リスナーを処理する順序

v1 SKU の場合、要求は、規則の順序とリスナーの種類に従って照合されます。 基本的なリスナーを持つルールが順序で先に来た場合、最初に処理し、そのポートとIPの組み合わせに対するリクエストを受け入れます。 この動作を避けるために、まずマルチサイトリスナーでルールを設定し、基本リスナーをリストの最後までプッシュしてください。

v2 SKU の場合、ルールの優先順位はリスナーが処理される順序を定義します。 サイト固有リスナーや複数サイトリスナーよりも優先度の高いワイルドカードおよびベーシックリスナーを定義します。 この構成により、サイトスペシフィックおよびマルチサイトリスナーがワイルドカードや基本リスナーより先に実行されることを保証します。

以下の表は、各SKUにおける処理順序の決定方法をまとめています。

フロントエンド IP アドレス

このリスナーに関連付ける予定のフロントエンド IP アドレスを選択します。 リスナーはこのIPからの受信リクエストを聞きます。

クライアントがインターネット経由でこのリスナーの背後にあるアプリケーションにアクセスした際、パブリックフロントエンドIPアドレスを選択します。 内部エンドポイントにはインターネットに触れないプライベートフロントエンドIPアドレスを選びましょう。例えば、内部ラインオブビジネスアプリケーションや、負荷分散、セッションの固定性、TLS終了が必要なマルチティアアプリケーションの階層などです。 サポートされている組み合わせについては、 フロントエンドIPアドレス設定を参照してください。

フロントエンド ポート

フロントエンド ポートを関連付けます。 既存のポートを選択するか、新しく作成できます。 許可されているポート範囲から任意の値を選択します。 80 や 443 などの一般的なポートだけではなく、許可されている適切なカスタム ポートを使用できます。 同じポートをパブリック リスナーとプライベート リスナーに使用できます。

ポート80はHTTPリスナーの典型的な選択肢であり、443ポートはHTTPSリスナーの典型的な選択肢です。 アプリケーションでカスタムポートが必要な場合はカスタムポートを使用し、その値がSKUの許容範囲内にあるかを確認してください。なぜなら、v1とv2のSKUでサポートされている範囲が異なるからです。

プロトコル

HTTPかHTTPSを選びましょう。 クライアントとアプリケーションゲートウェイ間の通信を暗号化する必要がある場合はHTTPSを選択し、これによりゲートウェイが暗号化や復号作業をオフロードできるため、バックエンドサーバーがTLSの計算負荷に悩まされずに済みます。 このリスナーが受け付けるトラフィックに対して暗号化が不要な場合はHTTPを選択してください。

• HTTP を選択すると、クライアントとアプリケーション ゲートウェイ間のトラフィックは暗号化されません。

• TLS ターミネーションまたはエンド ツー エンドの TLS 暗号化が必要な場合は、HTTPS を選択します。 クライアントとアプリケーション ゲートウェイ間のトラフィックは暗号化され、TLS 接続はアプリケーション ゲートウェイで終了されます。 バックエンド ターゲットへのエンド ツー エンドの TLS 暗号化を行う場合は、バックエンド HTTP 設定内の HTTPS も選択する必要があります。 これにより、アプリケーション ゲートウェイがバックエンド ターゲットへの接続を開始するときにトラフィックが暗号化されます。

TLS 終端を構成するには、TLS/SSL 証明書をリスナーに追加する必要があります。 これにより、Application Gateway で受信トラフィックを復号化し、クライアントへの応答トラフィックを暗号化することができます。 Application Gateway に提供される証明書は、プライベートおよび公開キーの両方を含む Personal Information Exchange (PFX) 形式である必要があります。

サポートされている証明書

TLS 終了およびアプリケーションゲートウェイを用いたエンドツーエンドTLSの概要を参照してください。

その他のプロトコルのサポート

HTTP/2 のサポート

アプリケーションゲートウェイは、アプリケーションゲートウェイリスナーに接続するクライアント向けにHTTP/2プロトコルをサポートしています。 バックエンドサーバープールへの通信は常にHTTP/1.1を使用します。 既定では、HTTP/2 のサポートは無効になっています。 以下のAzure PowerShellコードスニペットは、このサポートを有効にする方法を示しています:

$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm

$gw.EnableHttp2 = $true

Set-AzApplicationGateway -ApplicationGateway $gw

HTTP/3(QUIC)サポート

Von Bedeutung

Azure Application GatewayでのHTTP/3サポートは現在プレビュー段階です。 プレビュー段階では、この機能の機能、可用性、およびその他の側面が、フィードバックに応じて変更される可能性があります。

このプレビュー バージョンは、サービス レベル アグリーメントなしで提供され、運用環境のワークロードには推奨されません。 特定の機能がサポートされていないか、機能が制限されている可能性があります。

詳細については、「 Microsoft Azure プレビューの追加使用条件」を参照してください。

アプリケーションゲートウェイは、Basicリスナーを使用するクライアント接続でのみHTTP/3をサポートしています。 HTTP/3対応リスナーはクライアントからのHTTP/1.1またはHTTP/2トラフィックも受け入れることができます。 アプリケーションゲートウェイからバックエンドサーバープールへの通信は引き続きHTTP/1.1を使用しています。

HTTP/3のサポートはデフォルトで無効化されています。

HTTP/3サポートの宣伝方法

アプリケーションゲートウェイは Alt-Svc HTTPレスポンスヘッダーを使用してHTTP/3のサポートを宣伝します。 リスナーでHTTP/3を有効にすると、アプリケーションゲートウェイは応答に以下の Alt-Svc ヘッダーを含みます。

Alt-Svc: h3=":<listener-port>"; ma=86400

HTTP/3を無効にすると、Application Gatewayには Alt-Svc ヘッダーが含まれていません。

HTTP/3をサポートするクライアントは、宣伝されたサービスを使ってリスナーポートでQUIC接続を確立できます。 HTTP/3をサポートしないクライアントは、TCP上でHTTP/2またはHTTP/1.1を引き続き使用しています。

WebSocket のサポート

WebSocket のサポートは既定で有効です。 ユーザーが有効または無効に構成できる設定はありません。 WebSocket は HTTP リスナーと HTTPS リスナーの両方で使用できます。

カスタム エラー ページ

Application Gatewayが返す異なるレスポンスコードごとにカスタムエラーページを定義できます。 レスポンスコード400、403、405、408、500、502、503、504のエラーページを設定することができます。 グローバルレベルまたはリスナー固有のエラーページ設定を使って、各リスナーごとに細かく設定してください。 詳細については、「Create Application Gateway custom error pages (Application Gateway のカスタム エラー ページを作成する)」を参照してください。

TLS ポリシー

TLS/SSL 証明書の管理を一元化し、バックエンド サーバー ファームの暗号化と復号化のオーバーヘッドを減らすことができます。 集中型TLS処理は、セキュリティ要件に合った中央TLSポリシーを指定することも可能です。 事前に定義されたTLSポリシーまたはカスタムTLSポリシーを選択できます。

TLSポリシーを設定してTLSプロトコルのバージョンを制御します。 TLS 1.0、TLS 1.1、TLS 1.2、TLS 1.3のTLSハンドシェイクに最低プロトコルバージョンを使用するようアプリケーションゲートウェイを設定することができます。 SSL 2.0 および 3.0 は既定で無効なため、構成できません。 詳細については、「Application Gateway の TLS ポリシーの概要」を参照してください。

リスナーを作成したら、要求ルーティング規則に関連付ける必要があります。 このルールがリスナーが受け取ったリクエストをどのようにバックエンドにルーティングするかを決定します。

次のステップ

• 要求ルーティング規則について学習します。