Azure ExpressRoute を使用した Power Apps 用の App Service Environment のネットワーク構成の詳細

[アーティクル]
06/01/2023

重要

この記事は、App Service Environment v1 に関するものです。 App Service Environment v1 は 2024 年 8 月 31 日に廃止される予定です。より強力なインフラストラクチャ上で実行できる、使いやすい新しいバージョンの App Service Environment があります。新しいバージョンの詳細については、App Service Environment の概要に関するページから始めてください。現在 App Service Environment v1 を使用している場合は、この記事の手順に従って新しいバージョンに移行ください。

2024 年 1 月 29 日の時点で、ARM/Bicep テンプレート、Azure Portal、Azure CLI、REST API などの使用可能な方法を使用して、新しい App Service Environment v1 リソースを作成することはできなくなります。リソースの削除とデータの損失を防ぐため、2024 年 8 月 31 日より前に、App Service Environment v3 に移行する必要があります。

顧客は、Azure ExpressRoute 回線を自分の仮想ネットワークインフラストラクチャに接続することで、オンプレミスのネットワークを Azure に拡張できます。 App Service Environment は、仮想ネットワークインフラストラクチャのサブネットの中に作成されます。 App Service Environment で実行されるアプリは、ExpressRoute 接続でのみアクセスできる、バックエンドリソースに対する安全な接続を確立します。

App Service Environment は以下のシナリオで作成できます。

Azure Resource Manager の仮想ネットワーク。
クラシックデプロイモデルの仮想ネットワーク。
パブリックアドレス範囲または RFC1918 アドレス空間 (つまりプライベートアドレス) を使用する仮想ネットワーク。

Note

この記事は、Web アプリについて言及していますが、API アプリとモバイルアプリにも適用されます。

必要なネットワーク接続

App Service Environment には、ExpressRoute に接続された仮想ネットワークでは最初は満たされていない場合があるネットワーク接続要件があります。

App Service Environment が正常に機能するには、次のネットワーク接続設定が必要です。

世界各国の Azure Storage エンドポイントに対するポート 80 とポート 443 での発信ネットワーク接続。これらのエンドポイントは、App Service Environment と同じリージョンにあり、その他の Azure リージョンにもあります。 Azure Storage エンドポイントは、次の DNS ドメインで解決されます: table.core.windows.net、blob.core.windows.net、queue.core.windows.net、file.core.windows.net。
Azure Files サービスに対するポート 445 での発信ネットワーク接続。
App Service Environment と同じリージョンにある Azure SQL Database エンドポイントに対する発信ネットワーク接続。 SQL Database エンドポイントは、database.windows.net ドメインで解決されます。これには、ポート 1433、11000 ～ 11999、および 14000 ～ 14999 へのオープンアクセスが必要です。 SQL Database V12 ポートの使用について詳しくは、「ADO.NET 4.5 用の 1433 以外のポート」を参照してください。
Azure 管理プレーンエンドポイント (Azure クラシックデプロイモデルと Azure Resource Manager の両方のエンドポイント) に対する発信ネットワーク接続。これらのエンドポイントへの接続には、management.core.windows.net ドメインと management.azure.com ドメインが含まれます。
ocsp.msocsp.com、mscrl.microsoft.com、crl.microsoft.com の各ドメインメッセージに対する発信ネットワーク接続。これらのドメインへの接続は、TLS 機能をサポートするために必要です。
仮想ネットワークの DNS 構成は、この記事の前述のすべてのエンドポイントとドメインを解決できるようにする必要があります。エンドポイントを解決できない場合は、App Service Environment の作成が失敗します。既存の App Service Environment は異常とマークされています。
DNS サーバーとの通信には、ポート 53 での発信アクセスが必要です。
カスタム DNS サーバーが VPN ゲートウェイの相手側にある場合、DNS サーバーは App Service Environment を含むサブネットから到達できる必要があります。
発信ネットワークパスは、社内プロキシを経由したり、オンプレミスに強制的にトンネリングしたりすることができません。これらのアクションにより、App Service Environment からの発信ネットワークトラフィックの実質的な NAT アドレスが変わります。 App Service Environment の発信ネットワークトラフィックの NAT アドレスを変更すると、多数のエンドポイントに対して接続エラーが発生します。 App Service Environment の作成は失敗します。既存の App Service Environment は異常とマークされています。
App Service Environment に必要なポートへの受信ネットワークアクセスを許可する必要があります。詳細については、「App Service Environment への受信トラフィックを制御する方法」を参照してください。

