次の方法で共有

仮想ネットワークとAzure App Serviceの統合のトラブルシューティング

  • [アーティクル]

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

注:

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

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

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

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

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

Kudu コンソールにアクセスするには、Azure portalでアプリ サービスを選択し、[開発ツール] に移動し、[高度なツール] を選択して、[Go] を選択します。 Kudu サービス ページで、[ツール>] [デバッグ コンソール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 を確認する

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

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

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

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

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

DNS 機能をテストするには、 nameresolver.exeを使用できます。 構文は次のようになります。

nameresolver.exe hostname [optional:DNS Server]

nameresolver を使用して、アプリが依存するホスト名をチェックできます。 これにより、DNS で正しく構成されていないか、DNS サーバーにアクセスできない可能性があるかどうかをテストできます。 アプリで使用する DNS サーバーは、環境変数のWEBSITE_DNS_SERVERとWEBSITE_DNS_ALT_SERVERを確認することで、コンソールで確認できます。

注:

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

ホストとポートの組み合わせへの TCP 接続をテストするには、 tcpping を使用します。 構文は です。

tcpping.exe hostname [optional: port]

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

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

で Kudu に直接 [sitename].scm.azurewebsites.net移動します。 Kudu サービス ページで、[ツール>] [デバッグ コンソールCMD] の順に選択します>。

DNS 機能をテストするには、 コマンド nslookup を使用します。 構文は次のようになります。

nslookup hostname [optional:DNS Server]

上記の結果に応じて、DNS サーバーに正しく構成されていない場合は、チェックできます。

注:

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

接続をテストするには、 Curl コマンドを使用します。 構文は次のようになります。

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

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

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

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

これらの項目が問題に回答しない場合は、最初に次のようなものを探します。

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

  • 宛先がRFC1918以外のアドレスであり、 Route All が有効になっていないか。
  • 統合サブネットからの 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でネットワーク トラブルシューティング ツールを開く方法を示すスクリーンショット。

注:

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

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

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

構成の問題 - このトラブルシューティング ツールは、サブネットが仮想ネットワーク統合に有効な場合にチェックされます。

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

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

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

ネットワーク トレースを収集する

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

注:

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

Windows App Services

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

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

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

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

Linux App Services

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

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

    apt-get update
apt install tcpdump

  2. Secure Shell Protocol (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 フィードバック コミュニティに製品フィードバックを送信することもできます。