Network Watcher に関してよく寄せられる質問 (FAQ)

Network Watcher には、メトリックを監視、診断、表示し、IaaS (サービスとしてのインフラストラクチャ) リソース (仮想マシン、仮想ネットワーク、アプリケーション ゲートウェイ、ロード バランサー、Azure 仮想ネットワーク内のその他のリソースを含む) のログを有効または無効にする、一連のツールが用意されています。 PaaS (サービスとしてのプラットフォーム) インフラストラクチャを監視したり、Web/モバイル分析を取得したりするためのソリューションではありません。

Network Watcher には、3 つの主要な機能セットがあります。

• 監視
  • トポロジ ビューには、仮想ネットワーク内のリソースと、リソース間のリレーションシップが表示されます。
  • 接続モニターを使用すると、Azure の内部と外部のエンドポイント間の接続と待機時間を監視できます。
• ネットワーク診断ツール
  • IP フロー検証を使用すると、仮想マシン レベルでトラフィックのフィルター処理に関する問題を検出できます。
  • NSG 診断を使用すると、仮想マシン、仮想マシン スケール セット、またはアプリケーション ゲートウェイのレベルでトラフィックのフィルター処理に関する問題を検出できます。
  • 次ホップは、トラフィックのルートを検証してルーティングの問題を検出するのに役立ちます。
  • 接続のトラブルシューティングを実行すると、仮想マシンと Bastion ホスト、アプリケーション ゲートウェイ、または別の仮想マシンとの間の 1 回限りの接続と待機時間のチェックを実行できます。
  • パケット キャプチャを使用して、仮想マシンのトラフィックをキャプチャできます。
  • VPN のトラブルシューティングでは、VPN ゲートウェイと接続に対して複数の診断チェックを実行し、問題のデバッグに役立てることができます。
• Traffic
  • 仮想ネットワーク フロー ログ と ネットワーク セキュリティ グループ フロー ログ を使用すると、仮想ネットワークとネットワーク セキュリティ グループ (NSG) をそれぞれ通過するネットワーク トラフィックをログに記録できます。
  • Traffic Analytics では、ネットワーク セキュリティ グループ フロー ログのデータを処理して、ネットワーク トラフィックの視覚化、クエリ、分析、解釈を行うことができます。

詳細については、Network Watcher の概要を参照してください。

さまざまな Network Watcher コンポーネントの価格の詳細については、「Network Watcher の価格」を参照してください。

Network Watcher をサポートするリージョンについては、Network Watcher のリージョンに関するページを参照してください。

Network Watcher の各機能に必要なアクセス許可の詳細な一覧については、Network Watcher を使用するために必要な Azure RBAC のアクセス許可に関する記事を参照してください。

Network Watcher サービスは、すべてのサブスクリプションで自動的に有効になります。 Network Watcher の自動有効化をオプトアウトした場合は、手動で Network Watcher を有効にする必要があります。 詳細については、「Azure Network Watcher を有効または無効にする」を参照してください。

Network Watcher の親リソースは、各リージョンで一意のインスタンスを使用してデプロイされます。 既定の名前付け形式: NetworkWatcher_RegionName。 例:NetworkWatcher_centralus は、"米国中部" リージョンの Network Watcher リソースです。 PowerShell または REST API を使用して、Network Watcher インスタンスの名前をカスタマイズできます。

Network Watcher の機能を使用するには、各サブスクリプションでリージョンごとに Network Watcher を 1 回ずつ有効にする必要があります。 Network Watcher インスタンスをリージョン内に作成することで、そのリージョン内で Network Watcher が有効になります。

Network Watcher リソースは、Network Watcher のバックエンドサービスを表し、Azure によって完全に管理されます。 ただし、Network Watcher リソースを作成または削除し、特定のリージョンで有効または無効にできます。 詳細については、「Azure Network Watcher を有効または無効にする」を参照してください。

いいえ、Network Watcher リソースまたはその子リソースのリージョン間での移動はサポートされていません。 詳細については、ネットワークリソースの移動操作のサポートに関する記事を参照してください。

はい。リソース グループ間での Network Watcher リソースの移動がサポートされています。 詳細については、ネットワークリソースの移動操作のサポートに関する記事を参照してください。

