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

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

Azure App Service では、VNet 統合機能に次の 2 つのバリエーションがあります。

  • Isolated を除くすべての価格プランをサポートするマルチテナント システム
  • VNet にデプロイされ、Isolated 価格プランのアプリをサポートする App Service Environment。

VNet 統合機能はマルチテナント アプリで使用されます。 アプリが App Service Environment 内にある場合、そのアプリは既に VNet 内に存在するため、同じ VNet 内のリソースに到達するために VNet 統合機能を使用する必要はありません。 すべてのネットワーク機能の詳細については、「App Service のネットワーク機能」を参照してください。

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

  • リージョン VNet 統合:同じリージョン内の Azure Resource Manager 仮想ネットワークに接続する場合、統合する VNet での専用のサブネットが必要になります。
  • ゲートウェイが必要な VNet 統合:他のリージョン内の VNet または同じリージョン内のクラシック仮想ネットワークに接続する場合、ターゲットの VNet にプロビジョニングされた Azure 仮想ネットワーク ゲートウェイが必要です。

以下は、VNet 統合機能の特徴です。

  • Standard、Premium、PremiumV2、PremiumV3、または Elastic Premium の価格プランが必要である。
  • TCP と UDP をサポートする。
  • Azure App Service アプリや関数アプリで動作する。

以下のような一部の機能は、VNet 統合ではサポートされません。

  • ドライブのマウント。
  • Active Directory 統合。
  • NetBIOS。

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

使用されているバージョンに関係なく、VNet 統合によってアプリに VNet 内のリソースへのアクセスが付与されますが、VNet からアプリへの受信プライベート アクセスは付与されません。 プライベート サイト アクセスとは、Azure VNet 内など、プライベート ネットワークのみからアプリにアクセスできるようにすることです。 Vnet 統合は、アプリから VNet への送信呼び出しを行うためにのみ存在します。

VNET 統合を有効にする

  1. App Service ポータルで [ネットワーク] の UI に移動します。 [VNet 統合] の下の [ここをクリックして構成] を選択します。

  2. [Add VNet](VNet の追加) を選択します。

    Vnet 統合を選択する

  3. ドロップダウン リストには、お使いのサブスクリプションで同じリージョンに存在するすべての Azure Resource Manager 仮想ネットワークが含まれます。 その下に、他のすべてのリージョンの Resource Manager 仮想ネットワークの一覧が表示されます。 統合する VNet を選択します。

    VNet の選択

    • 同じリージョン内の VNet の場合は、新しいサブネットを作成するか、空の既存のサブネットを選択します。
    • 別のリージョンの VNet を選択するには、ポイント対サイトが有効になっている VNet ゲートウェイがプロビジョニングされている必要があります。
    • クラシック VNet と統合するには、 [仮想ネットワーク] ドロップダウン リストを選択するのではなく、 [クラシック VNet に接続するには、ここをクリックします] を選択します。 使用するクラシック仮想ネットワークを選択します。 ターゲットの VNet には、ポイント対サイトが有効になっている Virtual Network ゲートウェイがプロビジョニングされている必要があります。

    クラシック VNet の選択

統合中にアプリは再起動されます。 統合が完了すると、統合されている VNet の詳細が表示されます。

リージョン VNet 統合

リージョン VNet 統合を使用すると、アプリは次のものにアクセスできるようになります。

  • アプリと同じリージョンにある VNet 内のリソース。
  • VNet 内のリソースは、アプリが統合されている VNet とピアリングされます。
  • サービス エンドポイントでセキュリティ保護されたサービス。
  • Azure ExpressRoute 接続にまたがるリソース。
  • 統合されている VNet 内のリソース。
  • Azure ExpressRoute 接続を含む、ピアリングされた接続にまたがるリソース。
  • プライベート エンドポイント

同じリージョンの VNet との VNet 統合を使用する場合は、次の Azure ネットワーク機能を使用できます。

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

既定では、アプリでは RFC1918 トラフィックのみが VNet にルーティングされます。 すべての送信トラフィックを VNet にルーティングする場合は、次の手順を使用して WEBSITE_VNET_ROUTE_ALL 設定をアプリに適用します。

  1. アプリ ポータルの [構成] UI にアクセスします。 [新しいアプリケーション設定] を選択します。

  2. [名前] ボックスに「WEBSITE_VNET_ROUTE_ALL」、 [値] ボックスに「1」と入力します。

    アプリケーション設定を指定する

  3. [OK] を選択します。

  4. [保存] を選択します。

