次の方法で共有


プライベート Application Gateway デプロイ (プレビュー)

はじめに

従来、Application Gateway v2 SKU では (ある程度は v1 でも)、サービスの管理を有効にするためにパブリック IP アドレス指定を必要としてきました。 この要件により、ネットワーク セキュリティ グループやルート テーブルでのきめ細かな制御の使用にいくつかの制限が課されてきました。 具体的には、次の課題が観察されてきました。

  • [ゲートウェイ マネージャー] サービス タグへの通信を有効にするには、すべての Application Gateway v2 デプロイに公開されたフロントエンド IP 構成が含まれている必要があります。
  • ネットワーク セキュリティ グループの関連付けには、GatewayManager からの受信アクセスとインターネットへの送信アクセスを許可するための規則が必要です。
  • インターネット以外の任意の場所でトラフィックを転送する既定のルート (0.0.0.0/0) を導入しているときに、ゲートウェイのメトリック、監視、更新が失敗状態になります。

Application Gateway v2 では、これらの各項目に対処して、データ流出のリスクをさらに排除し、仮想ネットワーク内からの通信のプライバシーを制御できるようになりました。 これらの変更には、次の機能が含まれます。

  • プライベート IP アドレスのみのフロントエンド IP 構成
    • パブリック IP アドレス リソースは必要なし
  • ネットワーク セキュリティ グループを経由した GatewayManager サービス タグからの受信トラフィックの削除
  • インターネットへのエグレス トラフィックを制限するための [すべて拒否] 送信ネットワーク セキュリティ グループ (NSG) 規則を定義する機能
  • インターネットへの既定のルート (0.0.0.0/0) をオーバーライドする機能
  • 仮想ネットワーク上の定義されたリゾルバーによる DNS 解決 詳細情報 (プライベート リンクのプライベート DNS ゾーンを含む)。

これらの各機能は、独立に構成できます。 たとえば、パブリック IP アドレスを使用してインターネットからの受信トラフィックを許可し、データ流出を防止するためにネットワーク セキュリティ グループの構成で [すべて拒否] アウトバウンド規則を定義できます。

パブリック プレビューにオンボードする

プライベート IP フロントエンド構成の新しい制御、NSG 規則による制御、ルート テーブルによる制御の各機能は現在、パブリック プレビューの段階にあります。 パブリック プレビューに参加するには、Azure portal、PowerShell、CLI、または REST API を使用してこのエクスペリエンスにオプトインできます。

プレビューに参加すると、NSG、ルート テーブル、またはプライベート IP 構成の各機能の任意の組み合わせを定義する機能と共に、すべての新しい Application Gateway がプロビジョニングされます。 新しい機能からオプトアウトし、Application Gateway の現在の一般提供機能に戻りたい場合は、プレビューから登録解除することでそれを行うことができます。

プレビュー機能の詳細については、「Azure サブスクリプションでプレビュー機能を設定する」を参照してください。

プレビューに登録する

Azure portal を使用して、拡張された Application Gateway ネットワーク制御のパブリック プレビューに登録するには、次の手順を使用します。

  1. Azure portal にサインインします。

  2. 検索ボックスに「サブスクリプション」と入力し、 [サブスクリプション] を選択します。

    Azure portal 検索バーのスクリーンショット。

  3. サブスクリプションの名前のリンクを選択します。

    Azure サブスクリプションの選択のスクリーンショット。

  4. 左側のメニューの [設定] で、 [プレビュー機能] を選択します。

    Azure プレビュー機能メニューのスクリーンショット。

  5. 使用可能なプレビュー機能と現在の登録状態の一覧が表示されます。

    プレビュー機能の Azure portal の一覧のスクリーンショット。

  6. [プレビュー機能] から、フィルター ボックスに「EnableApplicationGatewayNetworkIsolation」と入力し、機能を確認して [登録] をクリックします。

    Azure portal フィルターのプレビュー機能のスクリーンショット。

Note

機能の登録の状態が [登録中] から [登録済み] に切り替わるには、最大 30 分かかることがあります。

プレビュー機能の詳細については、「Azure サブスクリプションでプレビュー機能を設定する」を参照してください。

プレビューから登録解除する

ポータルを使用して、拡張された Application Gateway ネットワーク制御のパブリック プレビューからオプトアウトするには、次の手順を使用します。

  1. Azure portal にサインインします。

  2. 検索ボックスに「サブスクリプション」と入力し、 [サブスクリプション] を選択します。

    Azure portal 検索バーのスクリーンショット。

  3. サブスクリプションの名前のリンクを選択します。

    Azure サブスクリプションの選択のスクリーンショット。

  4. 左側のメニューの [設定] で、 [プレビュー機能] を選択します。

    Azure プレビュー機能メニューのスクリーンショット。

  5. 使用可能なプレビュー機能と現在の登録状態の一覧が表示されます。

    プレビュー機能の Azure portal の一覧のスクリーンショット。

  6. [プレビュー機能] から、フィルター ボックスに「EnableApplicationGatewayNetworkIsolation」と入力し、機能を確認して [登録解除] をクリックします。

    Azure portal フィルターのプレビュー機能のスクリーンショット。

