Application Gateway リスナーの構成

注意

Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。 作業を始めるには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

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

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

リスナーの種類

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

ルーティングはホスト名によって異なります リスナーの種類 Behavior
いいえ Basic あらゆるドメインのリクエストをバックエンドプールに受け入れて転送します。 基本リスナーを持つアプリケーションゲートウェイを作成する方法を学ぶ。
はい マルチサイト ホストヘッダーやホスト名に基づいて異なるバックエンドプールにリクエストを転送します。 Application Gateway は、複数の Web サイトを同じパブリック IP アドレスとポートでホストするために、HTTP 1.1 ホスト ヘッダーを利用します。 同じポート上のリクエストを区別するには、受信リクエストと一致するホスト名を指定する必要があります。

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

リスナーを処理する順序

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

v2 SKU の場合、ルールの優先順位はリスナーが処理される順序を定義します。 ワイルドカードおよび基本リスナーの優先順位をサイト固有およびマルチサイトのリスナーよりも高く設定することで、サイト固有およびマルチサイトのリスナーがワイルドカードおよび基本リスナーより前に確実に実行されるようにする必要があります。

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

SKU 順序を決定するもの 推奨される構成
v1 ルールの順序とリスナーの種類。 順序で最初に処理し、そのポートとIPの組み合わせに対するあらゆるリクエストを受け入れる基本的なリスナーを持つルールです。 まずマルチサイトリスナーでルールを設定し、基本リスナーでルールをリストの最後の位置に押し上げます。
v2 ルールの優先順位。 サイト固有および複数サイトリスナーの優先度よりも高い優先度番号を持つワイルドカードおよび基本リスナーを定義し、サイト固有および複数サイトリスナーが先に実行するようにします。

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

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

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

注意

Application Gateway フロントエンドはデュアル スタック IP アドレスをサポートします。 最大 4 つのフロントエンド IP アドレス、つまり 2 つの IPv4 アドレス (パブリックとプライベート) と 2 つの IPv6 アドレス (パブリックとプライベート) を作成できます。

フロントエンド ポート

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

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

注意

同じポート番号を持つプライベートおよびパブリック リスナーを使用すると、アプリケーション ゲートウェイによってインバウンド フローの "宛先" がゲートウェイのフロントエンド IP に変更されます。 そのため、ネットワーク セキュリティ グループの構成によっては、アプリケーション ゲートウェイのパブリックおよびプライベート フロントエンド IP として宛先 IP アドレスを使用するインバウンド規則が必要になる場合があります。

インバウンド規則:

  • 送信元: （ご要望に応じて）
  • 宛先 IP アドレス: アプリケーション ゲートウェイのパブリックおよびプライベート フロントエンド IP。
  • 宛先ポート: (リスナーの構成による)
  • プロトコル: TCP

アウトバウンド規則: (特定の要件なし)

プロトコル

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

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

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

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

注意

Key Vault の TLS 証明書をリスナーに対して使用している場合は、Application Gateway から、そのリンクされたキー コンテナー リソースとその中の証明書オブジェクトに常にアクセスできるようにする必要があります。 これにより、TLS 終端機能のシームレスな操作が可能になり、ゲートウェイ リソースの全体的な正常性が維持されます。 アプリケーション ゲートウェイ リソースは、正しく構成されていないキー コンテナーを検出すると、関連付けられている HTTPS リスナーを無効な状態に自動的に設定します。 詳細情報 を参照してください。

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

「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

Von Bedeutung

Azure portal を使用してアプリケーション ゲートウェイ リソースを作成する場合、 HTTP2 の既定のオプションは有効に設定されます。 作成時に無効を選択し、Azure ポータルでApplication Gateway 構成の>の下にある有効を選択することで、HTTP2 のサポートを再度有効にできます。

HTTP2 がクライアントでサポートされていない場合は、HTTP1.1 が使用されます。 HTTP2 を有効にしても HTTP1.1 は無効になりません。両方をサポートできます。

注意

Application Gateway では、HTTP/2 over TLS (HTTPS リスナー) のみがサポートされます。 HTTP/1.1 からの HTTP/2 Cleartext (h2c) プロトコルのアップグレード試行はサポートされていないため、403 Forbidden エラーが発生します。 h2c アップグレードを試みるクライアントは、HTTPS 経由でネイティブ 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 のカスタム エラー ページを作成する)」を参照してください。

注意

バックエンド サーバーから発生したエラーは、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 ポリシーの概要」を参照してください。

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

次のステップ

  • Last updated on