次の方法で共有

Application Gateway リスナーの構成

  • [アーティクル]

注意

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

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

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

リスナーの種類

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

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

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

リスナーを処理する順序

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

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

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

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

Note

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

フロントエンド ポート

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

Note

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

インバウンド規則:

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

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

プロトコル

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

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

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

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

Note

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

また、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 のカスタム エラー ページを作成する)」を参照してください。

Note

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

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

次のステップ