ネットワーク障害対応で最初に触るツールがこの4つです。 pingで疎通確認、mtrで経路と区間ごとの遅延/損失確認、tcpdumpでサーバ上で軽量にパケットを取得、そしてGUIで深掘りできるのがWiresharkです。 本記事は実務で役立つコマンド例と出力の読み方まで、初心者〜中級者が一読で運用に使えるレベルを目指してまとめています。
目次
1. ping — 基本の疎通確認
何を確認するか
- 対象ホストへパケットが届くか(到達性)
- 往復時間(RTT)の目安
- パケットロス率(簡易)
代表的な使い方(Linux / macOS / Windows)
ping 8.8.8.8
# Windows: ping -n 5 8.8.8.8
# Linux/macOS: ping -c 5 8.8.8.8
出力例と読み方
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=117 time=23.4 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=22.9 ms
...
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max = 22.9/23.4/24.1 ms
ポイント:packet loss が発生している場合は物理的障害/経路障害/フィルタに注意。RTTが急に跳ね上がる場合は輻輳や途中経路の問題を疑います。
注意点
- ターゲットがICMPをブロックしているとpingは失敗するが、TCP/UDPは通る場合がある。
- 企業ネットワークではICMPレート制限されることがある。
2. mtr — 経路毎の遅延と損失をリアルタイムで見る
mtrの利点
- tracerouteの経路確認+pingの継続測定を組み合わせたツール
- 経路のどのホップでパケットロスや遅延が発生しているかを特定しやすい
基本コマンド
# インタラクティブ
mtr 8.8.8.8
# レポートモード(ルートやログ用)
mtr -r -c 100 8.8.8.8 # 100回送信してレポート出力
mtr -rw 8.8.8.8 # -w 幅広表示
代表的な出力例(抜粋)
HOST: host-name Loss% Snt Last Avg Best Wrst StDev
1. 192.168.0.1 0.0% 100 1.0 1.2 0.8 5.3 0.6
2. 203.0.113.1 0.0% 100 10.1 10.5 9.8 20.3 1.5
3. 198.51.100.1 5.0% 100 50.4 51.2 49.9 121.4 10.8
...
解釈:ホップ3で Loss% が高ければ、その区間(ホップ2→3あるいは3自体)で問題が起きている可能性が高い。注意点としては、途中ルータがICMPを低優先で扱う(管理ICMPに低優先度を与える)ため、必ずしもアプリ層トラフィックの品質劣化を直接意味しない点です。
3. tcpdump — CLIで手早くパケットを取得する(サーバ/現場向け)
用途
- サーバやゲートウェイ上でのパケット取得
- 短時間での証跡取得、後でWiresharkで解析するための.pcap保存
基本コマンド例
# インターフェース eth0 の全トラフィック表示(root権限)
sudo tcpdump -i eth0
# 特定ホストのTCP 443 のみキャプチャしてファイル出力(100パケット)
sudo tcpdump -i eth0 tcp port 443 -w capture.pcap -c 100
# 名前解決を無効化して高速化(-n)、パケット数制限(-c)
sudo tcpdump -i eth0 -n host 192.0.2.10 and port 22 -c 200
よく使うフィルタの例
# src または dst を指定
tcpdump -i eth0 src 192.168.1.100
tcpdump -i eth0 dst 203.0.113.5
# ネットワーク指定
tcpdump -i eth0 net 10.0.0.0/8
# 複合条件
tcpdump -i eth0 'tcp and (port 80 or port 443) and host 198.51.100.5'
実務的な注意点
- -wでファイル出力したら必ずサーバのディスク容量を確認する。
- 長時間キャプチャは負荷が高いため、事象が出る短時間に絞る。
- HTTPSなど暗号化通信は中身を見られないが、ハンドシェイクや異常再送は確認できる。
4. Wireshark — GUIで深掘り解析(プロトコル分解が強力)
用途
- パケットの詳細(レイヤ毎)を視覚的に追う
- TCP再送、遅延、TLSハンドシェイク、HTTPヘッダなどの解析
始め方(基本操作)
- 監視するインターフェースを選択してキャプチャ開始
- Display Filter(表示フィルタ)で必要なパケットだけ表示する(例:
ip.addr == 192.168.1.10 and tcp.port == 443) - 該当パケットを選び、下部ペインでプロトコル階層を展開して詳細を確認
よく使う Display Filter 例
http.request # HTTPリクエストのみ
tcp.analysis.retransmission # TCP再送のみ抽出
ip.addr == 10.0.0.5 # 指定IPの送受信を表示
tls.handshake.type == 1 # TLS ClientHello の抽出
実務での使い方ワークフロー
- tcpdumpで.pcapを収集(現場での負荷低減)
- ローカルPCに.pcapを持ち帰りWiresharkで解析
- フィルタで対象会話(Conversation)を絞り、再送やウィンドウサイズ、遅延を確認
注意点
- HTTPS等暗号化されたペイロードは見えない。TLSのハンドシェイクや証明書情報は見える。
- プライバシー/規約に従いパケットキャプチャの取り扱いに注意。
5. ツールの組み合わせで実務的な調査フロー
- 疑いの切り分け(速攻):ping で到達とRTT、mtr で経路と区間損失を確認。
- 対象絞り込み(現場):tcpdump で短時間キャプチャ(-c, -w)して問題の時間帯を保存。
- 深掘り解析(オフライン):Wireshark で .pcap を開き、TCP再送・遅延・アプリ層のエラーを解析。
- 再現・検証:必要ならネットワーク機器の設定やルート変更を行い、再度 mtr/ping で確認。
6. よくある実務的なチェック例(コマンド+期待値)
| 目的 | コマンド | 期待する正常結果 |
|---|---|---|
| 外部への到達確認 | ping -c 5 8.8.8.8 | 0% packet loss、RTTが通常値(例: <50ms) |
| 経路で遅延/損失のある区間検出 | mtr -rw 8.8.8.8 | 各ホップのLoss%が低く、特定ホップで急増しない |
| サーバ上のパケット確認 | sudo tcpdump -i eth0 host 10.0.0.5 and port 443 -c 200 -w /tmp/cap.pcap | 該当接続のTCPハンドシェイクが正常に行われている |
| アプリ層の問題解析 | Wiresharkでcap.pcapを開いてフィルタ | TCPの再送やRST、HTTPの500などが分かる |
7. トラブルシューティングのヒント/注意点まとめ
- ICMPがブロックされる環境では ping/mtr の結果を鵜呑みにしない(代替:tcping / telnet / nc でポート疎通確認)。
- ルータや中間機器がICMPに低い優先度を設定している場合、mtrのLoss%は誤解を招くことがある。
- パケットキャプチャは個人情報・機密情報が含まれるため、取得・保管・共有ルールを厳守する。
- 長時間のキャプチャは機器・ディスクへの負荷が高い。短時間で事象を切り取る運用を徹底する。
8. まとめ
ping → mtr → tcpdump → Wireshark の流れを標準ワークフローとして覚えておくと、多くのネットワーク障害を迅速に切り分けられます。 各ツールの出力の意味を正確に理解し、組み合わせて使うことで「どの機器/区間で」「なぜ」問題が起きているかを特定できます。 まずは現場で実際にコマンドを叩いてみて、出力の読み方に慣れてください。
