アプリを Azure 仮想ネットワークと統合する

この記事では、Azure App Service の仮想ネットワーク統合機能と、それを App Service のアプリで設定する方法について説明します。 Azure Virtual Network を使用すると、インターネットにルーティングできないネットワークに多くの Azure リソースを配置できます。 App Service の仮想ネットワーク統合機能を使用すると、アプリは仮想ネットワーク内のリソースにアクセスしたり、仮想ネットワークを通じてリソースにアクセスしたりできます。 仮想ネットワーク統合では、アプリにプライベートでアクセスすることはできません。

App Service には、次の 2 つのバリエーションがあります。

  • 専用コンピューティング価格レベル。Basic、Standard、Premium、PremiumV2、PremiumV3 が含まれます。
  • 専用のサポート インフラストラクチャを使用して仮想ネットワークに直接デプロイされ、Isolated と IsolatedV2 の価格レベルを使用している App Service Environment。

仮想ネットワーク統合機能は、Azure App Service 専用のコンピューティング価格レベルで使用されます。 アプリが App Service Environment 内にある場合、それは既に仮想ネットワーク内に存在するため、同じ仮想ネットワーク内のリソースにアクセスするために VNet 統合機能を使用する必要はありません。 すべてのネットワーク機能の詳細については、「App Service のネットワーク機能」を参照してください。

仮想ネットワーク統合により、アプリから仮想ネットワーク内のリソースにアクセスできるようになりますが、仮想ネットワークからそのアプリへの受信プライベート アクセスが許可されるわけではありません。 プライベート サイト アクセスとは、Azure 仮想ネットワーク内など、プライベート ネットワークのみからアプリにアクセスできるようにすることです。 仮想ネットワーク統合は、アプリから仮想ネットワークへの送信呼び出しを行うためだけに使用されます。 Virtual Network 統合機能は、同じリージョン内の仮想ネットワークで使用する場合と、他のリージョン内の仮想ネットワークで使用する場合とで、動作が異なります。 仮想ネットワーク統合機能には 2 つのバリエーションがあります。

  • リージョン仮想ネットワーク統合: 同じリージョン内の仮想ネットワークに接続するときは、統合する仮想ネットワークに専用のサブネットが必要です。
  • ゲートウェイが必要な仮想ネットワーク統合: 他のリージョン内の仮想ネットワークまたは同じリージョン内のクラシック仮想ネットワークに直接接続する場合、ターゲットの仮想ネットワークに作成された Azure Virtual Network ゲートウェイが必要です。

仮想ネットワーク統合の機能:

  • サポートされている Basic または Standard、Premium、Premium v2、Premium v3、または Elastic Premium の App Service 価格レベルが必要です。
  • TCP と UDP をサポートします。
  • App Service アプリおよび関数アプリと連携します。

仮想ネットワーク統合でサポートされない機能の例を次に示します。

  • ドライブのマウント。
  • Windows Server Active Directory ドメイン参加。
  • NetBIOS。

ゲートウェイが必要な仮想ネットワーク統合では、ターゲット仮想ネットワーク内、あるいはピアリングまたは VPN を使用してターゲット仮想ネットワークに接続されているネットワーク内のリソースのみにアクセスできます。 ゲートウェイが必要な仮想ネットワーク統合では、Azure ExpressRoute 接続全体で利用可能なリソースへのアクセスを有効にしたり、サービス エンドポイントと連携したりすることはできません。

使用しているバージョンにかかわらず、仮想ネットワーク統合により、アプリから仮想ネットワーク内のリソースにアクセスできるようになりますが、仮想ネットワークからそのアプリへの受信プライベート アクセスが許可されるわけではありません。 プライベート サイト アクセスとは、Azure 仮想ネットワーク内など、プライベート ネットワークのみからアプリにアクセスできるようにすることです。 仮想ネットワーク統合は、アプリから仮想ネットワークへの送信呼び出しを行うためだけのものです。

仮想ネットワーク統合を有効にする方法を確認する。

リージョン仮想ネットワーク統合

リージョン仮想ネットワーク統合では、同じリージョン内の仮想ネットワークへの接続がサポートされ、ゲートウェイは不要です。 リージョン仮想ネットワーク統合を使用すると、アプリは次のものにアクセスできるようになります。

  • 統合した仮想ネットワーク内のリソース
  • アプリが統合されている仮想ネットワークとピアリングされた仮想ネットワーク内のリソース (グローバル ピアリング接続を含む)
  • Azure ExpressRoute 接続にまたがるリソース。
  • サービス エンドポイントでセキュリティ保護されたサービス
  • プライベート エンドポイントが有効なサービス

リージョン仮想ネットワーク統合を使用している場合は、次の Azure ネットワーク機能を使用できます。

  • ネットワーク セキュリティ グループ (NSG) :統合サブネットに配置された NSG を使って送信トラフィックをブロックできます。 仮想ネットワーク統合を使ってアプリへの受信アクセスを提供することはできないため、受信規則は適用されません。
  • ルート テーブル (UDR) :統合サブネット上にルート テーブルを配置して、必要な場所に送信トラフィックを送信できます。

リージョン仮想ネットワーク統合の仕組み