リージョンと可用性

プライベート Application Gateway プレビューは、Application Gateway v2 SKU がサポートされているすべてのパブリック クラウド リージョンで使用できます。

ネットワーク制御の構成

パブリック プレビューに登録した後、NSG、ルート テーブル、プライベート IP アドレス フロントエンド構成の構成は、任意の方法を使用して実行できます。 たとえば、REST API、ARM テンプレート、Bicep デプロイ、Terraform、PowerShell、CLI、またはポータルを使用できます。 このパブリック プレビューでは、API やコマンドの変更は導入されていません。

リソースの変更

ゲートウェイがプロビジョニングされると、EnhancedNetworkControl の名前と True の値でリソース タグが自動的に割り当てられます。 次の例を参照してください。

EnhancedNetworkControl タグのスクリーンショット。

このリソース タグは表面的なものであり、ゲートウェイが、プライベートのみのゲートウェイ機能の任意の組み合わせを構成する機能を使用してプロビジョニングされていることを確認するのに役立ちます。 タグや値を変更または削除しても、ゲートウェイの機能的な動作は変更されません。

ヒント

EnhancedNetworkControl タグは、機能を有効にする前に既存の Application Gateway がサブスクリプションにデプロイされており、どちらのゲートウェイが新しい機能を利用できるかを見分けたい場合に役立つことがあります。

Application Gateway サブネット

Application Gateway サブネットは、Application Gateway リソースがデプロイされる仮想ネットワーク内のサブネットです。 フロントエンド プライベート IP 構成では、このサブネットが、公開されているアプリまたはサイトに接続するリソースにプライベートに到達できることが重要です。

送信インターネット接続

プライベート フロントエンド IP 構成のみが含まれている (要求ルーティング規則に関連付けられたパブリック IP フロントエンド構成が含まれていない) Application Gateway デプロイでは、インターネット宛てのトラフィックを送信できません。 この構成は、インターネット経由でパブリックにアクセス可能なバックエンド ターゲットへの通信に影響を与えます。

Application Gateway から、インターネットに接続するバックエンド ターゲットへの送信接続を有効にするには、Virtual Network NAT を利用するか、またはインターネットにアクセスできる仮想アプライアンスにトラフィックを転送できます。

Virtual Network NAT では、構成可能なアイドル タイムアウトだけでなく、との IP アドレスまたはプレフィックスを使用する必要があるかを制御できます。 構成するには、パブリック IP アドレスまたはパブリック プレフィックスを持つ新しい NAT Gateway を作成し、それを Application Gateway が含まれているサブネットに関連付けます。

インターネット エグレスに仮想アプライアンスが必要な場合は、このドキュメントの「ルート テーブルの制御」セクションを参照してください。

パブリック IP の使用が必要な一般的なシナリオ:

  • プライベート エンドポイントまたはサービス エンドポイントを使用しないキー コンテナーへの通信
    • Application Gateway に直接アップロードされる pfx ファイルに送信通信は必要なし
  • インターネットを経由したバックエンド ターゲットへの通信
  • インターネットに接続する CRL または OCSP エンドポイントへの通信

ネットワーク セキュリティ グループの制御

Application Gateway サブネットに関連付けられているネットワーク セキュリティ グループには GatewayManager のインバウンド規則が必要なくなり、インターネットへの送信アクセスは必要ありません。 必要な唯一の規則は、正常性プローブが確実にゲートウェイに到着できるようにするための AzureLoadBalancer からの受信を許可するです。

次の構成は、Azure 正常性プローブ以外のすべてのトラフィックを拒否する、最も制限の厳しい一連のインバウンド規則の例です。 定義された規則に加えて、クライアント トラフィックがゲートウェイのリスナーに到着できるようにするための明示的な規則が定義されます。

受信セキュリティ規則のスクリーンショット。

Note

DenyAll 規則で正常性プローブへのアクセスが誤って制限されている場合は、Application Gateway に、[LoadBalanceRule を許可する] が指定されていることを確認するよう求めるアラートが表示されます。

シナリオ例

この例では、次の規則で Azure portal を使用して NSG を作成する方法について説明します。

  • インターネットから発信されたクライアント要求から Application Gateway へのポート 80 と 8080 への受信トラフィックを許可する
  • その他のすべての受信トラフィックを拒否する
  • 別の仮想ネットワーク内のバックエンド ターゲットへの送信トラフィックを許可する
  • インターネットにアクセス可能バックエンド ターゲットへの送信トラフィックを許可する
  • その他のすべての送信トラフィックを拒否する