注意

すべての送信トラフィックを VNet にルーティングする場合は、統合サブネットに適用されている NSG と UDR に従います。 WEBSITE_VNET_ROUTE_ALL1 に設定しても、トラフィックを他の場所に送信するルートを指定しない限り、送信トラフィックはアプリのプロパティに一覧表示されているアドレスから送信されます。

リージョン VNet 統合では、ポート 25 を使用できません。

同じリージョンの VNet との VNet 統合を使用する場合、いくつかの制限があります。

  • グローバル ピアリング接続にまたがるリソースには到達できません。
  • この機能は、Premium V2 と Premium V3 のすべての App Service スケール ユニットから使用できます。 また、Standard でも使用できますが、新しい App Service のスケール ユニットからのみ利用できます。 以前のスケール ユニットを使用している場合は、Premium V2 App Service プランの機能のみを使用できます。 Standard App Service プランでこの機能を使用できるようにするには、Premium V3 App Service プランでアプリを作成します。 それらのプランは、最新のスケール ユニットでのみサポートされます。 その後、必要に応じてスケールダウンできます。
  • 統合サブネットは、1 つの App Service プランでしか使用できません。
  • この機能は、App Service Environment にある Isolated プランのアプリでは使用できません。
  • この機能には、Azure Resource Manager VNet 内に /28 以上の未使用のサブネットが必要です。
  • アプリと VNet は同じリージョンに存在する必要があります。
  • 統合アプリで VNet を削除することはできません。 VNet を削除する前に、統合を削除してください。
  • App Service プランごとに 1 リージョンの VNet 統合のみを持つことができます。 同じ App Service プラン内の複数のアプリが同じ VNet を使用できます。
  • リージョン VNet 統合を使用しているアプリがあるときに、アプリまたはプランのサブスクリプションを変更することはできません。
  • アプリでは、構成を変更せずに Azure DNS Private Zones のアドレスを解決することはできません。

VNet 統合は、専用サブネットに依存します。 サブネットをプロビジョニングすると、Azure サブネットは先頭から 5 つの IP を失います。 プラン インスタンスごとに、統合サブネットから 1 つのアドレスが使用されます。 アプリを 4 つのインスタンスにスケールする場合は、4 つのアドレスが使用されます。

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

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

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

割り当てた後はサブネット サイズを変更できないため、アプリが到達する可能性のあるスケールに対応できるだけの十分な大きさを持つサブネットを使用してください。 サブネット容量に関する問題を回避するには、64 個のアドレスを持つ /26 を使用する必要があります。

別のプラン内のご自身のアプリが、別のプラン内のアプリから既に接続されている VNet にアクセスできるようにしたい場合は、既存の VNet 統合によって使用されているものとは異なるサブネットを選択します。

この機能は、カスタム コンテナーを含め、Windows と Linux の両方のアプリで完全にサポートされています。 すべての動作は、Windows アプリと Linux アプリ間で同じです。

サービス エンドポイント

リージョン VNet 統合を使用すると、サービス エンドポイントで保護されている Azure サービスに接続できます。 サービス エンドポイントで保護されたサービスにアクセスするには、次の操作を行う必要があります。

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

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

ネットワーク セキュリティ グループを使用して、VNet 内のリソースへの受信および送信トラフィックをブロックできます。 リージョン VNet 統合を使用するアプリでは、ネットワーク セキュリティ グループを使用して、VNet またはインターネット内のリソースへの送信トラフィックをブロックできます。 パブリック アドレスへのトラフィックをブロックするには、アプリケーション設定 WEBSITE_VNET_ROUTE_ALL1 に設定する必要があります。 VNet 統合はアプリからの送信トラフィックのみに影響を与えるため、NSG での受信規則はアプリに適用されません。

アプリへの受信トラフィックを制御するには、アクセス制限機能を使用します。 統合サブネットに適用される NSG は、統合サブネットに適用されているルートに関係なく有効になります。 WEBSITE_VNET_ROUTE_ALL1 に設定されていて、統合サブネット上でパブリック アドレス トラフィックに影響を与えるルートがない場合、すべての送信トラフィックは引き続き、統合サブネットに割り当てられた NSG に従います。 WEBSITE_VNET_ROUTE_ALL が設定されていない場合、NSG は RFC1918 トラフィックにのみ適用されます。