App Service 内のアプリは、worker ロールでホストされます。 リージョン仮想ネットワーク統合は、委任されたサブネット内のアドレスで仮想インターフェイスを worker ロールにマウントすることによって機能します。 統合元のアドレスはお使いの仮想ネットワーク内にあるため、仮想ネットワーク内の VM と同じように、仮想ネットワーク内に存在するか、仮想ネットワークを経由してアクセスできるほとんどのものに、アクセスできます。 ネットワークの実装は、仮想ネットワークで VM を実行する場合とは異なります。 そのため、一部のネットワーク機能はこの機能ではまだ使用できません。

リージョン仮想ネットワーク統合の仕組みを示す図。

リージョン仮想ネットワーク統合が有効になっている場合、アプリは仮想ネットワークを介して送信呼び出しを行います。 アプリのプロパティ ポータルに一覧表示される送信アドレスは、引き続きそのアプリによって使用されるアドレスです。 ただし、送信呼び出しが、統合仮想ネットワークまたはピアリングされた仮想ネットワーク内の仮想マシンまたはプライベート エンドポイントに対して行われる場合、送信アドレスは統合サブネットのアドレスになります。 インスタンスに割り当てられたプライベート IP は、環境変数 WEBSITE_PRIVATE_IP によって公開されます。

すべてのトラフィックのルーティングを有効にすると、すべての送信トラフィックが仮想ネットワークに送られます。 すべてのトラフィックのルーティングが有効になっていない場合、統合サブネットで構成されたプライベート トラフィック (RFC1918) とサービス エンドポイントだけが仮想ネットワークに送信され、インターネットへの送信トラフィックは通常と同じチャネルを経由します。

この機能では、worker ごとに 2 つの仮想インターフェイスがサポートされます。 worker あたり 2 つの仮想インターフェイスは、App Service プランごとに 2 つのリージョン仮想ネットワーク統合を意味します。 同じ App Service プラン内のアプリは、特定のサブネットへの仮想ネットワーク統合のうち 1 つだけを使用できます。 アプリで追加の仮想ネットワークまたは同じ仮想ネットワーク内の追加のサブネットに接続する必要がある場合、別の App Service プランを作成する必要があります。 使用される仮想インターフェイスは、顧客が直接アクセスできるリソースではありません。

サブネットの要件

仮想ネットワーク統合は、専用サブネットに依存します。 サブネットを作成すると、Azure サブネットから 5 つの IP が減ります。 プラン インスタンスごとに、統合サブネットから 1 つのアドレスが使用されます。 アプリを 4 つのインスタンスにスケールする場合は、4 つのアドレスが使用されます。

サイズをスケールアップまたはスケールダウンすると、必要なアドレス空間が短期間に 2 倍になります。 この変更は、特定のサブネット サイズでサポートされる実際の使用可能なインスタンスに影響します。 次の表に、CIDR ブロック 1 つにつき利用可能なアドレスの最大数と、水平スケーリングに対する影響を示します。

CIDR ブロック サイズ 使用可能なアドレスの最大数 水平スケールの最大値 (インスタンス)*
/28 11 5
/27 27 13
/26 59 29

*ある時点でサイズまたは SKU のいずれかでスケールアップまたはスケールダウンする必要があることを前提としています。

割り当てた後はサブネット サイズを変更できないため、アプリが到達する可能性のあるスケールに対応できるだけの十分な大きさを持つサブネットを使用してください。 サブネット容量に関する問題を回避するには、64 個のアドレスを持つ /26 を使用してください。 Azure portal で仮想ネットワークとの統合の一部としてサブネットを作成する場合、必要な最小サイズは /27 です。 ポータルを介して統合する前にサブネットが既に存在する場合は、/28 サブネットを使用できます。

Note

Windows コンテナーは、各 App Service プラン インスタンスについてアプリごとに追加の IP アドレスを使用するため、それに応じてサブネットのサイズを設定する必要があります。 たとえば、4 つのアプリが実行されている 10 個の Windows コンテナー App Service プラン インスタンスがある場合は、水平スケール (アップまたはダウン) をサポートするために 50 個の IP アドレスと追加のアドレスが必要です。

お使いのプラン内のアプリが、別のプラン内のアプリから既に接続されている仮想ネットワークにアクセスできるようにする場合は、既存の仮想ネットワーク統合によって使用されているものとは異なるサブネットを選びます。

アクセス許可

Azure portal や CLI を介して、または virtualNetworkSubnetId サイト プロパティを直接設定するときに、リージョン仮想ネットワーク統合を構成するには、サブネットまたは上位レベルで少なくとも次のロールベースのアクセス許可が必要です。

アクション 説明
Microsoft.Network/virtualNetworks/read 仮想ネットワークの定義を読み取ります
Microsoft.Network/virtualNetworks/subnets/read 仮想ネットワーク サブネットの定義を読み取ります
Microsoft.Network/virtualNetworks/subnets/join/action 仮想ネットワークに参加します。

仮想ネットワークがアプリとは異なるサブスクリプションにある場合、仮想ネットワークがあるサブスクリプションが Microsoft.Web リソース プロバイダーに登録されていることを確認する必要があります。 プロバイダーはこのドキュメントに従って明示的に登録できますが、サブスクリプションで最初の Web アプリを作成するときにも自動的に登録されます。

ルート