まず、ネットワーク セキュリティ グループを作成します。 このセキュリティ グループには、インバウンド規則とアウトバウンド規則が含まれています。

受信の規則

セキュリティ グループには、3 つの受信の既定の規則が既にプロビジョニングされています。 次の例を参照してください。

既定のセキュリティ グループ規則のスクリーンショット。

次に、次の 4 つの新しい受信セキュリティ規則を作成します。

  • インターネットからの受信ポート 80 (TCP) を許可する (任意)
  • インターネットからの受信ポート 8080 (TCP) を許可する (任意)
  • AzureLoadBalancer からの受信を許可する
  • すべての受信を拒否する

これらの規則を作成するには、次の操作を行います。

  • [受信セキュリティ規則] を選択します。
  • [追加] を選択します。
  • 各規則の次の情報を [受信セキュリティ規則の追加] ペインに入力します。
  • 情報を入力したら、[追加] を選択して規則を作成します。
  • 各規則の作成には少し時間がかかります。
ルール番号 ソース 発信元サービス タグ Source port ranges 宛先 サービス 宛先ポートの範囲 プロトコル アクション Priority 名前
1 任意 * Any HTTP 80 TCP Allow 1028 AllowWeb
2 Any * Any Custom 8080 TCP Allow 1029 AllowWeb8080
3 サービス タグ AzureLoadBalancer * [任意] Custom * [任意] Allow 1045 AllowLB
4 Any * Any Custom * [任意] 拒否 4095 DenyAllInbound

プロビジョニングが完了したら、[更新] を選択して、すべての規則を確認します。

インバウンド セキュリティ グループ規則の例のスクリーンショット。

アウトバウンド規則

優先順位が 65000、65001、65500 の 3 つの既定のアウトバウンド規則が既にプロビジョニングされています。

次の 3 つの新しい送信セキュリティ規則を作成します。

  • 10.10.4.0/24 からバックエンド ターゲット 203.0.113.1 への TCP 443 を許可する
  • ソース 10.10.4.0/24 から宛先 10.13.0.4 への TCP 80 を許可する
  • DenyAll トラフィック規則

これらの規則には、それぞれ 400、401、4096 の優先順位が割り当てられます。

Note

  • 10.10.4.0/24 は、Application Gateway サブネットのアドレス空間です。
  • 10.13.0.4 は、ピアリングされた VNet 内の仮想マシンです。
  • 203.0.113.1 は、バックエンド ターゲット VM です。

これらの規則を作成するには、次の操作を行います。

  • [送信セキュリティ規則] を選択します。
  • [追加] を選択します。
  • 各規則の次の情報を [送信セキュリティ規則の追加] ペインに入力します。
  • 情報を入力したら、[追加] を選択して規則を作成します。
  • 各規則の作成には少し時間がかかります。
ルール番号 ソース ソース IP アドレス/CIDR 範囲 Source port ranges 宛先 宛先 IP アドレス/CIDR 範囲 サービス 宛先ポートの範囲 プロトコル アクション Priority 名前
1 IP アドレス 10.10.4.0/24 * IP アドレス 203.0.113.1 HTTPS 443 TCP Allow 400 AllowToBackendTarget
2 IP アドレス 10.10.4.0/24 * IP アドレス 10.13.0.4 HTTP 80 TCP Allow 401 AllowToPeeredVnetVM
3 Any * Any Custom * [任意] 拒否 4096 DenyAll

プロビジョニングが完了したら、[更新] を選択して、すべての規則を確認します。

アプリケーション ゲートウェイのアウトバウンド セキュリティ規則のスクリーンショット。

NSG をサブネットに関連付ける

Application Gateway が含まれているサブネットにネットワーク セキュリティ グループを関連付けます

NSG をサブネットに関連付ける様子のスクリーンショット。

結果:

NSG の概要のスクリーンショット。

重要

アクセスを許可しようとしているクライアントからの受信トラフィックを誤って拒否する可能性があるため、DenyAll 規則を定義する場合は注意が必要です。 また、バックエンド ターゲットへの送信トラフィックを誤って拒否したために、バックエンドの正常性の確認に失敗して 5XX 応答が生成されることもあります。

ルート テーブルの制御

Application Gateway の現在のオファリングでは、Application Gateway の適切な管理を確保するために、ネクスト ホップを仮想アプライアンスとして 0.0.0.0/0 として定義された規則のルート テーブルとの関連付け (または規則の作成) はサポートされていません。

パブリック プレビュー機能を登録した後、トラフィックを仮想アプライアンスに転送する機能は、仮想アプライアンスへのネクスト ホップを使用して 0.0.0.0/0 を定義するルート テーブル規則を定義することによって可能になります。

