Application Gateway リスナーの構成

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

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

リスナーの種類

新しいリスナーを作成するときは、"基本" または "マルチサイト" を選択します。

• (すべてのドメインに対する) すべての要求を受け入れ、バックエンド プールに転送する場合は、基本を選択します。 基本リスナーのアプリケーション ゲートウェイを作成する方法に関するページを参照してください。

• "ホスト" ヘッダーまたはホスト名に基づいて異なるバックエンド プールに要求を転送する場合は、マルチサイト リスナーを選択します。 Application Gateway は、複数の Web サイトを同じパブリック IP アドレスとポートでホストするために、HTTP 1.1 ホスト ヘッダーを利用します。 同じポートで要求を区別するために、受信要求と一致するホスト名を指定する必要があります。 詳細については、Application Gateway を使用した複数サイトのホスティングに関するページを参照してください。

リスナーを処理する順序

v1 SKU の場合、要求は、規則の順序とリスナーの種類に従って照合されます。 基本リスナーの規則が順序の先頭にある場合、その規則が最初に処理され、そのポートと IP の組み合わせに対応するすべての要求が受け入れられます。 これを回避するには、最初にマルチサイト リスナーの規則を構成し、基本リスナーの規則を一覧の最後にプッシュします。

v2 SKU の場合、ルールの優先順位が定義されていない限り、マルチサイト リスナーは基本リスナーの前に処理されます。 ルールの優先順位を使用する場合は、ワイルドカード リスナーの前に非ワイルドカード リスナーが確実に実行されるように、ワイルドカード リスナーの優先順位を非ワイルドカード リスナーよりも大きい値で定義する必要があります。

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

このリスナーに関連付ける予定のフロントエンド IP アドレスを選択します。 リスナーは、この IP 上の着信要求をリッスンします。

フロントエンド ポート

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

プロトコル

HTTP または HTTPS を選択します。

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

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

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

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

「Application Gateway での TLS 終了とエンド ツー エンド TLS の概要」を参照してください。

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

HTTP2 のサポート

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

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

$gw.EnableHttp2 = $true

Set-AzApplicationGateway -ApplicationGateway $gw

また、Azure portal を使用して HTTP2 のサポートを有効にするには、アプリケーション ゲートウェイ >[構成] の [HTTP2] で [有効] を選択します。

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 ポリシーを構成します。 TLS1.0、TLS1.1、TLS1.2、および TLS1.3 の TLS ハンドシェイクに最小プロトコル バージョンを使用するようにアプリケーション ゲートウェイを構成できます。 SSL 2.0 および 3.0 は既定で無効なため、構成できません。 詳細については、「Application Gateway の TLS ポリシーの概要」を参照してください。

リスナーを作成したら、要求ルーティング規則に関連付ける必要があります。 その規則で、リスナー上で受信された要求がバック エンドにルーティングされる方法が決まります。

次のステップ

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