仮想ネットワーク統合を通過するトラフィックを制御できます。 リージョン仮想ネットワーク統合を構成する場合は、3 種類のルーティングを考慮する必要があります。 アプリケーション ルーティングでは、アプリから仮想ネットワークにルーティングされるトラフィックを定義します。 構成ルーティングは、アプリの起動の前またはその最中に行われる操作に影響を与えます。 例として、コンテナー イメージのプルと、Key Vault の参照を使用したアプリの設定があります。 ネットワーク ルーティングは、アプリと構成の両方のトラフィックが仮想ネットワークから送信される方法を処理する機能です。

アプリケーション ルーティングまたは構成ルーティングのオプションで、仮想ネットワーク統合を通じて送信されるトラフィックを構成できます。 トラフィックは、仮想ネットワーク統合を通じて送信される場合にのみ、ネットワーク ルーティングの対象になります。

アプリケーション ルーティング

アプリケーション ルーティングは、アプリから、その起動後に送信されるトラフィックに適用されます。 起動中のトラフィックについては、「構成ルーティング」を参照してください。 アプリケーション ルーティングを構成するときは、仮想ネットワークにすべてのトラフィックまたはプライベート トラフィック (RFC1918 トラフィックとも呼ばれます) のみをルーティングできます。 この動作を構成するには、 [ルートすべて] 設定を使用します。 [ルートすべて] が無効になっている場合、アプリはプライベート トラフィックのみを仮想ネットワークにルーティングします。 すべての送信アプリ トラフィックを仮想ネットワークにルーティングする場合は、[ルートすべて] が有効になっていることを確認してください。

  • アプリケーションまたは構成のルーティングで構成されたトラフィックのみが、統合サブネットに適用される NSG と UDR の対象になります。
  • [ルートすべて] が有効になっている場合、アプリからの送信パブリック トラフィックの送信元アドレスは、まだアプリのプロパティに一覧表示されている IP アドレスの 1 つです。 トラフィックをファイアウォールまたは NAT ゲートウェイ経由でルーティングする場合、送信元 IP アドレスはこのサービスから送信されます。

アプリケーションのルーティング設定方法を確認する。

Note

SMTP トラフィックが仮想ネットワーク統合を経由してルーティングされる場合、App Service で送信 SMTP 接続 (ポート 25) がサポートされます。 ただし、サポートが可能かどうかは、仮想ネットワークがデプロイされているサブスクリプションの設定によって決まります。 2022 年 8 月 1 日より前に作成された仮想ネットワークまたはサブネットでは、 サブスクリプションから設定を同期するために、仮想ネットワークまたはサブネットへの一時的な構成変更を開始する必要があります。 たとえば、一時的なサブネットの追加、NSG の一時的な関連付けと関連付け解除、サービス エンドポイントの一時的な構成などを行います。 詳細とトラブルシューティングについては、Azure でのアウトバウンド SMTP 接続の問題のトラブルシューティングに関するページを参照してください。

構成ルーティング

仮想ネットワーク統合を使用している場合は、構成トラフィックの一部を管理する方法を構成できます。 既定では、構成トラフィックは直接パブリック ルートを経由して送られますが、示された個々のコンポーネントについては、仮想ネットワーク統合を通じてルーティングするように明示的に構成できます。

コンテンツ共有

独自のコンテンツ用のストレージの使用は Functions でよく使用され、その場合 Functions アプリの一部としてコンテンツ共有が構成されます。

コンテンツ共有のトラフィックを仮想ネットワーク統合でルーティングするには、ルーティング設定が構成されていることを確認する必要があります。 コンテンツ共有ルーティングを構成する方法に関する記事を参照してください。

ルーティングの構成以外に、サブネットからのトラフィックが構成されているファイアウォールまたはネットワーク セキュリティ グループで、ポート 443 と 445 へのトラフィックが許可されていることを確認する必要があります。

コンテナー イメージのプル

カスタム コンテナーを使う場合は、仮想ネットワーク統合を使用してコンテナーをプルできます。 コンテナー プルのトラフィックを仮想ネットワーク統合でルーティングするには、ルーティング設定が構成されていることを確認する必要があります。 イメージ プルのルーティングを構成する方法に関する記事を参照してください。

Key Vault の参照を使用したアプリの設定

Key Vault の参照を使用したアプリの設定では、パブリック ルートを介してシークレットの取得が試みられます。 パブリック トラフィックが Key Vault でブロックされていて、アプリで仮想ネットワーク統合が使用されている場合、仮想ネットワーク統合を通じてシークレットの取得が試みられます。

注意

  • プライベート ストレージ アカウントへのバックアップ/復元は、現在サポートされていません。
  • プライベート Key Vault からの SSL/TLS 証明書の構成は、現在サポートされていません。
  • プライベート ストレージ アカウントへの App Service ログは、現在サポートされていません。 診断ログを使用し、ストレージ アカウントに対して信頼できるサービスを許可することをお勧めします。

ネットワーク ルーティング

ルート テーブルを使用して、アプリからの送信トラフィックを制限なくルーティングすることができます。 一般的な宛先には、ファイアウォール デバイスまたはゲートウェイを含めることができます。 また、ネットワーク セキュリティ グループ (NSG) を使用して、仮想ネットワークまたはインターネット内のリソースへの送信トラフィックをブロックできます。 統合サブネットに適用された NSG は、統合サブネットに適用されているルート テーブルに関係なく有効になります。