DNS 要件を満たすには、仮想ネットワークに対して有効な DNS インフラストラクチャが構成され保守されていることを確認します。 App Service Environment の作成後に DNS 構成が変わった場合、開発者は強制的に App Service Environment から新しい DNS 構成を選択することができます。 Azure portal の App Service Environment の管理にある [再起動] アイコンを使用することで、ローリングする環境の再起動をトリガーできます。再起動により、環境から新しい DNS 構成が選択されます。

受信ネットワークアクセスの要件を満たすには、App Service Environment のサブネットに対してネットワークセキュリティグループ (NSG) を構成します。 NSG は、App Service Environment への受信トラフィックを制御するために必要なアクセスを許可します。

発信ネットワーク接続

既定では、新しく作成された ExpressRoute 回線は、発信インターネット接続を許可する既定のルートをアドバタイズします。 App Service Environment は、この構成を使用して他の Azure エンドポイントに接続できます。

顧客の一般的な構成では、発信インターネットトラフィックを強制的にオンプレミスにフローさせる独自の既定のルート (0.0.0.0/0) を定義しています。このトラフィックフローでは、App Service Environment の接続が必ず切断されます。発信トラフィックはオンプレミスでブロックされるか、Azure エンドポイントではもはや有効ではない、認識できないアドレスセットに NAT 処理されます。

解決策は、App Service Environment を含むサブネットに、1 つ (または複数) のユーザー定義ルート (UDR) を定義することです。 UDR は、既定のルートに優先するサブネット固有のルートを定義します。

可能な場合、次の構成を使用します。

ExpressRoute 構成は 0.0.0.0/0 をアドバタイズします。既定では、この構成はオンプレミスのすべての送信トラフィックを強制的にトンネリングします。
App Service Environment を含むサブネットに適用される UDR は、次ホップの種類がインターネットである 0.0.0.0/0 を定義します。この構成の例については、この記事の後の方で説明します。

この構成を組み合わせた結果として、サブネットレベル UDR は ExpressRoute 強制トンネリングよりも優先されます。 App Service Environment からの発信インターネットアクセスは保証されます。

重要

ExpressRoute 構成でアドバタイズされたルートよりも優先するには、UDR に定義されているルートを詳細にする必要があります。次のセクションで説明されている例では、0.0.0.0/0 という広いアドレス範囲を使用しています。この範囲は、より具体的なアドレス範囲を使用するルートアドバタイズによって誤ってオーバーライドされる可能性があります。

App Service Environment は、パブリックピアリングパスからプライベートピアリングパスにルートをクロスアドバタイズした ExpressRoute 構成ではサポートされません。パブリックピアリングが構成された ExpressRoute 構成は、大規模な Microsoft Azure の IP アドレス範囲について Microsoft からルートアドバタイズを受信します。これらのアドレス範囲がプライベートピアリングパスでクロスアドバタイズされた場合、App Service Environment のサブネットからの送信ネットワークパケットはすべて、顧客のオンプレミスのネットワークインフラストラクチャに強制的にトンネリングされます。このネットワークフローは App Service Environment では現在サポートされていません。 1 つの解決策として、パブリックピアリングパスからプライベートピアリングパスへのクロスアドバタイズルートの停止があります。

ユーザー定義のルートの背景情報については、「仮想ネットワークトラフィックルーティング」を参照してください。

