次の方法で共有

仮想ネットワークを Azure App Service に統合する際のトラブルシューティング

  • [アーティクル]

この記事では、仮想ネットワークと統合Azure アプリ サービスの接続に関する問題のトラブルシューティングに使用できるツールについて説明。

Note

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

仮想ネットワーク統合を確認する

接続の問題をトラブルシューティングするには、まず、仮想ネットワーク統合が正しく構成されているかどうか、およびプライベート IP が App Service プランのすべてのインスタンスに割り当てられているかどうかを確認する必要があります。

これを行うには、以下のいずれかの方法を使用します。

Kudu デバッグ コンソールでプライベート IP を確認する

Kudu コンソールにアクセスするには、Azure portal でアプリ サービスを選択し、 Development Tools に移動し、 Advanced Tools を選択してから、 Go を選択します。 Kudu サービス ページで、 Tools>Debug Console>CMD を選択します。

Azure portal で Kudu サービス ページを開く方法を示すスクリーンショット。

URL [sitename].scm.azurewebsites.net/DebugConsoleで直接 Kudu デバッグ コンソールに移動することもできます。

デバッグ コンソールで、次のいずれかのコマンドを実行します。

Windows OS ベースのアプリ

SET WEBSITE_PRIVATE_IP

プライベート IP が正常に割り当てられている場合は、次の出力が表示されます。

WEBSITE_PRIVATE_IP=<IP address>

Linux OS ベースのアプリ

set| egrep --color 'WEBSITE_PRIVATE_IP'

Kudu 環境でプライベート IP を確認する

[sitename].scm.azurewebsites.net/Envで Kudu 環境に移動し、WEBSITE_PRIVATE_IPを検索します。

仮想ネットワーク統合が正常に構成されていることを確認したら、接続テストに進むことができます。

Windows Apps での送信接続のトラブルシューティング

ネイティブ Windows アプリでは、ツールの、nslookup、および tracert は、セキュリティ上の制約のためにコンソールを介して機能しません (カスタム Windows コンテナーで動作します)。

[sitename].scm.azurewebsites.net/DebugConsoleで直接 Kudu コンソールに移動します。

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

Linux Apps での送信接続のトラブルシューティング

[sitename].scm.azurewebsites.netから直接 Kudu に移動します。 Kudu サービス ページで、 Tools>Debug Console>CMD を選択します。

DNS 機能をテストするには、コマンド nslookupを使用できます。 構文は次のとおりです。

nslookup hostname [optional:DNS Server]

上記の結果に応じて、DNS サーバーに正しく構成されていないかどうかを確認できます。

Note

現在、nameresolver.exe ツールは Linux アプリでは機能しません。

接続をテストするには、 Curl コマンドを使用できます。 構文は次のとおりです。

curl -v https://hostname
curl hostname:[port]

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

さまざまな要因により、アプリが特定のホストとポートに到達できなくなる可能性があります。 ほとんどの場合、次のいずれかです。

  • ファイアウォールがルートを塞いでいる。 ルートを塞いでいるファイアウォールがあると、TCP タイムアウトに達します。 この場合の TCP タイムアウトは 21 秒です。 tcpping ツールを使用して接続をテストします。 TCP タイムアウトには、ファイアウォール以外にさまざまな要因が考えられますが、まずはここから開始します。
  • DNS にアクセスできない。 DNS タイムアウトは、DNS サーバーごとに 3 秒です。 2 つの DNS サーバーがある場合、タイムアウトは 6 秒です。 nameresolver を使用して、DNS が動作しているかどうかを確認します。 仮想ネットワークが構成されている DNS を使用しないため、nslookup を使用できません。 アクセスできない場合は、ファイアウォールまたは NSG が DNS へのアクセスをブロックしているか、ダウンしている可能性があります。 カスタム DNS サーバーを使用する一部の DNS アーキテクチャは複雑な場合があり、タイムアウトが発生する場合があります。 これが当てはまるかどうかを判断するために、環境変数 WEBSITE_DNS_ATTEMPTS を設定できます。 App Services の DNS の詳細については、「App Service での Name resolution (DNS)」を参照してください。

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

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

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

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

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

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

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

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

ネットワークのトラブルシューティング ツール