ルート テーブルとネットワーク セキュリティ グループは、仮想ネットワーク統合を通じてルーティングされるトラフィックにのみ適用されます。 詳細については、「アプリケーション ルーティング」と「構成ルーティング」を参照してください。 仮想ネットワーク統合はアプリからの送信トラフィックのみに影響を与えるため、ルートは受信アプリ要求への応答には影響を与えず、NSG での受信規則はアプリに適用されません。 アプリへの受信トラフィックを制御するには、アクセス制限機能を使用します。

送信トラフィックに影響を与えるネットワーク セキュリティ グループまたはルート テーブルを構成する場合は、アプリケーションの依存関係を考慮する必要があります。 アプリケーションの依存関係には、実行時にアプリに必要なエンドポイントが含まれます。 これは、アプリが呼び出している API とサービスの他に、証明書失効リスト (CRL) チェック エンドポイントや ID/認証エンドポイント (Azure Active Directory など) のような派生エンドポイントである可能性があります。 App Service で継続的デプロイを使用している場合は、型と言語に応じてエンドポイントを許可する必要がある場合もあります。 特に Linux の継続的デプロイの場合は、oryx-cdn.microsoft.io:443 を許可する必要があります。

オンプレミスの送信トラフィックをルーティングする場合は、ルート テーブルを使用して、送信トラフィックを Azure ExpressRoute ゲートウェイに送信できます。 ゲートウェイにトラフィックをルーティングする場合は、外部ネットワークのルートを設定して、応答を返信するようにします。 また、Border Gateway Protocol (BGP) ルートも、アプリのトラフィックに影響を与えます。 ExpressRoute ゲートウェイのようなものから BGP ルートを使用している場合は、アプリの送信トラフィックが影響を受けます。 BGP ルートもユーザー定義のルートと同様に、ルーティング スコープの設定に従ってトラフィックに影響を与えます。

サービス エンドポイント

リージョン仮想ネットワーク統合を使用すると、サービス エンドポイントで保護されている Azure サービスに接続できます。 サービス エンドポイントで保護されたサービスにアクセスするには、次の手順に従います。

  1. 統合のための特定のサブネットに接続するために、Web アプリとのリージョン 仮想ネットワーク統合を構成します。
  2. 対象のサービスに移動し、統合サブネットに対してサービス エンドポイントを構成します。

プライベート エンドポイント

プライベート エンドポイントを呼び出す場合は、DNS 参照がプライベート エンドポイントに解決されることを確認します。 この動作は、次のいずれかの方法で実現できます。

  • Azure DNS プライベート ゾーンと統合する。 仮想ネットワークにカスタム DNS サーバーがない場合は、ゾーンが仮想ネットワークにリンクされたときに自動で統合が実行されます。
  • アプリで使用される DNS サーバーでプライベート エンドポイントを管理する。 構成を管理するには、プライベート エンドポイントの IP アドレスを把握している必要があります。 次に、A レコードを使用して、アクセスしようとしているエンドポイントがそのアドレスを指すようにします。
  • Azure DNS プライベート ゾーンに転送する独自の DNS サーバーを構成します。

Azure DNS プライベート ゾーン

仮想ネットワークに統合されたアプリでは、仮想ネットワークが構成されているのと同じ DNS サーバーが使用されます。 カスタム DNS が指定されていない場合は、Azure の既定の DNS と、仮想ネットワークにリンクされているすべてのプライベート ゾーンが使用されます。

制限事項

リージョン仮想ネットワーク統合を使用する場合、いくつかの制限があります。

  • この機能は、Premium v2 と Premium v3 のすべての App Service デプロイから使用できます。 また、Basic および Standard レベルでも使用できますが、新しい App Service のデプロイからのみ利用できます。 以前のデプロイを使用している場合は、Premium v2 App Service プランからのみ、この機能を使用できます。 Basic または Standard App Service プランでこの機能を使用できるようにするには、Premium v3 App Service プランでアプリを作成します。 それらのプランは、最新のデプロイでのみサポートされます。 プランを作成した後に、必要に応じてスケールダウンできます。
  • この機能は、App Service Environment にある Isolated プランのアプリでは使用できません。
  • 従来の仮想ネットワークでは、ピアリング接続でリソースにアクセスすることはできません。
  • この機能を使用するには、Azure Resource Manager 仮想ネットワークで、/28 より大きい IPv4 のブロックからなる未使用のサブネットが必要です。
  • アプリと仮想ネットワークが同じリージョンに存在する必要があります。
  • 統合仮想ネットワークで IPv6 アドレス空間を定義することはできません。
  • 統合サブネットでは、サービス エンドポイント ポリシーを有効にすることはできません。
  • 統合サブネットは、1 つの App Service プランでしか使用できません。
  • 統合アプリがある仮想ネットワークを削除することはできません。 仮想ネットワークを削除する前に、統合を削除してください。
  • App Service プランごとに 2 つのリージョン仮想ネットワーク統合を使用できます。 同じ App Service プラン内の複数のアプリで、同じ仮想ネットワーク統合を使用できます。
  • リージョン仮想ネットワーク統合を使用しているアプリがあるときに、アプリまたはプランのサブスクリプションを変更することはできません。

