アプリケーション接続のトラブルシューティング

問題

ネットワーク関連の問題を報告し対策を講じるには、正確なデータの収集、可視化、および解釈が必要です。 信頼できるネットワークパフォーマンス指標がないと、接続の問題を修正することは推測のゲームになります。 最終的には、従業員体験の低下とリソースの浪費につながります。

解決策

アプリケーション接続性のトラブルシューティングは、一連の調査方針 に従います。アプリケーション接続性は次のことをサポートします:

  • ネットワーク関連の問題の根本原因を特定する、または可能性のある根本原因を排除する。

  • ターゲットとなる解決策でネットワーク関連の問題を効果的にトラブルシューティングする。

  • 関係するチーム間で事実に基づく議論を可能にすることで、“責任転嫁ゲーム”を止める。

  • デバイスデータのプライバシーを管理し、組織内でのコンプライアンスを確保する。

これを達成するために、アプリケーション接続フレームワークは、接続データ に依存します。接続メトリックス、目的地情報、データプライバシーコンプライアンスを可用性デバイスレベルで提供しています。

このページのNQLクエリは、ネットワーク関連の問題を調査するために接続データを使用する方法の例です。 同様のクエリは、Nexthinkのwebインターフェースで利用可能なさまざまなクエリベースの機能によってサポートされています。

You can also use Network view for connections data visualization, filtering and drill-downs (transport protocols, devices, binaries, destinations, etc.).

前提条件

  • 接続イベントは、"Infinityのみ" を報告するCollector を持つデバイスにのみ利用可能です。

  • Collector の最小バージョンは2023.10。

接続データ

Network viewおよびこのページのNQLクエリで使用される接続データが含まれます:

  • 接続イベント

  • 接続メトリックス

  • 目的地のデコレーション

  • 接続イベントの集計

接続データを用いたネットワークトラブルシューティングセクションに移動して、Application Connectivityのクエリの使用について学びます。

接続イベント

A connection event represents an outgoing TCP connection (established by a device) or outgoing UDP packages. 各接続イベントは次の情報を提供します:

  • イベントのバケットの開始時刻、終了時刻、および継続時間

  • 接続イベントのソース

  • イベントの目的地

  • トランスポートプロトコルおよびIPバージョン

  • 接続に関するメトリックス

Connection events are sampled events, meaning Nexthink reports connection events in buckets of 15 minutes and 1 day.

NQLデータモデルのnamespace connectionには1つの主要なテーブがあります:

  • connection.eventsテーブルには、外向きTCP接続およびUDPパッケージのためのイベントが含まれます。

The following two tables in the connection namespace are deprecated and will be removed in the future:

  • connection.tcp_eventsテーブルには、外向きTCP接続のためのイベントが含まれます。

  • connection.udp_eventsテーブルには、外向きUDPパッケージのためのイベントが含まれます。

失敗した接続の数や接続の確立時間などのいくつかのメトリックスは、TCP接続イベントにのみ利用可能です。

詳細については、NQLデータモデル ドキュメントを参照してください。

接続イベントの関連付け

接続イベントは次のオブジェクトにリンクされています:

  • 接続を確立したデバイス。

  • 接続を使用するバイナリ。

  • バイナリを実行するプロセスのユーザー。

  • オプションで、このバイナリに設定されたデスクトップアプリケーション。

  • オプションで、設定された目的地に一致するネットワークアプリケーション

接続の目的地のデコレーション

Nexthinkは、目的地に関する追加情報で接続イベントデータを装飾します。

IPとネットワークポートは接続の目的地を定義します。 さらに、Nexthinkは接続イベントデータに目的地タイプ、「サブネットアドレス」、およびオプション情報を装飾します:

  • 目的地のドメイン名。

  • 目的地の所有者。

  • Country and location of the destination (GeoIP information).

  • 目的地の所有者提供によるデータセンター地域の名前。

The destination subnet address equals the IP address with the last 8 bits set to zero.

Nexthinkは、GeoIPデータおよび公表されたIPアドレス範囲を使用して接続の目的地情報を充実させます。 次の表を参照してください。

条件
接続の種類
目的地情報

プライベートIPアドレス

イントラネット

追加の目的地情報はありません

パブリックIPアドレス

イントラネット

  • 目的地の所有者: Autonomous Systemの名前として提供されたもの

  • 目的地の国: GeoIP情報に基づく