ルート

ルート テーブルを使用して、アプリからの送信トラフィックを任意の場所にルーティングすることができます。 既定では、ルート テーブルは、RFC1918 の送信先トラフィックのみに影響を与えます。 WEBSITE_VNET_ROUTE_ALL1 に設定すると、すべての送信呼び出しが影響を受けます。 統合サブネット上に設定されているルートは、受信アプリ要求への応答には影響を与えません。 一般的な宛先には、ファイアウォール デバイスまたはゲートウェイを含めることができます。

オンプレミスのすべての送信トラフィックをルーティングする場合は、ルート テーブルを使用して、すべての送信トラフィックを ExpressRoute ゲートウェイに送信できます。 ゲートウェイにトラフィックをルーティングする場合は、外部ネットワークのルートを設定して、応答を返信するようにしてください。

また、Border Gateway Protocol (BGP) ルートも、アプリのトラフィックに影響を与えます。 ExpressRoute ゲートウェイのようなものから BGP ルートを使用している場合は、アプリの送信トラフィックが影響を受けます。 既定では、BGP ルートは、RFC1918 の送信先トラフィックにのみ影響を与えます。 WEBSITE_VNET_ROUTE_ALL1 に設定されている場合、すべての送信トラフィックは、BGP ルートの影響を受ける可能性があります。

Azure DNS プライベート ゾーン

アプリでは、VNet に統合された後、VNet が構成されているのと同じ DNS サーバーが使用されます。 既定では、アプリは Azure DNS プライベート ゾーンで動作しません。 Azure DNS プライベート ゾーンで動作させるには、次のアプリ設定を追加する必要があります。

  1. WEBSITE_DNS_SERVER (値 168.63.129.16)
  2. WEBSITE_VNET_ROUTE_ALL (値 1)

これらの設定により、アプリからのすべての送信呼び出しが VNet に送信され、アプリから Azure DNS プライベート ゾーンにアクセスできるようになります。 これらの設定を使用すると、アプリは、ワーカー レベルで DNS プライベート ゾーンを照会することによって、Azure DNS を使用できます。

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

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

  • Azure DNS プライベート ゾーンと統合する。 VNet にカスタム DNS サーバーがない場合、これは自動的に行われます。
  • アプリで使用される DNS サーバーでプライベート エンドポイントを管理する。 これを行うには、プライベート エンドポイント アドレスを把握し、到達しようとしているエンドポイントが A レコードを使用してそのアドレスにポイントされるようにします。
  • Azure DNS プライベート ゾーンに転送する独自の DNS サーバーを構成する。

リージョン VNET 統合のしくみ

App Service 内のアプリは、worker ロールでホストされます。 Basic 以上の価格プランは、同じ worker 上で他の顧客のワークロードが実行されない専用のホスティング プランです。 リージョン VNet 統合は、委任されたサブネット内のアドレスで仮想インターフェイスをマウントすることによって機能します。 送信元アドレスは VNet 内に存在するため、VNet 内の VM と同様に、VNet 内または VNet 経由でほとんどの場所にアクセスできます。 ネットワークの実装は、VNet で VM を実行する場合とは異なります。 そのため、一部のネットワーク機能はこの機能ではまだ使用できません。

リージョン VNET 統合のしくみ

リージョン VNet 統合が有効になっているとき、アプリによるインターネットへの送信呼び出しは、通常と同じチャネル経由で行われます。 アプリのプロパティ ポータルに一覧表示される送信アドレスは、引き続きそのアプリによって使用されるアドレスです。 アプリに関する変更は、サービス エンドポイントのセキュリティ保護されたサービスつまり RFC 1918 アドレスへの呼び出しが、VNet に転送されることです。 WEBSITE_VNET_ROUTE_ALL が 1 に設定されている場合、すべての送信トラフィックを VNet 内に送信できます。

注意

WEBSITE_VNET_ROUTE_ALL は、現在 Windows コンテナーではサポートされていません。

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

このテクノロジが動作する方法の性質のために、VNet 統合で使用されるトラフィックは Azure Network Watcher や NSG フローのログには表示されません。

