ゲートウェイが必要な仮想ネットワーク統合を構成する

  • [アーティクル]

ゲートウェイが必要な仮想ネットワーク統合では、別のリージョンの仮想ネットワークまたはクラシック仮想ネットワークへの接続がサポートされています。 ゲートウェイが必要な仮想ネットワーク統合は、Windows プランでのみ機能します。 仮想ネットワークと統合するには、リージョン仮想ネットワーク統合を使うことをお勧めします。

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

  • アプリでは一度に 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 クライアント用のカスタム ルートをアドバタイズする」の手順を使用して、ポイント対サイト構成で手動で反映する必要があります。

Note

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

ピアリング

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

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

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

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

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

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

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

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

Note

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

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

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

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

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

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

証明書の更新

ゲートウェイが必要な仮想ネットワーク統合で使用される証明書の有効期間は 8 年です。 有効期間の長い、ゲートウェイに必要な仮想ネットワーク統合を使用するアプリがある場合には、証明書を更新する必要があります。 Azure portal の VNet 統合ページにアクセスして、証明書の有効期限が切れているか、有効期限が 6 か月未満であるかどうかを検証できます。

有効期限が近づいている、ゲートウェイに必要な仮想ネットワーク統合証明書を示すスクリーンショット。

有効期限が近い証明書または期限切れの証明書がポータルに表示されたら、証明書を更新できます。 証明書を更新するには、仮想ネットワークを切断して再接続する必要があります。 再接続では、アプリと仮想ネットワークの間の接続が短時間途切れます。 アプリは再起動されませんが、接続が切れることによって、サイトが正常に機能しなくなる可能性があります。

価格の詳細

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

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

トラブルシューティング

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

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

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

  • ポイント対サイトのアドレス範囲が 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 以外のアドレスへのアクセスを試みている。

詳しくは、仮想ネットワーク統合のトラブルシューティング ガイドに関する記事をご覧ください。