ネットワークで問題が発生した場合には、ネットワークコマンド（pingなど）を使って原因究明するのが一番多いですが、色々調べてもわからなかったときに、一番たよりになるのがパケットキャプチャーではないでしょうか。
なんでネットワークを扱うのが難しいのかって、ネットワークが目に見えるものではないからだと思います。
ところがパケットキャプチャーできれば通信しているデータが見えてしまうのですから、これは強力です。
これまで、パケットキャプチャーする環境構築に苦戦しておりましたが、今回はネットワークの可視化したものを眺めます。
パケットキャプチャーの実施
私が作業しているシェアーオフィスで実施しました。
朝9時前に私を含めて、数名しかいない時間から、5,6名の会員が来て、Web会議なども実施する状況で１時間弱の間キャプチャーしました。
Wifiは Wifiアダプタ TP-Link Archer T2U PLUSを接続して、自端末の通信のみを取得するのではなく、該当チャンネルで飛び交うパケットを全て取得できるモニタモードで収集しました。
これによって、無線波の管理・制御フレームとデータフレームの割合などから、無線効率を確認したり、モバイル端末が接続するときのネゴシエーションから問題の切り分けができたりします。
ただし、あまりヴィジュアルとして訴求できなかったので、わかりやすいラズパイ内臓Wifiによる、etherフレーム以上のパケットから可視化したヴィジュアルをあげます。
１．プロトコル階層統計：メニュー「統計」→「プロトコル階層」
【 wlan0 - プロトコル階層 】
【 wlan0 で収集したデータ 】
IPver6パケットは、21.5％
IPver4パケットは、54.1％
UDPデータグラムは、33.5%
TCPパケットは、19.6％
ARPフレームは、24.2%
パケットサンプルとしては、IPver6パケット、UDPデータグラムが多めの日でした。おそらく、Web会議を実施している人がいて、IPver6パケット、UDPデータグラムが取れていると思われる。
プロトコルごとに％が出るので、ネットワーク全体に影響を及すプロトコルや帯域に負荷をかけている大量データの通信などが発見できるかもしれない。
【捕捉】
Wiresharkで「Malformed Packet」と表示される場合、これは特定のプロトコルではなく、パケットの解析中に問題が発生したことを示すエラーメッセージです
Roofnetプロトコルはメトリックを決定するために定期的なブロードキャストが使用されます。実験的な802.11b/gメッシュネットワークのパケットのようです。
Meraki Discovery Packetは、Cisco Merakiデバイスがネットワーク上で自身を識別し、他のデバイスと通信するために使用するプロトコルで、LLDPを使用して、接続されているデバイスの自動検出と30秒ごとにLLDPパケットを送信し、接続されているデバイスの情報を提供します。
Multicast Domain Name System (mDNS)は、ローカルネットワーク内でデバイスの名前解決を行うためのプロトコルです。
mDNSは、特に家庭内ネットワークや小規模オフィスで広く利用されており、AppleのBonjourやLinuxのAvahiなど、多くの実装が存在します
Simple Service Discovery Protocol (SSDP)は、ネットワーク上のデバイスを自動的に発見し、接続するためのプロトコルです。
特に、UPnP（Universal Plug and Play）を使用するデバイスやサービスを検出するために使用されます。
Internet Group Management Protocol (IGMP)は、IPネットワーク上でマルチキャスト通信を行うためのプロトコルです。
Apple Wireless Direct Link (AWDL)は、Appleが開発したプロプライエタリなピアツーピア無線通信プロトコルです。
AWDLは、AirDropやAirPlayなどのApple製品間でのデータ転送や通信に使用されます。
【 wlan1 - プロトコル階層 】
IEEE802.11ヘッダーの情報が収集されている。
２．対話解析（どの端末とどの端末が通信しているか）：メニュー「統計」 - 「対話」 （通信量が多いエンドポイント同士）
【TCP】
172.16.13.101 ⇔ 172.16.13.147 は私のPCとラズパイの間で、ラズパイOS7GBを転送した記録です。
【UDP】「パケット」項目でソート
一番パケット数が多い「172.16.13.79」を選択して、ストリームＩＤでフィルタする。
mDNSでのマルチキャスト通信とわかりました。
同様に送信元5353の通信はmDNSでのマルチキャスト通信とわかりました。
同様に送信元11111の通信はUDPでのブロードキャスト通信とわかりました。
同様に送信元17500の通信はDROPBOXのブロードキャスト通信とわかりました。
・・・と宛先ごとに通信の正体を確認していくこともできますが、データ量が少ないので、ネットワークの負荷としては問題ないと思われます。
相手先ごとに％が出るので、問題があって割合が多くなっている通信を発見できると思われる。
正常なサービスを提供している相手先などは省いて行って、突き止められない宛先でパケット過多となっているところは要注意と分かります。
３．終端解析（どの端末が通信しているか）：メニュー「統計」 - 「終端」 （もっともおしゃべり）
【TCP】
172.16.13.101 ⇔ 172.16.13.147 は私のPCとラズパイの間で、ラズパイOS7GBを転送した記録です。
【UDP】「パケット」項目でソート
一番パケット数が多い「224.0.0.251」を選択してフィルタする。
やはり、mDNSのマルチキャスト通信でありました。
内部端末ごとに％が出るので、問題があって割合が多くなっている通信を発見できると思われます。
正常なサービスを提供している相手先などは省いて行って、突き止められない宛先でパケット過多となっているところは要注意と分かります。
マルウエアに感染して内部ＬＡＮからインターネット上のリスクあるサーバと通信している端末が特定できるでしょう。
４．パケット長解析：メニュー「統計」→「パケット長」
※ 40-79：TCP制御パケット 1280-2559：転送パケット
４０以下の短すぎるパケットと、2560以上の大きすぎるパケットは正常な通信ではない可能性が高いので、調査要と分かります。
５．入出力グラフ（時間に基づいてグラフ化）：メニュー「統計」→「入出力グラフ」
TCPエラーはほぼ無いように見えるので、TCPエラーだけをフィルタする。
TCPエラーは無いことがわかる
2025.02.28 に実施したパケットチャプチャーを見ると（エラーがあった）
わずかだが、TCPエラーが発生しているのがわかる。
これをTCPエラーでフィルタをかけて、画面で確認すると、Info欄に [TCP Retransmission] と再送していることがわかる。
また、 [TCP Dup ACK xxxx#n ] は重複ACKであり、パケットの欠損など発生している可能性があり、win=501 などウィンドウサイズも小さいため、効率が落ちているようです。
SLE、SREも指定されており、選択確認応答 (TCP SACK)は行われているようです。
６．ストリーム追跡機能：パケットを右クリック →「追跡」→「TCPストリーム/UDPストリーム/SSLストリーム/HTTPストリーム」
パケットを選択して、右クリック「追跡」→「TCPストリーム」を実行
TCPストリームIDでパケットを追跡できる。
７．フローグラフ：メニュー「統計」→「フローグラフ」 機器間の通信の可視化やなじみのない通信の理解に役立つ
パケットを選択して、「統計」→「フローグラフ」でプロトコルのシーケンスを確認できる。
再送が発生している箇所など確認できる。
８．エキスパート情報：メニュー「分析」→「エキスパート情報」→ 「概要毎にグループ化」のチェックをはずす 警告の状態を一覧する
エキスパート情報は、Wiresharkが特定の状態になった際に警告を挙げるために設定されている4つの状態を示します:
1. Error: パケットやそれを解析したときにエラーが発生したもの。
2. Warning: 通常の通信の一部ではない異常なパケット。
3. Note: 通常の通信の一部である異常なパケット。
4. Chat: 通信の基本情報。
９．パケット選択、「統計」 → 「TCPストリームグラフ」 → 「グラフタイプ」 （１つのコネクションに特化した形でTCPとしての状態変化を見たい）
●シーケンス番号（Stevens）
●シーケンス番号（tcptrace）
ズームをかけて、部分的なパフォーマンスを確認できる。
●往復遅延時間
ズームをかけて、部分的なパフォーマンスを確認できる。
●スループット
ズームをかけて、部分的なパフォーマンスを確認できる。
ウィンドウスケーリング
ズームをかけて、部分的なパフォーマンスを確認できる。
ネットワークがアイドル状態の時、負荷がかかっている時で、それぞれの状況として、ネットワークの品質を判断しなければならない。
Windowサイズの調整によるフロー制御が行われて、効率的に性能を高めようとするが、TCPの輻輳制御のために流量調整が入ったりするので、性能が出ないこともある。ネットワーク環境の色々な要因が絡んでくると思われ、設定として問題ないかの判断が難しい。
たとえば、Wireguard経由での大量データの送信でスムーズな転送と見えていても、TCPレベルでは再送が行われていたりする。
切り分け、状況判断が難しいと感じました。
調整の仕方としては、以下の計算式からバッファサイズを変更することであるが、OSレベルの調整となるので簡単ではない。
帯域幅遅延積BDP(セグメント) = 帯域幅（セグメント/秒）X RTT（秒）
・BDPよりバッファサイズが大きいとき、パケットロスや遅延が発生する
・BDPよりバッファサイズが小さいときは、ネットワークに無駄が生じる