目的地の所有者により公開されたIPアドレスの範囲に属するパブリックIPアドレス。

データセンター

  • 目的地の所有者: IP範囲のための名前

  • 目的地の国: GeoIP情報に基づく

  • データセンター地域: 所有者により提供されたデータセンターの名前

目的地の所有者、国、データセンターの地域に関する情報は常に利用可能ではなく、部分的にのみ利用可能な場合もあります。 この場合、対応するフィールドはNULLになります。

接続イベントメトリックス

接続イベントは以下のメトリックスを提供します:

  • The connection round-trip-time (RTT): The average round trip time for all established TCP connections. The round trip time is measured between sending the SYN message and receiving the SYN-ACK message from the remote party during the TCP connection establishment, a 3-way handshake. このメトリックスは、少なくとも1つの確立された接続を持つTCP接続にのみ利用可能です。

  • バイト単位での受信および送信トラフィック。 Data received (TCP only) and sent (TCP and UDP) by the application during the event.

  • すべての試行されたTCP接続の失敗した比率、すなわちすべての確立および失敗したTCP接続の比率。

  • イベント中のステータスごとの接続数。

ステータスごとの接続数
  • 確立済み接続数:現在のタイムバケット内で確立された接続の数。 (TCP and UDP)

  • 存続接続数:以前のタイムバケットで確立され、現在のタイムバケットまで続く接続の数。 (TCP and UDP)

  • 成功した接続: 確立済み接続と存続接続の合計。

  • Failed connections (TCP only) can be one of the following:

    • ホストなしで失敗した接続:目的地ホストに到達しないために失敗した接続の数。

    • サービスがなくて失敗した接続:目的地ホストのサービスに到達しないために失敗した接続の数。

    • 拒否された接続:ユーザーのデバイスで拒否された外向き接続の数。

  • 試行された接続: プロセスがバケット内で確立しようとしたTCP接続の数、すなわち確立および失敗した接続の合計。

  • Nexthinkが1つのイベントに集計する接続数は、失敗した接続と成功した接続の合計です。

接続ステータスを理解し、失敗接続率がどのように計算されるかをよりよく理解するために、タイムライン上の接続を示す次の画像を見てください。 各ラインは特定の接続を表し、その持続時間を示しています。 たとえば:

  • C1は選択された時間範囲の前に開始し、その範囲内で終了します。

  • C2は選択された時間範囲の前に開始し、その後に終了します。

  • C5は選択された時間範囲内で接続を試みますが失敗します。

テーブルは、指定された時間範囲内でステータスごとに接続数を計算するためにどの接続が考慮されるかを説明しています。

接続イベントの集計

Nexthink aggregates connections into buckets of 15 minutes and 1 day.

15-min aggregation

Nexthink aggregates all connections happening within the same 15-minute bucket and sharing the following characteristics into one event :

  • 同じデバイス

  • 同じバイナリ

  • バイナリを実行する同じユーザー

  • 同じIPアドレスとネットワークポート

  • Same transport protocol (TCP or UDP)

When aggregating connections into a 15-minute bucket, Nexthink computes the following:

  • 確立されたTCP接続のラウンドトリップ時間の平均。

  • バケット内のすべての接続の受信および送信トラフィックの合計。

  • ステータスごとの接続数。

  • 失敗した接続の比率。

1-day subnet aggregation

When Nexthink aggregates 15-minute buckets into 1-day buckets, the system sets the IP address to NULL and combines all 15-minute events into one 1-day event that share the following characteristics:

  • 同じデバイス

  • 同じバイナリ

  • バイナリを実行する同じユーザー

  • 同じサブネットマスクとネットワークポート

  • Same transport protocol (TCP or UDP)

  • 同じ目的地フィールド

When aggregating connections into a 1-day bucket, Nexthink computes the following:

  • 確立されたTCP接続のラウンドトリップ時間の加重平均。

  • バケット内のすべての接続の受信および送信トラフィックの合計。

  • ステータスごとの接続数。

  • 失敗した接続の比率。

接続データを用いたネットワークトラブルシューティング

接続データ を使用してネットワーク関連の問題をトラブルシューティングします。 To find the root cause of a network issue or exclude possible root causes, you must identify the relevant population (devices, apps, destinations) affected by network issues and when the impacted connection metric (failed connection ratio, establishment time, traffic) changed.