NetworkWatcherRG は、Network Watcher リソース用に自動的に作成されるリソース グループです。 たとえば、NetworkWatcherRG リソース グループには、Network Watcher リージョン インスタンスとネットワーク セキュリティ グループ フロー ログ リソースが作成されます。 PowerShell、Azure CLI、または REST API を使用して、Network Watcher リソース グループの名前をカスタマイズできます。

Azure Network Watcher では、接続モニターを除いて、顧客データは格納されません。 接続モニターにより顧客データが格納されます。これは、リージョン内のデータ所在地の要件を満たすために、Network Watcher によって 1 つのリージョンに自動的に格納されます。

Network Watcher には次の制限があります。

はい、Network Watcher サービスは、既定ではゾーン回復性を備えています。

ゾーン回復性を有効にするために、構成は必要ありません。 Network Watcher リソースのゾーン回復性は、既定で使用できるようになっており、サービス自体によって管理されます。

Network Watcher Agent は、仮想マシンからトラフィックを生成またはインターセプトするすべての Network Watcher 機能に必要です。

接続モニター、パケット キャプチャ、接続のトラブルシューティング (接続テスト) の機能には、Network Watcher 拡張機能が存在している必要があります。

Network Watcher 拡張機能の最新バージョンは 1.4.3614.3 です。 詳細については、Azure Network Watcher 拡張機能を最新バージョンに更新する を参照してください。

• Linux: Network Watcher Agent は、ポート port 50000 から始まり port 65535 に達するまでの利用可能なポートを使用します。
• Windows: Network Watcher Agent は、利用可能なポートのクエリが実行されたときにオペレーティング システムが返すポートを使用します。

Network Watcher Agent では、169.254.169.254 経由での port 80 への、168.63.129.16 経由での port 8037 への送信 TCP 接続が必要です。 エージェントは、これらの IP アドレスを使用して Azure プラットフォームと通信します。

いいえ。接続モニターはクラシック VM をサポートしていません。 詳細については、クラシックから Azure Resource Manager への IaaS リソースの移行に関するページを参照してください。

トポロジは、宛先 Azure リソースと接続モニター リソースが同じリージョンにある場合にのみ Azure 以外から Azure へと装飾できます。

同じ Azure VM を、同じ接続モニター内の異なる構成で使用することはできません。 たとえば、同じ接続モニターで、同じ VM をフィルターありとフィルターなしで使用することはサポートされていません。

接続モニター ダッシュボードに表示される問題は、トポロジの検出またはホップ探索中に見つかったものです。 % loss または RTT に設定されているしきい値に到達したにも関わらず、ホップで問題が見つからない場合があります。

接続モニター (クラシック) にはプロトコルの選択オプションはありません。 接続モニター (クラシック) のテストは TCP プロトコルのみを使用しており、これが移行時に、新しい接続モニターのテストで TCP 構成を作成する理由です。

現在、関連付けられている Log Analytics ワークスペースで Azure Monitor エージェントと Arc エージェントをエンドポイントが使用する場合、リージョンの境界があります。 この制限の結果、関連付けられている Log Analytics ワークスペースは Arc エンドポイントと同じリージョンに存在する必要があります。 個々のワークスペースに取り込まれたデータは、1 つのビューに統合できます。「Azure Monitor 内の Log Analytics ワークスペース、アプリケーション、リソース全体のデータにクエリを実行する」を参照してください。

フロー ログを使用すると、ネットワーク セキュリティ グループまたは Azure 仮想ネットワークを通過する Azure IP トラフィックに関する 5 タプル フロー情報をログに記録できます。 生のフロー ログが Azure Storage アカウントに書き込まれます。 そこから、必要に応じて、さらに処理、分析、クエリ、またはエクスポートを行うことができます。

フロー ログのデータは、ネットワーク トラフィックのパスの外部で収集されるため、ネットワークのスループットや待機時間には影響しません。 ネットワーク パフォーマンスに影響を及ぼす危険性がまったく生じずに、フロー ログを作成または削除できます。

ネットワーク セキュリティ グループのフロー ログには、ネットワーク セキュリティ グループを通過するトラフィックが記録されます。 一方、NSG 診断では、トラフィックが通過しているすべてのネットワーク セキュリティ グループと、このトラフィックに適用される各ネットワーク セキュリティ グループの規則が返されます。 NSG 診断を使用して、ネットワーク セキュリティ グループの規則が想定どおりに適用されていることを確認してください。