ゲートウェイが必要な仮想ネットワーク統合

ゲートウェイが必要な仮想ネットワーク統合では、別のリージョンの仮想ネットワークまたはクラシック仮想ネットワークへの接続がサポートされています。 ゲートウェイが必要な仮想ネットワーク統合:

  • アプリでは一度に 1 つの仮想ネットワークにのみ接続できます。
  • App Service プランで、最大 5 つの仮想ネットワークと統合できます。
  • App Service プランで使用できる総数に影響を与えることなく、App Service プラン内の複数のアプリで同じ仮想ネットワークを使用できます。 同じ App Service プラン内の同じ仮想ネットワークを使用しているアプリが 6 つある場合、使用されている仮想ネットワークは 1 つとしてカウントされます。
  • ゲートウェイの SLA は、SLA 全体に影響を与える場合があります。
  • アプリでは仮想ネットワークが構成されている DNS を使用できます。
  • アプリに接続するには、SSTP ポイント対サイト VPN を設定した仮想ネットワーク ルートベース ゲートウェイが必要です。

次の場合、ゲートウェイが必要な仮想ネットワーク統合は使用できません。

  • ExpressRoute で接続された仮想ネットワークに対して。
  • Linux アプリから。
  • Windows コンテナーから。
  • サービス エンドポイントによって保護されているリソースにアクセスする場合
  • ネットワークで保護された Key Vault を参照するアプリ設定を解決する場合
  • ExpressRoute とポイント対サイトまたはサイト間 VPN の両方をサポートする共存ゲートウェイに対して。

Azure 仮想ネットワークでゲートウェイを設定する

ゲートウェイを作成するには:

  1. VPN ゲートウェイとサブネットを作成します。 VPN の種類はルート ベースを選択します。

  2. ポイント対サイト アドレスを設定します。 ゲートウェイが Basic SKU 内にない場合は、ポイント対サイトの構成で IKEV2 を無効にする必要があり、SSTP を選択する必要があります。 ポイント対サイトのアドレス空間は、RFC 1918 のアドレス ブロック 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 内に存在する必要があります。

ゲートウェイが必要な仮想ネットワーク統合で使用するゲートウェイを作成するときは、証明書をアップロードする必要はありません。 ゲートウェイの作成には 30 分かかることがあります。 ゲートウェイが作成されるまで、アプリを仮想ネットワークに統合することはできません。

ゲートウェイが必要な仮想ネットワーク統合の仕組み

ゲートウェイが必要な仮想ネットワーク統合は、ポイント対サイト VPN テクノロジに基づいて構築されています。 ポイント対サイト VPN により、ネットワーク アクセスはアプリがホストされている仮想マシンに制限されます。 アプリからインターネットへのトラフィックの送信は、ハイブリッド接続または仮想ネットワーク統合経由にのみ制限されます。 ゲートウェイが必要な仮想ネットワーク統合を使用するようにアプリをポータルで構成すると、ゲートウェイとアプリケーション側で証明書を作成して割り当てるための複雑なネゴシエーションが、ユーザーの代わりに管理されます。 結果として、アプリをホストするために使用される worker は、選択した仮想ネットワーク内の仮想ネットワーク ゲートウェイに直接接続できます。

ゲートウェイが必要な仮想ネットワーク統合の仕組みを示す図。

オンプレミスのリソースにアクセスする

アプリでは、サイト間接続がある仮想ネットワークと統合することで、オンプレミスのリソースにアクセスできます。 ゲートウェイが必要な仮想ネットワーク統合を使用する場合は、ポイント対サイト アドレス ブロックでオンプレミスの VPN ゲートウェイのルートを更新します。 サイト間 VPN が初めてセットアップされるときには、その構成に使用するスクリプトによって、ルートが正しくセットアップされるはずです。 サイト間 VPN を作成した後にポイント対サイト アドレスを追加する場合は、ルートを手動で更新する必要があります。 その詳しい方法はゲートウェイごとに異なるため、ここでは説明しません。

オンプレミスからの BGP ルートは、App Service に自動的に反映されません。 ドキュメント「P2S VPN クライアント用のカスタム ルートをアドバタイズする」の手順を使用して、ポイント対サイト構成で手動で反映する必要があります。

仮想ネットワーク経由でオンプレミスのリソースにアクセスするために、リージョン仮想ネットワーク統合機能に対する追加の構成は必要ありません。 必要なのは、単に ExpressRoute またはサイト間 VPN を使用して仮想ネットワークをオンプレミスのリソースに接続することだけです。

Note

ゲートウェイが必要な仮想ネットワーク統合機能では、アプリは ExpressRoute ゲートウェイを含む仮想ネットワークとは統合されません。 ExpressRoute ゲートウェイが共存モードで構成されている場合であっても、仮想ネットワーク統合は機能しません。 ExpressRoute 接続経由でリソースにアクセスする必要がある場合は、仮想ネットワークで実行されるリージョン仮想ネットワーク統合機能または App Service Environment を使用します。

ピアリング

リージョン仮想ネットワーク統合でピアリングを使用する場合、それ以上の構成を行う必要はありません。