Network viewを使用して同じトラブルシューティングの原則を適用できます。 Network Viewを使用することで、ユーザーは接続メトリックを選択し、デバイス、アプリケーション、目的地の次元でフィルタリングすることで、関連する集団を視覚的に特定できます。

関連する集団の特定

接続データの3つの次元に注目してください:

  • デバイス次元:影響を受けたデバイスはどれですか、それらはどのくらいありますか?

    • 同じ特性と場所を共有する影響を受けたデバイスを決定します。

  • アプリケーション次元:影響を受けたデスクトップアプリケーションはどれですか、それらはどのくらいありますか?

  • 目的地次元:影響を受けた目的地はどれですか? それらはどこにありますか?

デバイス次元

接続イベントは、ネットワーク接続を作成したデバイスオブジェクトにリンクされています。 This allows you to investigate the connections data of a single device (by devices.name) or a group of devices, for example by devices.entity, GeoIP-based location or other custom organizational unit classifications.

詳細については、Product configuration ドキュメントを参照してください。

GeoIPに基づいた場所でデバイスをグループ化するには、接続イベントの場所コンテキストを使用します。例えば:

Code
connection.events during past 7d
| where transport_protocol == TCP
| where binary.name == "*outlook*"
| summarize Avg_RTT = establishment_time.avg() by context.location.country

場所コンテキストは、イベント時にデバイスがどこにあったかを示します。 ジオロケーション機能がアクティブ化されている必要があり、コレクタのトラフィックがVPNを通じてではなくインターネットに直接ルーティングされているときに最適に機能します。

または、組織のコンテキストを使用することができます。例えば:

Code
devices during past 7d
| with connection.events during past 7d
| where transport_protocol == tcp
| where context.organization.entity == "XYZ"
| compute Failed_Connections = number_of_failed_connections.sum()

アプリケーションの次元

接続イベントは、接続を開始したバイナリオブジェクトにリンクされています。

Code
connection.events during past 7d
| where transport_protocol == TCP
| where binary.name == "ABC"
| summarize Avg_RTT = establishment_time.avg() by context.location.country

さらに、バイナリがアプリケーション定義の一部である場合、接続イベントはデスクトップアプリケーションにもリンクされます。

Code
connection.events during past 7d
| where transport_protocol == TCP
| where application.name == "XYZ"
| summarize Avg_RTT = establishment_time.avg() by context.location.country

行先名

行先は接続イベントの構造化フィールドです。 たとえば:

Code
connection.events during past 7d
| where transport_protocol == TCP
| where destination.port == 135
| where number_of_failed_connections > 0

IPアドレスのカーディナリティが高すぎるため、IPアドレスごとに要約することは不可能であることに注意してください。 代わりに、IPアドレス、IPサブネット、ネットワークポート、またはドメイン名に基づいてネットワークアプリケーションを設定できます。 その後、ネットワークアプリケーション名を使用して接続イベントをフィルタリングできます。たとえば:

Code
connection.events during past 7d
| where transport_protocol == TCP
| where network_application.name == "XYZ"
| where number_of_failed_connections > 0

TCP接続の調査

TCP接続の品質を視覚化するための主な指標は次のとおりです:

  • 接続のラウンドトリップタイム(RTT):すべてのTCPイベントで確立された接続のRTTが利用可能で、tcp_events.establishment_time.avgを通じてアクセスできます。 接続のRTTは遅い接続の良い指標です。

  • 失敗した接続の割合:新しい接続(確立済みと失敗した接続)の数に対する失敗した接続の数。 失敗した接続の割合には、failed_connection_ratio.avgを通じてアクセスできます。

失敗した接続の割合とその値の変動は、常に失敗した接続の数または試行された接続の数とともに評価されるべきです。 次の例を考えてみましょう:失敗した接続の割合が100%ですが、試行された接続の数が1の場合、さらに調査する価値はありません。

例:VPN接続の問題の調査

以下は、VPN接続の問題を調査するためのライブダッシュボードの例です。 アプリケーションの次元がVPNバイナリに固定されていることに注意してください。

以下にVPN接続の問題を調査する例のNQLクエリを示します:

Code
connection.tcp_events during past 24h
| where binary.name in ["VPN_binary_Windows", "VPN_binary_macOS"]
| where destination.domain == "VPN_edge_domain_name"
| where number_of_established_connections > 0
| summarize Devices__ = device.name.count(), Avg_RTT = establishment_time.avg(), Failed_Connections_Ratio_in_percent = (number_of_failed_connections.sum()) / ((number_of_established_connections.sum()) + (number_of_failed_connections.sum())) * 100, Failed_Connections = number_of_failed_connections.sum() by context.location.country, destination.country, destination.datacenter_region
| sort Failed_Connections desc
Code
connection.tcp_events during past 720min
| where binary.name in ["VPN_binary_Windows", "VPN_binary_macOS"]
| where destination.domain == "VPN_edge_domain_name"
| where number_of_established_connections > 0
| summarize average_RTT = establishment_time.avg() by 15min

UDPトラフィックの調査

UDPのコネクションレスな性質により、UDPネットワークトラフィックの調査はTCPネットワークトラフィックに比べて限られています。 主なツールは、1つのアプリケーションのデバイスごとの平均トラフィックを比較するなど、送信UDPトラフィックの量の変化と違いを探すことです。

Code
connection.events during past 7d 
| where transport_protocol == UDP 
| where number_of_successful_connections > 0 
| where outgoing_traffic == 0 
| summarize idle_connections = number_of_successful_connections.sum() by binary.name 
| sort idle_connections desc

同じトラブルシューティングアプローチをネットワークビューに適用して、接続データの視覚化、フィルタリング、およびドリルダウン(トランスポートプロトコルを含む)を行うことができます。

Nexthink Infinity におけるアプリケーション接続

アプリケーション接続の接続データおよびクエリに対応するNexthinkのいくつかの機能に関する関連ドキュメントを以下に示します:

このページに含まれているアプリケーション接続クエリは、Nexthink WebインターフェースのすべてのNQLベースの機能に使用できます。

データプライバシーの管理

コレクターレベルの匿名化の設定およびロールのドキュメントを参照して、接続データ プライバシーを匿名化し、フィルタリングし、管理します。

実装面

次の実装の側面が接続イベントに影響を与えます:

ドメイン名の報告

コレクターは、TLSサーバー名表示(SNI)拡張から目的地のドメイン名を取得し、デバイス上のDNS リクエストを監視します。 コレクターは、SNIからドメイン名を取得できない場合や、アプリケーションがDNSルックアップでOSを使用しない場合にドメイン名を報告しません。

Google Chrome Webブラウザーなどの一部のアプリケーションでは、SNIが暗号化されています。 これはTLS暗号化クライアントハロー(ECH)と呼ばれます。 ECHを利用している接続に対して、コレクターはドメイン名を報告できません。 ユーザーは、アプリケーションでECHを無効にしてドメイン名の報告を確保できます。

コレクターは、同じバイナリとユーザーによる複数の接続イベントが、同じデバイス、同じ時間、同じ目的地(同じ IP アドレスとポート)であるが、異なるドメイン名の場合に、実際のドメイン名の代わりに”multiple domain names”を報告します。

ドメイン名の短縮

コレクターは、さまざまな数学的およびヒューリスティックな特性を評価することによって、長くランダム化されたドメイン名を短縮します。

バイナリまたはユーザーごとの接続最大数

コレクターは、バイナリおよびユーザーごとに最大5分で512個の接続を報告します。 たとえば「ポートスキャン」中など、1つのバイナリおよびユーザーに対して512以上の接続が存在する場合、コレクターはこの期間内のすべてのこれらの接続イベントを1つのイベントとして報告します。 そのようなイベントに対して、次のフィールドはNULLです:

  • destination.ip_address

  • destination.ip_subnet

  • destination.port

  • destination.type

  • destination.owner

  • destination.country

  • destination.datacenter_region

  • destination.domain

  • establishment_time

VPNを介した接続

VPNとセキュアアクセスサービスエッジ(SASE)製品は、接続をインターセプトおよびルーティングするためのさまざまなソリューションを実装しています。 コレクターは、さまざまなVPNおよびSASE製品の接続データをすぐに報告します。 一部の製品では、コレクターは不完全なデータを報告します。 これは製品、デバイスのOS、および製品の構成に依存します。


関連トピック

関連トレーニング

Last updated