ゲートウェイが必要な VNet 統合

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

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

ゲートウェイが必要な VNet 統合は次の場合は使用できません。

  • Azure ExpressRoute で接続された VNet に対して。
  • Linux アプリから。
  • Windows コンテナーから。
  • サービス エンドポイントによって保護されているリソースにアクセスする場合。
  • ExpressRoute とポイント対サイトまたはサイト間 VPN の両方をサポートする共存ゲートウェイに対して。

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

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

  1. VNet 内にゲートウェイ サブネットを作成します。

  2. VPN ゲートウェイを作成します。 VPN の種類はルート ベースを選択します。

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

App Service の VNet 統合で使用するゲートウェイを作成する場合は、証明書をアップロードする必要はありません。 ゲートウェイの作成には 30 分かかることがあります。 ゲートウェイがプロビジョニングされるまで、アプリを VNet に統合することはできません。

ゲートウェイが必要な VNet 統合のしくみ

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

ゲートウェイが必要な VNet 統合のしくみ

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

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

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

注意

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

ピアリング

リージョン VNet 統合でピアリングを使用する場合、追加の構成を行う必要はありません。

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

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

VNet 統合を管理する

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

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

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

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

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

注意

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

ゲートウェイが必要な VNET 統合のルーティング

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

ゲートウェイが必要な VNet 統合の証明書

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

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

価格の詳細

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

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

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

トラブルシューティング

注意

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

機能は簡単にセットアップできますが、問題が発生しないという意味ではありません。 目的のエンドポイントへのアクセスに関して問題が発生した場合は、アプリのコンソールからの接続をテストするために、いくつかのユーティリティを利用できます。 利用できるコンソールが 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 サーバーをコンソール上で確認できます。

注意

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 が停止している可能性があります。

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

リージョン VNet 統合

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

ゲートウェイが必要な VNet 統合

  • ポイント対サイトのアドレス範囲が 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 の両方をサポートする共存ゲートウェイを使用しようとしているか。 VNet 統合では、共存ゲートウェイはサポートされていません。

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

  • ホスト上で稼働しているファイアウォールが、ポイント対サイト 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 範囲からのトラフィックがブロックされている。
  • リージョン VNet 統合機能を使用して、RFC 1918 以外のアドレスへのアクセスを試みている。

オートメーション

リージョン VNet 統合では CLI がサポートされています。 次のコマンドにアクセスするには、Azure CLI をインストールします。

az webapp vnet-integration --help

Group
    az webapp vnet-integration : Methods that list, add, and remove virtual network
    integrations from a webapp.
        This command group is in preview. It may be changed/removed in a future release.
Commands:
    add    : Add a regional virtual network integration to a webapp.
    list   : List the virtual network integrations on a webapp.
    remove : Remove a regional virtual network integration from webapp.

az appservice vnet-integration --help

Group
    az appservice vnet-integration : A method that lists the virtual network
    integrations used in an appservice plan.
        This command group is in preview. It may be changed/removed in a future release.
Commands:
    list : List the virtual network integrations used in an appservice plan.

リージョン VNet 統合では PowerShell のサポートも提供されていますが、サブネットの resourceID のプロパティ配列を使用して汎用のリソースを作成する必要があります

# Parameters
$sitename = 'myWebApp'
$resourcegroupname = 'myRG'
$VNetname = 'myVNet'
$location = 'myRegion'
$integrationsubnetname = 'myIntegrationSubnet'
$subscriptionID = 'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee'

#Property array with the SubnetID
$properties = @{
  subnetResourceId = "/subscriptions/$subscriptionID/resourceGroups/$resourcegroupname/providers/Microsoft.Network/virtualNetworks/$VNetname/subnets/$integrationsubnetname"
}

#Creation of the VNet integration
$vNetParams = @{
  ResourceName = "$sitename/VirtualNetwork"
  Location = $location
  ResourceGroupName = $resourcegroupname
  ResourceType = 'Microsoft.Web/sites/networkConfig'
  PropertyObject = $properties
}
New-AzResource @vNetParams

ゲートウェイが必要な VNet 統合では、PowerShell を使用して App Service を Azure 仮想ネットワークと統合できます。 すぐに使用できるスクリプトについては、「Azure App Service のアプリを Azure 仮想ネットワークに接続する」をご覧ください。