ユーザー定義のルートの作成および構成方法については、「PowerShell を使用してルートテーブルでネットワークトラフィックをルーティングする」を参照してください。

UDR の構成

このセクションでは、App Service Environment の UDR 構成例を示します。

前提条件

Azure ダウンロードページから Azure PowerShell をインストールします。 2015 年 6 月以降の日付のダウンロードを選択してください。 [コマンドラインツール]>[Windows Powershell] で、 [インストール] を選択して最新の PowerShell コマンドレットをインストールします。
App Service Environment が独占的に使用する一意のサブネットを作成します。一意のサブネットにより、サブネットに適用される UDR で、App Service Environment 用の発信トラフィックのみが開くことが保証されます。

重要

構成手順が完了したら、App Service Environment のみをデプロイしてください。この手順により、App Service Environment のデプロイを試みる前に、発信ネットワーク接続を使用できることを確認できます。

手順 1:ルートテーブルの作成

次のスニペットに示されているように、Azure の米国西部リージョンに DirectInternetRouteTable という名前のルートテーブルを作成します。

New-AzureRouteTable -Name 'DirectInternetRouteTable' -Location uswest

手順 2:テーブル内にルートを作成する

発信インターネットアクセスを有効にするために、ルートテーブルにルートを追加します。

インターネットへの発信アクセスを構成します。次のスニペットに示されているように、0.0.0.0/0 のルートを定義します。

Get-AzureRouteTable -Name 'DirectInternetRouteTable' | Set-AzureRoute -RouteName 'Direct Internet Range 0' -AddressPrefix 0.0.0.0/0 -NextHopType Internet

0.0.0.0/0 は広いアドレス範囲です。この範囲は、より具体的な ExpressRoute からアドバタイズされたアドレス範囲によってオーバーライドされます。 0\.0.0.0/0 ルートの UDR は、0.0.0.0/0 のみをアドバタイズする ExressRoute 構成と組み合わせて使用する必要があります。

または、Azure で使用されている CIDR 範囲の最新の全一覧をダウンロードしてください。すべての Azure IP アドレス範囲の XML ファイルは、Microsoft ダウンロードセンターで入手できます。

Note

Azure の IP アドレス範囲は時間が経つと変更されます。ユーザー定義のルートは、定期的に手動で更新して同期状態を保つ必要があります。

1 つの UDR の既定の上限は 100 ルートです。 100 ルートの上限に収まるように Azure の IP アドレス範囲を "まとめる" 必要があります。 UDR 定義のルートは、ExpressRoute 接続によってアドバタイズされたルートよりも具体的である必要があります。

手順 3:テーブルをサブネットに関連付ける

ルートテーブルを、App Service Environment をデプロイする予定のサブネットに関連付けます。次のコマンドは、DirectInternetRouteTable テーブルを、App Service Environment を含む ASESubnet に関連付けます。

Set-AzureSubnetRouteTable -VirtualNetworkName 'YourVirtualNetworkNameHere' -SubnetName 'ASESubnet' -RouteTableName 'DirectInternetRouteTable'

手順 4:ルートをテストして確認する

ルートテーブルをサブネットにバインドした後、ルートをテストして確認します。

仮想マシンをサブネットにデプロイし、以下の条件を確認します。

この記事に記載されている Azure エンドポイントと Azure 以外のエンドポイントに対する発信トラフィックは、ExpressRoute 回線をフローしません。サブネットからの発信トラフィックがオンプレミスで強制トンネリングされると、App Service Environment の作成は常に失敗します。
この記事に記載されているエンドポイントの DNS 参照は、すべて正しく解決されます。

構成手順を完了してルートを確認したら、仮想マシンを削除します。サブネットは、App Service Environment の作成時には "空" である必要があります。

これで、App Service Environment をデプロイする準備が整いました。

次のステップ

Power Apps 用の App Service Environment の使用を開始するには、App Service Environment の概要に関する記事を参照してください。