BGP アドバタイズを使用した 0.0.0.0/0 ルートの強制トンネリングまたは学習は、Application Gateway の正常性には影響を与えず、トラフィック フローに対して適用されます。 このシナリオは、VPN、ExpressRoute、Route Server、または Virtual WAN を使用している場合に適用できます。

シナリオ例

次の例では、ルート テーブルを作成し、それを Application Gateway サブネットに関連付けて、そのサブネットからの送信インターネット アクセスが確実に仮想アプライアンスから送信されるようにします。 大まかには、次の設計が図 1 に要約されています。

  • Application Gateway はスポーク仮想ネットワーク内に存在する
  • ハブ ネットワーク内にネットワーク仮想アプライアンス (仮想マシン) が存在する
  • 仮想アプライアンスへの既定のルート (0.0.0.0/0) を持つルート テーブルが Application Gateway サブネットに関連付けられている

サンプル ルート テーブルの図。

図 1: 仮想アプライアンスを経由した送信インターネット アクセス

ルート テーブルを作成し、それを Application Gateway サブネットに関連付けるには、次の操作を行います。

  1. ルート テーブルを作成します

新しく作成されたルート テーブルのスクリーンショット。

  1. [ルート] を選択し、0.0.0.0/0 に関するネクスト ホップ規則を作成して、宛先を VM の IP アドレスとして構成します。

ネットワーク仮想アプライアンスに既定のルートを追加する様子のスクリーンショット。

  1. [サブネット] を選択し、このルート テーブルを Application Gateway サブネットに関連付けます。

AppGW サブネットへのルートの関連付けのスクリーンショット。

  1. トラフィックが仮想アプライアンスを通過していることを検証します。

制限事項と既知の問題

パブリック プレビュー段階では、次の制限事項が判明しています。

Application Gateway へのプライベート エンドポイント経由でトラフィックをトンネリングするためのプライベート リンクの構成のサポートは、プライベートのみのゲートウェイではサポートされていません。

WAF レート制限

Application Gateway WAF v2 のレート制限カスタム ルールは現在サポートされていません。

AGIC を使用したプライベート IP フロントエンド構成専用

プライベート フロントエンド IP 専用のサポートを導入するには、AGIC v1.7 を使用する必要があります。

グローバル VNet ピアリング経由のプライベート エンドポイント接続

Application Gateway に、グローバル VNet ピアリング経由でアクセス可能な VNet 内にあるプライベート エンドポイントへのバックエンド ターゲットまたはキー コンテナーの参照が存在する場合は、トラフィックが破棄され、異常な状態が発生します。

Network Watcher 統合

チェックと診断テストを実行している場合は、接続のトラブルシューティングや NSG 診断によってエラーが返されます。

拡張されたネットワーク制御を有効にする前に作成された v2 Application Gateway の共存

サブネットで、拡張されたネットワーク制御機能を有効にする前と後に作成された Application Gateway v2 デプロイを共有している場合は、ネットワーク セキュリティ グループ (NSG) とルート テーブルの機能が前のゲートウェイ デプロイに制限されます。 新しい機能を有効にする前にプロビジョニングされた Application Gateway を再プロビジョニングするか、または新しく作成されたゲートウェイで別のサブネットを使用して、拡張されたネットワーク セキュリティ グループとルート テーブルの機能を有効にする必要があります。

  • そのサブネット内に、新しい機能を有効にする前にデプロイされたゲートウェイが存在する場合は、ルート テーブル エントリを追加すると、For routes associated to subnet containing Application Gateway V2, please ensure '0.0.0.0/0' uses Next Hop Type as 'Internet' などのエラーが表示されることがあります。
  • そのサブネットにネットワーク セキュリティ グループ規則を追加すると、Failed to create security rule 'DenyAnyCustomAnyOutbound'. Error: Network security group \<NSG-name\> blocks outgoing Internet traffic on subnet \<AppGWSubnetId\>, associated with Application Gateway \<AppGWResourceId\>. This isn't permitted for Application Gateways that have fast update enabled or have V2 Sku. が表示されることがあります。

不明なバックエンドの正常性状態

バックエンドの正常性が "不明な" 場合は、次のエラーが表示されることがあります。

  • バックエンドの正常性状態を取得できませんでした。 これは、v1 SKU がある場合はポート 65503 から 65534、v2 SKU がある場合はポート 65200 から 65535 のトラフィックがアプリケーション ゲートウェイ サブネット上の NSG/UDR/Firewall によってブロックされている場合、またはバックエンド プールで構成された FQDN を IP アドレスに解決できない場合に発生します。 To learn more visit - https://aka.ms/UnknownBackendHealth. (詳細については、次にアクセスしてください。)

このエラーは無視することができ、今後のリリースで明確にされる予定です。

次のステップ