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 上の着信要求をリッスンします。
フロントエンド ポート
フロントエンド ポートを関連付けます。 既存のポートを選択するか、新しいポートを作成できます。 許可されているポート範囲から任意の値を選択します。 80 や 443 などの一般的なポートだけではなく、許可されている適切なカスタム ポートを使用できます。 パブリック リスナーとプライベート リスナーに同じポートを使用できます (プレビュー機能)。
注意
同じポート番号でプライベート リスナーとパブリック リスナーを使用する場合、アプリケーション ゲートウェイは、受信フローの "宛先" をゲートウェイのフロントエンド IP に変更します。 そのため、ネットワーク セキュリティ グループの構成によっては、アプリケーション ゲートウェイのパブリックおよびプライベート フロントエンド IP として 宛先 IP アドレス を含む受信規則が必要になる場合があります。
受信規則:
- ソース: (要件に従って)
- 宛先 IP アドレス: アプリケーション ゲートウェイのパブリックおよびプライベート フロントエンド IP。
- 宛先ポート: (リスナー構成に従って)
- プロトコル:TCP
送信規則: (特定の要件なし)
Protocol
HTTP または HTTPS を選択します。
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
また、アプリケーション ゲートウェイ>構成の [HTTP2] で [有効] を選択して、Azure portalを使用して HTTP2 サポートを有効にすることもできます。
WebSocket のサポート
WebSocket のサポートは既定で有効です。 ユーザーが有効または無効に構成できる設定はありません。 WebSocket は HTTP リスナーと HTTPS リスナーの両方で使用できます。
カスタム エラー ページ
カスタム エラーはグローバル レベルまたはリスナー レベルで定義できますが、Azure portal でのグローバル レベルのカスタム エラー ページの作成は現在サポートされていません。 リスナー レベルで 403 Web アプリケーション ファイアウォール エラー用のカスタム エラー ページまたは 502 メンテナンス ページを構成できます。 特定のエラー状態コード用の公的にアクセス可能な BLOB URL を指定する必要があります。 詳細については、「Create Application Gateway custom error pages (Application Gateway のカスタム エラー ページを作成する)」を参照してください。
グローバル カスタム エラー ページを構成する方法については、Azure PowerShell の構成に関するページを参照してください。
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 ポリシーの概要」を参照してください。
リスナーを作成したら、要求ルーティング規則に関連付ける必要があります。 その規則で、リスナー上で受信された要求がバック エンドにルーティングされる方法が決まります。