ゲートウェイが必要な仮想ネットワーク統合でピアリングを使用する場合は、いくつかの追加の項目を構成する必要があります。 アプリで動作するようにピアリングを構成するには:

  1. アプリの接続先の仮想ネットワークでピアリング接続を追加します。 ピアリング接続を追加するときに、 [仮想ネットワークアクセスを許可する] を有効にして、 [転送されたトラフィックを許可する] チェック ボックスと [ゲートウェイ転送を許可する] チェック ボックスをオンにします。
  2. 接続先の仮想ネットワークとピアリングする仮想ネットワークにピアリング接続を追加します。 対象の仮想ネットワークでピアリング接続を追加するときは、 [仮想ネットワークアクセスを許可する] を有効にして、 [転送されたトラフィックを許可する] チェック ボックスと [リモート ゲートウェイを許可する] チェック ボックスをオンにします。
  3. ポータルで [App Service プラン][ネットワーク][VNet 統合] に移動します。 アプリの接続先の仮想ネットワークを選択します。 ルーティングのセクションで、アプリの接続先の仮想ネットワークとピアリングされている仮想ネットワークのアドレス範囲を追加します。

仮想ネットワーク統合の管理

仮想ネットワークとの接続および切断は、アプリ レベルで行われます。 複数のアプリで仮想ネットワーク統合に影響する可能性がある操作は、App Service プラン レベルで行われます。 アプリの >[ネットワーク]>[VNet 統合] ポータルから、仮想ネットワークに関する詳細を取得できます。 [App Service プラン][ネットワーク][VNet 統合] ポータルの App Service プラン レベルでも、同様の情報が表示されます。

仮想ネットワーク統合インスタンスのアプリ ビューで実行できる操作は、現在接続されている仮想ネットワークからアプリを切断する操作のみです。 仮想ネットワークからアプリを切断するには、 [切断] を選択します。 仮想ネットワークから切断すると、アプリが再起動されます。 切断によって仮想ネットワークが変更されることはありません。 サブネットやゲートウェイは削除されません。 その後で仮想ネットワークを削除する必要がある場合は、まず仮想ネットワークからアプリを切断し、ゲートウェイなどのそこに含まれているリソースを削除します。

App Service プランの仮想ネットワーク統合の UI には、App Service プラン内のアプリによって使用されているすべての仮想ネットワーク統合が表示されます。 各仮想ネットワークの詳細を表示するには、目的の仮想ネットワークを選択します。 ここでは、ゲートウェイが必要な仮想ネットワーク統合に対して実行できる操作が 2 つあります。

  • ネットワークを同期する: ネットワークの同期操作は、ゲートウェイが必要な仮想ネットワーク統合機能でのみ使用されます。 ネットワークの同期操作を実行すると、証明書とネットワーク情報が同期されます。仮想ネットワークの DNS を追加または変更する場合は、ネットワークの同期操作を実行します。 この操作では、この仮想ネットワークを使用するすべてのアプリが再起動されます。 別のサブスクリプションに属しているアプリと仮想ネットワークを使用している場合、この操作は機能しません。
  • ルートを追加する: ルートを追加すると、送信トラフィックが仮想ネットワークに転送されます。

インスタンスに割り当てられたプライベート IP は、環境変数 WEBSITE_PRIVATE_IP によって公開されます。 Kudu コンソールの UI にも、Web アプリで使用できる環境変数の一覧が表示されます。 この IP は、統合されたサブネットのアドレス範囲から割り当てられます。 リージョン仮想ネットワーク統合の場合、WEBSITE_PRIVATE_IP の値は、委任されたサブネットのアドレス範囲の IP になります。 ゲートウェイが必要な仮想ネットワーク統合の場合、この値は、仮想ネットワーク ゲートウェイに構成されているポイント対サイト アドレス プールのアドレス範囲の IP になります。 この IP は、Azure 仮想ネットワークを通じてリソースに接続するために Web アプリで使用されます。

Note

WEBSITE_PRIVATE_IP の値は、必ず変更されます。 ただし、これは統合サブネットまたはポイント対サイトのアドレス範囲内の IP であるため、アドレス範囲全体からのアクセスを許可する必要があります。

ゲートウェイが必要な仮想ネットワーク統合のルーティング

仮想ネットワークで定義されているルートが、アプリから仮想ネットワークにトラフィックを転送するために使用されます。 仮想ネットワークに追加の送信トラフィックを送信するには、ここでそれらのアドレス ブロックを追加します。 この機能は、ゲートウェイが必要な仮想ネットワーク統合でのみ動作します。 ゲートウェイが必要な仮想ネットワーク統合を使用すると、リージョン仮想ネットワーク統合の場合とは異なり、ルート テーブルによるアプリのトラフィックへの影響はありません。

ゲートウェイが必要な仮想ネットワーク統合の証明書

ゲートウェイが必要な仮想ネットワーク統合が有効になっている場合は、接続のセキュリティを確保するために証明書の交換が必要です。 証明書と共に、DNS の構成、ルート、ネットワークについて記述するその他の同様の情報があります。

証明書またはネットワーク情報が変更された場合は、 [ネットワークの同期] を選択します。 [ネットワークの同期] を選択すると、アプリと仮想ネットワークの間の接続が短時間途切れます。 アプリは再起動されませんが、接続が切れることによって、サイトが正常に機能しなくなる可能性があります。