いいえ、ネットワーク セキュリティ グループ フロー ログでは、ESP プロトコルと AH プロトコルはサポートされていません。

いいえ、ネットワーク セキュリティ グループ フロー ログと仮想ネットワーク フロー ログでは、ICMP プロトコルはサポートされていません。

はい。 関連付けられているフロー ログ リソースも削除されます。 フロー ログ データは、フロー ログで構成された保持期間のストレージ アカウントに保持されます。

はい。ただし、関連付けられているフロー ログ リソースを削除する必要があります。 ネットワーク セキュリティ グループを移動した後、フロー ログを再作成して、そのグループでのフロー ログを有効にすることができます。

はい。このサブスクリプションがネットワーク セキュリティ グループの同じリージョンにあり、ネットワーク セキュリティ グループまたは仮想ネットワークのサブスクリプションの同じ Microsoft Entra テナントに関連付けられている限り、別のサブスクリプションのストレージ アカウントを使用できます。

ファイアウォールの背後にあるストレージ アカウントを使用するには、 信頼された Azure サービス がストレージ アカウントにアクセスできるようにする必要があります。

1. ポータルの上部にある検索ボックスにストレージ アカウントの名前を入力して、ストレージ アカウントに移動します。
2. [Security + networking] (セキュリティとネットワーク) で、[Networking] (ネットワーク) を選択し、[Firewalls and virtual networks] (ファイアウォールと仮想ネットワーク) を選択します。
3. [公衆ネットワーク アクセス] で [選択した仮想ネットワークと IP アドレスから有効] を選びます。 次に、[例外] で、[信頼されたサービスの一覧にある Azure サービスがこのストレージ アカウントにアクセスすることを許可します] の横のボックスをオンにします。
4. ストレージ アカウントを使用してターゲット リソースのフロー ログを作成して、フロー ログを有効にします。 詳細については、「フロー ログを作成する」を参照してください。

数分後にストレージ ログを確認できます。 更新されたタイム スタンプまたは作成された新しい JSON ファイルが表示されているはずです。

現在、1 つのストレージ アカウントは 100 個のルールをサポートし、各ルールは 10 個の BLOB プレフィックスを含むことができます。 制限に達した場合は、新しい仮想ネットワーク フロー ログを有効にするときにアイテム保持ポリシーを 0 に設定し、サブスクリプションの保持ルールを手動で追加できます。

保持ポリシーサブスクリプションルールを作成するには、次のステップに従ってください。

1. ポータルの上部にある検索ボックスにストレージ アカウントの名前を入力して、ストレージ アカウントに移動します。
2. [ データ管理] で、[ ライフサイクル管理] を選択します。
3. [ + ルールの追加] を選択します。
4. [詳細] セクションで、ルール スコープ:フィルターを使用した BLOB の制限、BLOB の種類:ブロック BLOB、BLOB サブタイプ:ベース BLOB の設定を選択します。
5. [ ベース BLOB ] セクションで、保持設定を構成します。
6. [ フィルター セット ] セクションで、 BLOB プレフィックス を次のように書式設定します。 "insights-logs-flowlogflowevent/flowLogResourceID=/<yourSubscriptionId>_NETWORKWATCHERRG"
7. [] を選択し、[] を追加します。

保持期間が短いルールが優先されます。

Network Watcher には、ファイアウォールの背後にあるストレージ アカウントに接続するときに使用する組み込みのフォールバック メカニズムがあります (ファイアウォールが有効)。 キーを使用してストレージ アカウントへの接続が試行され、失敗した場合はトークンに切り替わります。 この場合、ストレージ アカウントのアクティビティ ログに 403 エラーが記録されます。

はい。Network Watcher では、プライベート エンドポイントで有効になっているストレージ アカウントへのフロー ログ データの送信がサポートされています。

フロー ログは、追加の構成を必要とせずにサービス エンドポイントと互換性があります。 詳細については、「サービス エンドポイントの有効化」を参照してください。

フロー ログ バージョン 2 では、"フロー状態" という概念が導入されており、転送されるバイトとパケットに関する情報が保存されます。 詳細については、「ネットワーク セキュリティ グループ フロー ログの形式」を参照してください。