また、ネットワーク トラブルシューティング ツールを使用して、App Service のアプリの接続に関する問題のトラブルシューティングを行うこともできます。 ネットワーク トラブルシューティング ツールを開くには、Azure portal でアプリ サービスに移動します。 [診断と問題の解決] を選択し、ネットワーク トラブルシューティング ツールを検索します。

Azure portal でネットワーク トラブルシューティング ツールを開く方法を示すスクリーンショット。

Note

接続の問題シナリオでは、Linux またはコンテナー ベースのアプリはまだサポートされていません。

接続の問題 - App Service プランのすべてのインスタンスと DNS 設定にプライベート IP が割り当てられているかどうかを確認するなど、仮想ネットワーク統合の状態を確認します。 カスタム DNS が構成されていない場合は、既定の Azure DNS が適用されます。 接続をテストする特定のエンドポイントに対してテストを実行することもできます。

接続の問題に関する実行トラブルシューティング ツールを示すスクリーンショット。

構成の問題 - このトラブルシューティング ツールは、サブネットが仮想ネットワーク統合に対して有効かどうかを確認します。

Azure portal で構成の問題のトラブルシューティング ツールを実行する方法を示すスクリーンショット。

サブネット/VNet の削除の問題 - このトラブルシューティング ツールは、サブネットにロックがあるかどうか、および VNet/サブネットの削除をブロックしている可能性がある未使用のサービス関連付けリンクがあるかどうかを確認します。

サブネットまたは仮想ネットワークの削除に関する問題のトラブルシューティング ツールを実行する方法を示すスクリーンショット。

ネットワーク トレースの収集

ネットワーク トレースの収集は、問題の分析に役立ちます。 Azure アプリ サービスでは、ネットワーク トレースはアプリケーション プロセスから取得されます。 正確な情報を取得するには、ネットワーク トレース収集の開始時に問題を再現します。

Note

仮想ネットワーク トラフィックはネットワーク トレースにキャプチャされません。

Windows App Services

Windows App Services のネットワーク トレースを収集するには、次の手順に従います。

  1. Azure portal で、Web アプリに移動します。
  2. 左側のナビゲーションで、 Diagnose と問題の解決を選択します。
  3. 検索ボックスに「 Collect Network Trace 」と入力し、 Collect Network Trace を選択してネットワーク トレースの収集を開始します。

ネットワーク トレースをキャプチャする方法を示すスクリーンショット。

Web アプリを提供する各インスタンスのトレース ファイルを取得するには、ブラウザーで、Web アプリ (https://<sitename>.scm.azurewebsites.net) の Kudu コンソールに移動します。 トレース ファイルを C:\home\LogFiles\networktrace または D:\home\LogFiles\networktrace フォルダーからダウンロードします。

Linux App Services

カスタム コンテナーを使用しない Linux App Services のネットワーク トレースを収集するには、次の手順に従います。

  1. 次のコマンドを実行して、 tcpdump コマンド ライン ユーティリティをインストールします。

    apt-get update
apt install tcpdump

  2. Secure Shell プロトコル (SSH) を使用してコンテナーに接続します。

  3. 次のコマンド (たとえば、 eth0) を実行して、稼働しているインターフェイスを特定します。

    root@<hostname>:/home# tcpdump -D

1.eth0 [Up, Running, Connected]
2.any (Pseudo-device that captures on all interfaces) [Up, Running]
3.lo [Up, Running, Loopback]
4.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
5.nflog (Linux netfilter log (NFLOG) interface) [none]
6.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
7.dbus-system (D-Bus system bus) [none]
8.dbus-session (D-Bus session bus) [none]

  4. 次のコマンドを実行して、ネットワーク トレースコレクションを開始します。

    root@<hostname>:/home# tcpdump -i eth0 -w networktrace.pcap

    eth0を実際のインターフェイスの名前に置き換えます。

トレース ファイルをダウンロードするには、Kudu、FTP、Kudu API 要求などのメソッドを使用して Web アプリに接続します。 ファイルのダウンロードをトリガーする要求の例を次に示します。

https://<sitename>.scm.azurewebsites.net/api/vfs/<path to the trace file in the /home directory>/filename

サードパーティの情報に関する免責事項

この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。