Application Gateway リスナーの構成

注意

この記事では、Azure と対話するために推奨される PowerShell モジュールである Azure Az PowerShell モジュールを使用します。 Az PowerShell モジュールの使用を開始するには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

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

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

リスナーの種類

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

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

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

リスナーを処理する順序

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

v2 SKU の場合、マルチサイト リスナーは基本リスナーの前に処理されます。

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

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

フロントエンド ポート

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

Protocol

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

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

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

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

WebSocket のサポート

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

カスタム エラー ページ

カスタム エラーは、グローバル レベルまたはリスナー レベルで定義できます。 ただし、Azure portal からのグローバル レベル カスタム エラー ページの作成は、現在サポートされていません。 リスナー レベルで 403 Web アプリケーション ファイアウォール エラー用のカスタム エラー ページまたは 502 メンテナンス ページを構成できます。 また、特定のエラー状態コード用の公的にアクセス可能な BLOB URL も指定する必要があります。 詳細については、「Create Application Gateway custom error pages (Application Gateway のカスタム エラー ページを作成する)」を参照してください。

Application Gateway error codes

グローバル カスタム エラー ページを構成する方法については、Azure PowerShell の構成に関するページを参照してください。

TLS ポリシー

TLS/SSL 証明書の管理を一元化し、バックエンド サーバー ファームの暗号化と復号化のオーバーヘッドを減らすことができます。 一元化された TLS の処理によって、お客様のセキュリティ要件に適したサーバーで中心的な役割を担う TLS ポリシーを指定することもできます。 既定定義済み、またはカスタムの TLS ポリシーを選択できます。

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

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

次の手順