いいえ、ネットワーク セキュリティ グループの読み取り専用ロックを使用すると、対応するネットワーク セキュリティ グループ フロー ログを作成できなくなります。

はい、ネットワーク セキュリティ グループの削除不可ロックによって、対応するネットワーク セキュリティ グループ フロー ログの作成または変更が妨げられることはありません。

はい、AZURE Resource Manager テンプレート (ARM テンプレート) を使用してネットワーク セキュリティ グループ フロー ログを自動化できます。 詳細については、「Azure Resource Manager (ARM) テンプレートを使用して NSG のフロー ログを構成する」を参照してください。

はい。仮想ネットワークとネットワーク セキュリティ グループは、Log Analytics ワークスペース リージョンとは異なるリージョンに存在できます。

はい。

トラフィック分析ダッシュボードのリソース選択ドロップダウンで、仮想マシンまたはネットワーク セキュリティ グループのリソース グループではなく、 仮想ネットワーク リソースのリソース グループを選択する必要があります。

トラフィック分析では、6 時間ごとにリソース検出スキャンが実行され、新しい VM、NIC、仮想ネットワーク、サブネットが識別されます。 最新の検出サイクルの後に新しい VM または NIC が作成され、次の検出の前にフロー データが収集された場合、トラフィック分析でトラフィックを既知のリソースに関連付けることはできません。 その結果、これらのリソースは分析ビューで一時的に 不明 としてラベル付けされます。

はい。データ収集エンドポイント (DCE) リソースへのパブリック アクセスを無効にして、それに対するパブリック受信トラフィックをブロックできます。 インジェストは、DCE リソースを Azure Monitor Private Link スコープに関連付けずに引き続き機能します。

はい。 既存のワークスペースを選択する場合は、新しいクエリ言語に移行されていることを確認します。 ワークスペースをアップグレードしない場合は、新しいワークスペースを作成する必要があります。 Kusto クエリ言語 (KQL) の詳細については、「 Azure Monitor のログ クエリ」を参照してください。

はい。Azure ストレージ アカウントは 1 つのサブスクリプションにすることができ、Log Analytics ワークスペースは別のサブスクリプションに存在できます。

はい。 適切な特権があり、ストレージ アカウントがネットワーク セキュリティ グループ (ネットワーク セキュリティ グループ フロー ログ) または仮想ネットワーク (仮想ネットワーク フロー ログ) と同じリージョンにある場合は、フロー ログを別のサブスクリプションにあるストレージ アカウントに送信するように構成できます。 宛先ストレージ アカウントは、ネットワーク セキュリティ グループまたは仮想ネットワークの同じ Microsoft Entra テナントを共有する必要があります。

No. すべてのリソースは、ネットワーク セキュリティ グループ (ネットワーク セキュリティ グループ フロー ログ)、仮想ネットワーク (仮想ネットワーク フロー ログ)、フロー ログ、ストレージ アカウント、Log Analytics ワークスペース (トラフィック分析が有効な場合) を含む同じテナントに存在する必要があります。

はい。

Traffic Analytics ワークブックは、Log Analytics クエリによって動作します。 クエリがログ分析の制限を超えると、ワークブックにメモリ不足エラーが表示される場合があります。 パフォーマンスを向上させ、メモリエラーを減らすために、ユーザーは専用の Log Analytics クラスターを使用できます。

No. フロー ログに使用されているストレージ アカウントを削除しても、Log Analytics ワークスペースに格納されているデータは影響を受けません。 Log Analytics ワークスペースでは履歴データを引き続き表示できますが (一部のメトリックは影響を受けます)、フロー ログを更新して別のストレージ アカウントを使用するまで、トラフィック分析は新しいフロー ログを処理しなくなります。

サポートされているリージョンを選択します。 サポートされていないリージョンを選択すると、"見つかりません" というエラーが表示されます。 詳細については、「 Traffic Analytics でサポートされているリージョン」を参照してください。

フロー ログが正常に機能するためには、 Microsoft.Insights プロバイダーを登録する必要があります。 Microsoft.Insights プロバイダーがサブスクリプションに登録されているかどうかがわからない場合は、「NSG フロー ログの管理」の登録方法に関する手順を参照してください。