価格の詳細

リージョン仮想ネットワーク統合機能には、App Service プランの価格レベルの料金を超える追加の使用料金はありません。

ゲートウェイが必要な仮想ネットワーク統合機能の使用には、3 つの料金が関連します。

  • App Service プランの価格レベルの料金: アプリは、Basic、Standard、Premium、Premium v2、または Premium v3 の App Service プランに属している必要があります。 コストについて詳しくは、「App Service の価格」をご覧ください。
  • データ転送コスト: 仮想ネットワークが同じデータ センター内にある場合でも、データのエグレスには料金がかかります。 それらの料金については、データ転送価格の詳細に関するページをご覧ください。
  • VPN Gateway のコスト: ポイント対サイト VPN に必要な仮想ネットワーク ゲートウェイに対して費用がかかります。 詳細については、「VPN Gateway の価格」を参照してください。

トラブルシューティング

Note

仮想ネットワーク統合は、App Service の Docker Compose シナリオではサポートされていません。 プライベート エンドポイントが存在する場合、アクセス制限は無視されます。

機能は簡単にセットアップできますが、問題が発生しないという意味ではありません。 目的のエンドポイントへのアクセスに関して問題が発生した場合は、アプリのコンソールからの接続をテストするために、いくつかのユーティリティを利用できます。 利用できるコンソールが 2 つあります。 1 つは Kudu コンソールで、もう 1 つは Azure portal 内のコンソールです。 アプリから Kudu コンソールにアクセスするには、[ツール][Kudu] の順に移動します。 [サイト名].scm.azurewebsites.net で Kudo コンソールにアクセスすることもできます。 Web サイトが読み込まれたら、[デバッグ コンソール] タブに移動します。お使いのアプリから Azure portal にホストされたコンソールにアクセスするには、[ツール][コンソール] の順に移動します。

ツール

ネイティブ Windows アプリでは、pingnslookuptracert の各ツールは、セキュリティの制約により、コンソールから使用することはできません (カスタム Windows コンテナーで動作します)。 それを補うために、2 つの独立したツールが追加されています。 DNS 機能をテストするために、nameresolver.exe という名前のツールを追加しました。 構文は次のとおりです。

nameresolver.exe hostname [optional: DNS Server]

nameresolver を使用すると、アプリが依存しているホスト名を確認できます。 この方法によって、DNS の構成に誤りがあるかどうかや、DNS サーバーへのアクセス権がないかどうかをテストできます。 環境変数 WEBSITE_DNS_SERVER と WEBSITE_DNS_ALT_SERVER を調べることによって、アプリによって使用される DNS サーバーをコンソール上で確認できます。

Note

nameresolver.exe ツールは現在の、カスタム Windows コンテナーでは動作しません。

次のツールを使用して、ホストとポートを組み合わせたものへの TCP 接続をテストすることができます。 このツールは tcpping という名前で、構文は次のとおりです。

tcpping.exe hostname [optional: port]

tcpping ユーティリティを使用すると、特定のホストとポートにアクセスできるかどうかがわかります。 成功として示されるのは、ホストとポートの組み合わせでリッスンしているアプリケーションがあり、アプリから指定のホストとポートへのネットワーク アクセスがある場合のみです。

仮想ネットワークによってホストされたリソースへのアクセスをデバッグする

さまざまな要因によって、アプリから特定のホストとポートへのアクセスが妨げられる場合があります。 ほとんどの場合は、次のいずれかに該当します。

  • ファイアウォールがルートを塞いでいる。 ルートを塞いでいるファイアウォールがあると、TCP タイムアウトに達します。 この場合の TCP タイムアウトは 21 秒です。 tcpping ツールを使用して接続をテストします。 TCP タイムアウトには、ファイアウォール以外にさまざまな要因が考えられますが、まずはここから開始します。
  • DNS にアクセスできない。 DNS タイムアウトは、DNS サーバーごとに 3 秒です。 2 つの DNS サーバーがある場合、タイムアウトは 6 秒です。 nameresolver を使用して、DNS が機能しているかどうかを確認します。 nslookup では仮想ネットワークの構成に使用されている DNS を利用しないため、nslookup を使うことはできません。 アクセスできない場合は、ファイアウォールが存在するか、NSG が DNS へのアクセスをブロックしているか、または DNS が停止している可能性があります。

これらの項目が問題の回答になっていない場合は、まず次のような点を確認してください。

リージョン仮想ネットワーク統合

  • 宛先は RFC1918 以外のアドレスであり、 [すべてルーティング] が有効になっていないこと。
  • 統合サブネットからのエグレスをブロックしている NSG は存在するか。
  • Azure ExpressRoute または VPN をまたがって移動する場合は、オンプレミスのゲートウェイがトラフィック バックアップを Azure にルーティングするように構成されているか。 仮想ネットワーク内のエンドポイントには到達できるが、オンプレミスに到達できない場合は、ルートを確認します。
  • 統合サブネットに委任を設定するための十分なアクセス許可があるか。 リージョン仮想ネットワーク統合が構成されている間、統合サブネットは Microsoft.Web/serverFarms に委任されます。 VNet 統合 UI では、Microsoft.Web/serverFarms に対するサブネットが自動的に委任されます。 アカウントに委任を設定するための十分なネットワークのアクセス許可がない場合は、サブネットを委任するために、統合サブネットに属性を設定できるユーザーが必要になります。 統合サブネットを手動で委任するには、Azure Virtual Network サブネット UI にアクセスして、Microsoft.Web/serverFarms の委任を設定します。

