Application Gateway インフラストラクチャの構成
Azure Application Gateway のインフラストラクチャには、仮想ネットワーク、サブネット、ネットワーク セキュリティ グループ (NSG)、ユーザー定義ルート (UDR) が含まれます。
仮想ネットワークと専用サブネット
アプリケーション ゲートウェイは、お客様の仮想ネットワーク内の専用デプロイメントです。 仮想ネットワーク内では、ご使用のアプリケーション ゲートウェイのために専用サブネットが必要です。 1 つのサブネットに特定の Application Gateway デプロイの複数インスタンスを配置できます。 また、サブネット内に他のアプリケーション ゲートウェイをデプロイすることもできます。 ただし、Application Gateway サブネットに他のリソースをデプロイすることはできません。 同じサブネット上に v1 と v2 の Application Gateway SKU を混在させることはできません。
Note
仮想ネットワーク サービス エンドポイント ポリシーは現在、Application Gateway のサブネットではサポートされません。
サブネットのサイズ
Application Gateway は、インスタンスごとに 1 つのプライベート IP アドレスを使用します。さらに、プライベート フロントエンド IP を構成している場合は、もう 1 つプライベート IP アドレスを使用します。
また Azure では、各サブネット内に内部使用のため 5 つの IP アドレスが予約されています。 最初の 4 つのアドレスと最後の IP アドレスです。 たとえば、プライベート フロントエンド IP がない 15 個のアプリケーション ゲートウェイ インスタンスがあるとします。 このサブネットには少なくとも 20 個の IP アドレスが必要です。 内部使用のために 5 個、アプリケーション ゲートウェイ インスタンスのために 15 個必要です。
27 個のアプリケーション ゲートウェイ インスタンスと、1 個のプライベート フロントエンド IP 用 IP アドレスがあるサブネットがあるとします。 この場合、33 個の IP アドレスが必要です。 アプリケーション ゲートウェイ インスタンスのために 27 個、プライベート フロント エンドのために 1 個、内部使用のために 5 個です。
Application Gateway (Standard または WAF SKU) では、最大 32 のインスタンス (32 のインスタンス IP アドレス + 1 つのプライベート フロントエンド IP 構成 + 5 つの Azure 予約) をサポートできます。 最小サブネット サイズは /26 にすることをお勧めします。
Application Gateway (Standard_v2 または WAF_v2) SKU では、最大 125 のインスタンス (125 のインスタンス IP アドレス + 1 つのプライベート フロントエンド IP 構成 + 5 つの予約済み Azure) をサポートできます。 最小サブネット サイズは /24 にすることをお勧めします。
アプリケーション ゲートウェイがプロビジョニングされている既存のサブネットの使用可能な容量を確認するには、サブネットのサイズを取得し、プラットフォームによって予約されているサブネットの 5 つの予約済み IP アドレスを減算します。 次に、各ゲートウェイを取得し、最大インスタンス数を減算します。 プライベート フロントエンド IP 構成を持つ各ゲートウェイに対し、ゲートウェイごとにさらに 1 つの追加 IP アドレスを減算します。
たとえば、さまざまなサイズの 3 つのゲートウェイがあるサブネットで使用可能なアドレス指定を計算する方法を次に示します。
- ゲートウェイ 1: 最大 10 個のインスタンス。 プライベート フロントエンド IP 構成を使用。
- ゲートウェイ 2: 最大 2 つのインスタンス。 プライベート フロントエンド IP 構成なし。
- ゲートウェイ 3: 最大 15 個のインスタンス。 プライベート フロントエンド IP 構成を使用。
- サブネットのサイズ: /24
- サブネット サイズ /24 = 256 個の IP アドレス - プラットフォームから予約された 5 個 = 251 個の使用可能なアドレス
- 251: ゲートウェイ 1 (10個) - プライベート フロントエンド IP 構成 1 個 = 240 個
- 240: ゲートウェイ 2 (2個) = 238 個
- 238: ゲートウェイ 3 (15個) - プライベート フロントエンド IP 構成 1 個 = 222 個
重要
Application Gateway v2 SKU のデプロイでは /24 サブネットは必須ではありませんが、強くお勧めします。 /24 サブネットは、Application Gateway v2 で拡張とメンテナンスのアップグレードの自動スケール用に十分な領域を確保します。
予想される最大トラフィックの処理に必要なインスタンス数に対応するための、十分なアドレス空間が Application Gateway v2 サブネットにあることを確認する必要があります。 最大インスタンス数を指定する場合、そのサブネットには少なくともその数のアドレスに対応する容量が必要です。 インスタンス数に関するキャパシティ プランニングについては、インスタンス数の詳細を参照してください。
GatewaySubnet という名前のサブネットは VPN ゲートウェイ用に予約されています。 コントロール プレーンの障害やプラットフォームの不整合を回避するために、サブネット GatewaySubnet を使用する Application Gateway v1 リソースを、2023 年 9 月 30 日より前に、別のサブネットに移動するか v２ SKU に移行する必要があります。 既存の アプリケーション ゲートウェイ インスタンスのサブネットを変更する方法については、「Application Gateway に関してよく寄せられる質問」を参照してください。
ヒント
IP アドレスは、ゲートウェイ インスタンス用に定義されたサブネット領域の先頭から割り当てられます。 ゲートウェイやスケーリング イベントの作成によってインスタンスが作成され、削除されると、サブネット内の次に使用可能なアドレスがわかりにくくなる可能性があります。 今後のゲートウェイに使用する次のアドレスを決定し、フロントエンド IP 用に連続したアドレス指定のテーマを使用できるようにするには、定義済みのサブセット領域の上半分からフロントエンド IP アドレスを割り当てることを検討してください。
たとえば、サブネットのアドレス空間が 10.5.5.0/24 の場合、10.5.5.254 で始まるゲートウェイのプライベート フロントエンド IP 構成を設定し、今後のゲートウェイで 10.5.5.253、10.5.5.252、10.5.5.251 などが続くことを検討してください。
同じ仮想ネットワーク内にある既存のアプリケーション ゲートウェイ インスタンスのサブネットを変更することができます。 この変更を行うには、Azure PowerShell または Azure CLI を使用します。 詳細については、「Application Gateway に関してよく寄せられる質問」を参照してください。
名前解決のための DNS サーバー
仮想ネットワーク リソースでは DNS サーバーの構成がサポートされており、Azure で提供される既定の DNS サーバーとカスタム DNS サーバーのどちらかを選択できます。 さらに、この DNS 構成は、アプリケーション ゲートウェイのインスタンスで名前解決のために使用されます。 この設定を変更した後、これらの変更をインスタンスに反映するために、アプリケーション ゲートウェイを再起動 ([停止]と[起動]) する必要があります。
Application Gateway のインスタンスから DNS クエリが発行されるとき、最初に応答するサーバーからの値が使用されます。
Note
Application Gateway 仮想ネットワークでカスタム DNS サーバーを使用する場合、DNS サーバーはパブリック インターネット名を解決できる必要があります。 Application Gateway には、この機能が必要です。
仮想ネットワークのアクセス許可
Application Gateway リソースは仮想ネットワーク内にデプロイされるため、仮想ネットワーク リソースに対するアクセス許可を確認するためのチェックも実行されます。 この検証は、作成と管理の両方の操作で実行され、Application Gateway イングレス コントローラーのマネージド ID にも適用されます。
Azure ロールベースのアクセス制御をチェックして、アプリケーション ゲートウェイを操作するユーザーとサービス プリンシパルに、仮想ネットワークまたはサブネットに対する少なくとも次のアクセス許可があることを確認します。
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
これらのアクセス許可を既にサポートしている、ネットワーク共同作成者などの組み込みロールを使用できます。 組み込みロールで適切なアクセス許可が提供されない場合は、カスタム ロールを作成して割り当てることができます。 「サブネットのアクセス許可の管理」の詳細を確認してください。
Note
ロールの割り当て変更の後には、Azure Resource Manager キャッシュの更新に十分な時間が必要になる場合があります。
サブスクリプションで影響を受けるユーザーまたはサービス プリンシパルの特定
アカウントの Azure Advisor にアクセスすると、十分なアクセス許可を持たないユーザーまたはサービス プリンシパルがサブスクリプションに含まれているかどうかを確認できます。 その推奨事項の詳細は次のとおりです。
タイトル: Application Gateway ユーザーの VNet アクセス許可を更新する
カテゴリ: 信頼性
影響: 高
一時的な Azure Feature Exposure Control (AFEC) フラグの使用
一時的な拡張機能として、サブスクリプション レベルの Azure Feature Exposure Control (AFEC) が導入されました。 AFEC に登録し、それをすべてのユーザーとサービス プリンシパルのアクセス許可を修正するまで使用できます。 Azure サブスクリプションのプレビュー機能の登録と同じ手順に従って機能に登録します。
名前: Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
説明: Application Gateway サブネットのアクセス許可チェックを無効にする
ProviderNamespace: Microsoft.Network
EnrollmentType: AutoApprove
Note
この AFEC プロビジョニングは、適切なアクセス許可を割り当てるまでの中間軽減策としてのみ使用することをお勧めします。 該当するすべてのユーザー (およびサービス プリンシパル) のアクセス許可の修正を優先し、その後、この AFEC フラグの登録を解除して、仮想ネットワーク リソースに対するアクセス許可の検証を再開する必要があります。 将来削除されるため、この AFEC メソッドに永続的に依存しないことをお勧めします。
Azure Virtual Network Manager
Azure Virtual Network Manager は、サブスクリプション全体でグローバルに仮想ネットワークをグループ化、構成、デプロイ、管理できる管理サービスです。 Virtual Network Manager では、ネットワーク グループを定義して、仮想ネットワークを識別し、論理的に分割することができます。 その後、必要な接続とセキュリティの構成を決定し、ネットワーク グループ内の選択したすべての仮想ネットワークで一度に適用できます。
Azure Virtual Network Manager のセキュリティ管理規則の構成を使うと、セキュリティ ポリシーを大規模に定義して、それらを複数の仮想ネットワークに一度に適用できます。
Note
Azure Virtual Network Manager のセキュリティ管理規則は、ネットワークの分離が有効になっているアプリケーション ゲートウェイを含む Application Gateway サブネットにのみ適用されます。 ネットワークの分離が無効になっているアプリケーション ゲートウェイを持つサブネットには、セキュリティ管理規則がありません。
ネットワーク セキュリティ グループ
Application Gateway サブネットには NSG を使用できますが、いくつかの重要な点と制限事項に注意してください。
重要
「プライベート Application Gateway デプロイ (プレビュー)」を使用する場合、これらの NSG の制限は緩和されます。
必要なセキュリティ規則
アプリケーション ゲートウェイで NSG を使用するには、いくつかの重要なセキュリティ規則を作成、または保持する必要があります。 これらの優先度は同じ順序で設定できます。
受信の規則
クライアント トラフィック: 予想されるクライアント (送信元 IP または IP 範囲として) からの受信トラフィックと、アプリケーション ゲートウェイのサブネット全体の IP プレフィックスおよび受信アクセス ポートとしての宛先に対する受信トラフィックを許可します 例えば、ポート 80 とポート 443 用にリスナーが構成されている場合、これらのポートを許可する必要があります。 この規則は Any に設定することもできます。
| ソース | 送信元ポート | 宛先 | 送信先ポート | Protocol | アクセス |
|---|---|---|---|---|---|
<as per need> |
Any | <Subnet IP Prefix> |
<listener ports> |
TCP | 許可 |
アクティブなパブリックおよびプライベート リスナーを (ルールを使用して) 同じポート番号で構成した後は、アプリケーション ゲートウェイによって、すべての受信フローの "宛先" がゲートウェイのフロントエンド IP に変更されます。 この変更は、ポートを共有していないリスナーでも発生します。 そのため、同じポート構成を使用する場合は、ゲートウェイのフロントエンドのパブリック IP アドレスとプライベート IP アドレスを受信規則の "宛先" に含める必要があります。
| ソース | 送信元ポート | 宛先 | 送信先ポート | Protocol | アクセス |
|---|---|---|---|---|---|
<as per need> |
Any | <Public and Private frontend IPs> |
<listener ports> |
TCP | 許可 |
インフラストラクチャ ポート: GatewayManager サービス タグと "任意" の宛先として、ソースからの受信要求を許可します。 宛先ポートの範囲は、SKU によって異なります。これは、バックエンド正常性の状態を通信するために必要です。 これらのポートは、Azure 証明書によって保護 (ロックダウン) されます。 適切な証明書が設定されていない外部エンティティは、そのようなエンドポイントに対する変更を開始できません。
- V2: ポート 65200 から 65535
- V1: ポート 65503 から 65534
| ソース | 送信元ポート | 宛先 | 送信先ポート | Protocol | アクセス |
|---|---|---|---|---|---|
| GatewayManager | Any | Any | <as per SKU given above> |
TCP | 許可 |
Azure Load Balancer プローブ: AzureLoadBalancer サービス タグとして、ソースからの受信トラフィックを許可します。 このルールは、NSG に対して既定で作成されます。 アプリケーション ゲートウェイの円滑な運用を保証するために、手動の "拒否" 規則でオーバーライドしないでください。
| ソース | 送信元ポート | 宛先 | 送信先ポート | Protocol | アクセス |
|---|---|---|---|---|---|
| AzureLoadBalancer | Any | Any | Any | Any | Allow |
"すべて拒否" 規則を使用すると、他のすべての受信トラフィックをブロックできます。
アウトバウンド規則
インターネットへの送信: すべての宛先に対してインターネットへの送信トラフィックを許可します。 このルールは、NSG に対して既定で作成されます。 アプリケーション ゲートウェイの円滑な運用を保証するために、手動の "拒否" 規則でオーバーライドしないでください。 送信接続を拒否する送信 NSG 規則は作成しないでください。
| ソース | 送信元ポート | 宛先 | 送信先ポート | Protocol | アクセス |
|---|---|---|---|---|---|
| Any | Any | インターネット | Any | Any | Allow |
Note
ネットワーク分離が有効になっていない Application Gateway では、リモート仮想ネットワークへのトラフィックの許可が無効になっている場合、ピアリングされた VNet 間でトラフィックを送信することはできません。
サポートされているユーザー定義ルート
パブリック プレビューでは、ルート テーブル規則を使用して Application Gateway サブネットを細かく制御できます。 詳しくは、「プライベート Application Gateway デプロイ」を参照してください。
現在の機能には、いくつかの制限があります。
重要
Application Gateway サブネット上で UDR を使用すると、バックエンドの正常性ビューに正常性状態が不明と表示される場合があります。 また、Application Gateway ログとメトリックの生成が失敗する場合があります。 バックエンドの正常性、ログ、およびメトリックを表示できるように、Application Gateway サブネット上で UDR を使用しないことをお勧めします。
v1: v1 SKU の場合、UDR は、エンド ツー エンドの要求/応答の通信が変更されなければ、Application Gateway サブネットでサポートされます。 たとえば、パケットの検査のためにファイアウォール アプライアンスを指すように Application Gateway サブネットの UDR を設定できます。 ただし、検査後にパケットが目的の宛先に到達できることを確認する必要があります。 これに失敗すると、不適切な正常性プローブやトラフィック ルーティング動作が発生する場合があります。 これには仮想ネットワークの Azure ExpressRoute や VPN ゲートウェイによってプロパゲートされる学習済みのルートまたは既定の 0.0.0.0/0 ルートが含まれます。
v2: v2 SKU の場合、サポートされるシナリオとサポートされないシナリオがあります。
v2 でサポートされるシナリオ
警告
ルート テーブルの構成が正しくないと Application Gateway v2 で非対称ルーティングが発生する可能性があります。 すべての管理/コントロール プレーン トラフィックが、仮想アプライアンス経由ではなく、インターネットに直接送信されるようにしてください。 ログ記録、メトリック、CRL チェックも影響を受ける可能性があります。
シナリオ 1: UDR で Application Gateway サブネットへの Border Gateway Protocol (BGP) ルート伝達を無効にする
既定のゲートウェイ ルート (0.0.0.0/0) は、Application Gateway 仮想ネットワークに関連付けられている ExpressRoute または VPN ゲートウェイ経由でアドバタイズされる場合があります。 これにより、インターネットへの直接パスを必要とする管理プレーン トラフィックが中断されます。 このようなシナリオでは、UDR を使用して BGP ルートの伝達を無効にすることができます。
BGP ルートの伝達を無効にするには以下の手順を行います。
- Azure でルート テーブル リソースを作成します。
- 仮想ネットワーク ゲートウェイのルート伝達パラメーターを無効にします。
- ルート テーブルを適切なサブネットに関連付けます。
このシナリオで UDR を有効にすると、既存のセットアップが中断されないはずです。
シナリオ 2: UDR で 0.0.0.0/0 をインターネットに送信する
0.0.0.0/0 トラフィックをインターネットに直接送信する UDR を作成できます。
シナリオ 3: Azure Kubernetes Service と kubenet の UDR
AKS と Application Gateway Ingress Controller で kubenet を使用している場合は、アプリケーション ゲートウェイからポッドに送信されたトラフィックが正しいノードにルーティングされるように、ルート テーブルが必要になります。 Azure Container Networking Interface を使用する場合は、ルート テーブルを使用する必要はありません。
ルート テーブルを使用して kubenet の動作を許可するには次の手順に従います。
AKS によって作成されたリソース グループに移動します。 リソース グループの名前は
MC_で始まる必要があります。そのリソース グループで AKS によって作成されたルート テーブルを探します。 ルート テーブルには次の情報が入ります。
- アドレス プレフィックスは、AKS でアクセスするポッドの IP 範囲にする必要があります。
- 次ホップの種類は [仮想アプライアンス] にする必要があります。
- 次ホップ アドレスは、ポッドをホストしているノードの IP アドレスになります。
このルートテーブルを Application Gateway サブネットに関連付けます。
v2 でサポートされないシナリオ
シナリオ 1: 仮想アプライアンスの UDR
v2 では、仮想アプライアンス、ハブ/スポーク仮想ネットワーク、またはオンプレミス (強制トンネリング) を介して 0.0.0.0/0 をリダイレクトする必要があるシナリオはサポートされません。