ダッシュボードに初めてレポートが表示されるまでに最大 30 分かかる場合があります。 ソリューションでは、まず、意味のある分析情報を得るために十分なデータを集計し、次にレポートを生成する必要があります。

次のオプションを試してください。

• 上のバーの時間間隔を変更します。
• 上部のバーで別の Log Analytics ワークスペースを選択します。
• 最近有効にされた場合は、30 分後にトラフィック分析にアクセスしてみてください。

このメッセージは、次の理由で表示される場合があります。

• トラフィック分析は最近有効になっており、意味のある分析情報を導き出すために十分なデータをまだ集計していない可能性があります。
• 無料バージョンの Log Analytics ワークスペースを使用していて、クォータ制限を超えました。 容量が大きいワークスペースを使用する必要がある場合があります。

前の質問に対して推奨される解決策をお試しください。 問題が解決しない場合は、 Microsoft Q&A で懸念事項を提起してください。

ダッシュボードにリソース情報が表示されます。ただし、フロー関連の統計情報は存在しません。 リソース間の通信フローがないため、データが存在しない可能性があります。 60 分待ってから、状態を再確認します。 問題が解決しない場合、リソース間の通信フローが確実に存在する場合は、 Microsoft Q&A で懸念事項を発生させます。

トラフィック分析は従量制課金されます。 測定は、サービスによる生フロー ログ データの処理に基づいています。 詳細については、「Network Watcher の価格」を参照してください。
Log Analytics ワークスペースに取り込まれた拡張ログは、最初の 31 日間 (ワークスペースで Microsoft Sentinel が有効になっている場合は 90 日間) まで無料で保持できます。 詳細については、「Azure Monitor の価格」を参照してください。

トラフィック分析の既定の処理間隔は 60 分ですが、10 分間隔で高速処理を選択できます。 詳細については、 トラフィック分析でのデータ集計に関するページを参照してください。

Traffic Analytics は、ワークスペースと同じリソース グループ内にデータ収集規則 (DCR) リソースとデータ収集エンドポイント (DCE) リソースを作成および管理し、プレフィックスとして NWTA を付けます。 これらのリソースに対して何らかの操作を実行すると、トラフィック分析が期待どおりに機能しない可能性があります。 詳細については、 トラフィック分析でのデータ集計に関するページを参照してください。 詳細については、Azure Monitor のデータ収集規則と Azure Monitor のデータ収集エンドポイントに関するページを参照してください。

これらのリソースはサービスによって管理されるため、トラフィック分析によって作成された DCR および DCE リソースにロックを適用することはお勧めしません。 関連するフロー ログを削除すると、ロックされたリソースはクリーンアップされません。 これらのリソースに対して何らかの操作を実行すると、トラフィック分析が期待どおりに機能しない可能性があります。 詳細については、 トラフィック分析でのデータ集計に関するページを参照してください。

トラフィック分析は、Microsoft の内部脅威インテリジェンス システムに依存して、IP を悪意があると見なします。 これらのシステムは、Microsoft 製品やサービス、Microsoft Digital Crimes Unit (DCU)、Microsoft Security Response Center (MSRC)、外部フィードなどの多様なテレメトリ ソースを使用し、その上にインテリジェンスを構築します。 このデータの一部は Microsoft Internal です。 既知の IP に悪意のあるフラグが設定されている場合は、詳細を知るためのサポート チケットを作成します。

トラフィック分析には、アラートのサポートが組み込まれていません。 ただし、トラフィック分析データは Log Analytics に格納されるため、カスタム クエリを記述してアラートを設定できます。 次の手順に従います。

• トラフィック分析では Log Analytics リンクを使用できます。
• トラフィック分析スキーマを使用してクエリを記述します。
• [新しいアラート ルール] を選択してアラートを作成します。
• アラートを作成するには、「新しいアラート ルールを作成する」を参照してください。

いいえ。現在サポートされていません。 Log Analytics ワークスペースがネットワーク セキュリティ境界の背後にデプロイされている場合、トラフィック分析ではそこからデータを取り込むことができなくなります。

はい。 接続のトラブルシューティングと NSG 診断では、プライベート Application Gateway のデプロイはサポートされていません。 詳しくは、「プライベート Application Gateway デプロイ」を参照してください。