ゲートウェイが必要な仮想ネットワーク統合

  • ポイント対サイトのアドレス範囲が RFC 1918 の範囲 (10.0.0.0-10.255.255.255/172.16.0.0-172.31.255.255/192.168.0.0-192.168.255.255) にあるか。
  • ゲートウェイはポータル上に稼働中として表示されているか。 ゲートウェイがダウンしている場合は、再起動してください。
  • 証明書は同期していると表示されているか。または、ネットワーク構成が変更されたことが疑われるか。 証明書が同期していないか、または ASP と同期していない仮想ネットワーク構成への変更が行われたことが疑われる場合は、 [ネットワークの同期] を選択します。
  • VPN をまたがって移動する場合は、オンプレミスのゲートウェイがトラフィック バックアップを Azure にルーティングするように構成されているか。 仮想ネットワーク内のエンドポイントには到達できるが、オンプレミスに到達できない場合は、ルートを確認します。
  • ポイント対サイトと ExpressRoute の両方をサポートする共存ゲートウェイを使用しようとしているか。 仮想ネットワーク統合では、共存ゲートウェイはサポートされていません。

ホストとポートの特定の組み合わせへのアクセスが何によってブロックされているかを確認できないため、ネットワークに関する問題のデバッグは厄介です。 次のような原因が考えられます。

  • ホスト上で稼働しているファイアウォールが、ポイント対サイト IP の範囲からアプリケーション ポートへのアクセスを妨げている。 サブネットの境界を越えるには、多くの場合、パブリック アクセスが必要になります。
  • ターゲット ホストがダウンしている。
  • アプリケーションがダウンしている。
  • IP またはホスト名が誤っている。
  • アプリケーションが予期しないポートでリッスンしている。 エンドポイント ホストで "netstat-aon" を使用することで、プロセス ID と、リッスンしているポートを一致させることができます。
  • ネットワーク セキュリティ グループが、ポイント対サイト IP の範囲からアプリケーション ホストとポートへのアクセスを妨げる手法で構成されている。

アプリによって実際にどのアドレスが使用されるかを把握することはできません。 統合サブネットまたはポイント対サイトのアドレス範囲内の任意のアドレスである可能性があるため、アドレス範囲全体からのアクセスを許可する必要があります。

その他のデバッグ手順は次のとおりです。

  • 仮想ネットワーク内の VM に接続し、そこからリソースのホスト:ポートへのアクセスを試みます。 TCP アクセスのテストには、PowerShell コマンド Test-NetConnection を使用します。 構文は次のとおりです。
Test-NetConnection hostname [optional: -Port]
  • VM 上でアプリケーションを起動し、tcpping を使用して、アプリのコンソールからそのホストとポートへのアクセスをテストします。

オンプレミスのリソース

アプリからオンプレミスのリソースにアクセスできない場合は、仮想ネットワークからリソースにアクセスできるかどうかを確認します。 TCP アクセスを確認するには、PowerShell コマンド Test-NetConnection を使用します。 VM からオンプレミス リソースに到達できない場合は、VPN または ExpressRoute 接続が正しく構成されていない可能性があります。

仮想ネットワークでホストされている VM からオンプレミス システムにアクセスでき、アプリからはアクセスできない場合、以下のいずれかの理由が原因と考えられます。

  • オンプレミスのゲートウェイで、ルートがサブネットまたはポイント対サイトのアドレス範囲に構成されていない。
  • ネットワーク セキュリティ グループによって、ポイント対サイト IP 範囲へのアクセスがブロックされている。
  • オンプレミスのファイアウォールによって、ポイント対サイト IP 範囲からのトラフィックがブロックされている。
  • リージョン仮想ネットワーク統合機能を使用して、RFC 1918 以外のアドレスへのアクセスを試みている。

VNet 統合を切断する前に App Service プランまたは Web アプリを削除する

最初に VNet 統合を切断せずに Web アプリまたは App Service プランを削除した場合、削除したリソースとの統合に使用された仮想ネットワークまたはサブネットに対して、更新または削除操作を実行することはできません。 サブネット委任 'Microsoft. Web/serverFarms' はサブネットに割り当てられたままになり、更新または削除操作を実行できなくなります。

サブネットまたは仮想ネットワークをもう一度更新または削除するには、VNet 統合を再作成してから切断する必要があります。

  1. App Service プランと Web アプリを再作成します (以前とまったく同じ Web アプリ名を使用する必要があります)。
  2. Web アプリの [ネットワーク] ブレードに移動し、VNet 統合を構成します。
  3. VNet 統合を構成したら、[切断] ボタンを選びます。
  4. App Service プランまたは Web アプリを削除します。
  5. サブネットまたは仮想ネットワークを更新または削除します。

上記の手順に従った後も VNet 統合に関する問題が引き続き発生する場合は、Microsoft サポートにお問い合わせください。