ネットワークトラブルが起きたとき、「とりあえずtcpdumpでキャプチャを取ればいい」と言う人は多いですが、実際にはtcpdumpの本質を理解せず、知識だけで“わかったふう”になっているケースが非常に多く見受けられます。
tcpdumpは単なるログ収集ツールではなく、「どこを観測するか」という視点が不可欠なツールです。対象となる通信には必ず送信側と受信側の2地点が存在し、それぞれにtcpdumpを仕掛けて比較することではじめて意味のある解析が可能になります。
それにも関わらず、1台のコンソールだけで状況を把握したつもりになっている技術者が、現場には驚くほど多く存在します。この記事では、そうした誤解を正し、tcpdumpを使った実践的かつ効果的な診断手順を解説していきます。
tcpdumpとは何か
tcpdumpは、LinuxやUNIX系OSにおいて最も古く、そして今でも現場で使われ続けているパケットキャプチャツールのひとつです。ネットワーク上を流れるパケットをコマンドラインから直接確認できることが最大の特徴であり、GUIツールとは違った機動性と柔軟性を持ちます。
特にトラブルシューティングやシステム検証の場面において、tcpdumpのようなツールは「本当に通信が発生しているのか」「そのパケットは送られているのか／届いているのか」を正確に観察するための“顕微鏡”のような存在です。
tcpdumpの役割と基本概念
tcpdumpの最大の役割は、ネットワーク通信の「実体」を捉えることです。アプリケーションやサーバーログだけを見ていては、そもそもパケットが届いているのか、送られていないのかを判断することはできません。
tcpdumpはNIC（ネットワークインターフェース）をモニタリングし、その時点でインターフェースを通過するパケットの内容を「そのまま」観察できます。つまり、上位のアプリケーションやシステムが何と言おうと、ネットワークレベルで起きている事実を確認できるという点で、最も信頼できる通信確認手段のひとつです。
tcpdump -i eth0 tcp
このような簡単なコマンドでも、特定インターフェース（ここではeth0）上のTCP通信をすべて表示することが可能です。ただし、tcpdumpの出力は非常に多くなるため、必ずしも「何でも表示すれば良い」わけではありません。
ネットワーク層での位置づけと特徴
tcpdumpはOSI参照モデルの「データリンク層〜ネットワーク層」に位置するツールです。つまり、パケットのIPヘッダーやTCPヘッダーなどの情報を直接観察することができ、アプリケーション層でのログとは異なる粒度の情報が得られます。
このため、以下のような特徴があります。
| 特徴 | 説明 |
|---|---|
| リアルタイム性 | 通信が発生した瞬間に出力されるため、遅延なく確認可能 |
| フィルタ機能 | 特定のIPアドレス、ポート、プロトコルに限定したキャプチャが可能 |
| ローカル視点 | tcpdumpを実行したマシンから“見える”通信しか観測できない |
この「ローカル視点」という特性が最も重要な点です。tcpdumpは、インターフェースを通過するパケットしか観察できません。つまり、「通信を見ているつもり」でも、その通信が実際には届いていなかったということが起こりえます。
例えば、クライアントからサーバーに対してHTTPリクエストを送った場合、クライアント側のtcpdumpでSYNパケットを確認できたとしても、それがサーバーに届いていなければ何も始まりません。このように、tcpdumpは“見える場所”が限られるという制約を持つことから、最低でも2台（送信側・受信側）のtcpdumpを同時に確認する必要があります。
tcpdump -i eth0 host 192.168.0.10 and port 80
このようにIPアドレスやポートを限定することで、無駄な出力を省き、必要な情報だけを抽出できます。ただし、この情報が「どこから」「どこへ」「どのように」送られているのかを理解するには、ネットワークトポロジと合わせてtcpdumpの出力を見ていく必要があります。
tcpdumpのインストール方法
tcpdumpは多くのLinuxディストリビューションで標準パッケージとして提供されており、導入は比較的簡単です。ただし、システムによってはデフォルトでインストールされていないこともあるため、最初に確認しておく必要があります。また、tcpdumpのバージョンは機能やオプションに影響するため、導入時点でのバージョン確認も重要なステップです。
RHEL系Linuxでのインストール手順
RHEL系ディストリビューション（AlmaLinux、Rocky Linux、CentOS、Red Hat Enterprise Linuxなど）では、標準のパッケージマネージャであるdnfを使用してtcpdumpをインストールできます。
インストール前にroot権限でログインしているか、またはsudoが使えるユーザーであることを確認してください。
dnf install -y tcpdump
このコマンドを実行することで、tcpdumpパッケージと依存関係が自動的にインストールされます。ネットワーク環境によってはリポジトリのキャッシュを先に更新しておくとエラーを防げます。
dnf makecache --refresh
上記のように明示的にキャッシュを再構築してからtcpdumpをインストールすることが推奨されます。インストールが完了したら、次に正しくインストールされているかを確認します。
which tcpdump
このコマンドで /usr/sbin/tcpdump のようなパスが表示されれば、インストールは成功しています。パスが表示されない場合は、パスが通っていないか、インストールが正しく行われていない可能性があります。
もしsudo権限でインストールした場合、通常ユーザーではtcpdumpを実行できないことがあります。これはtcpdumpがネットワークインターフェースを操作するためにroot権限を必要とするためです。その場合はsudoをつけて実行する必要があります。
sudo tcpdump -i eth0
また、インストールされたバイナリの場所を明示的に確認したい場合は、以下のコマンドでファイルの所在を確認できます。
rpm -ql tcpdump | grep bin
このようにして、tcpdumpの正確な導入状態を把握することができます。
バージョン確認と公式サイトの参照方法
tcpdumpはバージョンによって使えるオプションや動作が変わるため、バージョンの確認は非常に重要です。特に記事や書籍のコマンドを参考にする場合は、自分の環境のtcpdumpバージョンと照らし合わせておく必要があります。
現在のバージョンを確認するには以下のコマンドを使用します。
tcpdump --version
例えば以下のように表示されます。
tcpdump version 4.99.4
libpcap version 1.10.3 (with TPACKET_V3)
ここで確認するのは「tcpdump本体のバージョン」と「libpcapのバージョン」の2点です。libpcapはtcpdumpのパケットキャプチャ機能を支えているライブラリであり、これが古いと新しいカーネルに対応できない場合があります。
さらに詳細なマニュアルや最新版情報を確認したい場合は、公式サイトを参照するのが確実です。
tcpdump公式サイトには以下のような情報が掲載されています。
| 情報項目 | 内容 |
|---|---|
| Download | 最新版のtcpdumpおよびlibpcapのソースコード |
| Documentation | 使用方法の詳細、過去バージョンの履歴、コマンドリファレンス |
| Changelog | 各バージョンで追加・削除された機能の一覧 |
なお、tcpdumpは頻繁に機能追加されるわけではありませんが、libpcapのバージョン更新によって性能や安定性が変わる場合があります。そのため、古い環境を運用している場合は定期的な確認をおすすめします。
また、検証環境などで最新版のtcpdumpをビルドしたい場合は、公式サイトからソースを取得し、以下の手順で導入することも可能です。
curl -O https://www.tcpdump.org/release/tcpdump-4.99.4.tar.gz
tar -xvzf tcpdump-4.99.4.tar.gz
cd tcpdump-4.99.4
./configure && make && make install
ただし、運用環境では標準パッケージを利用する方が保守性に優れるため、無理なビルドは避ける方が賢明です。
tcpdumpの基本的な使い方
tcpdumpは、ネットワークトラブルの原因を特定する際に欠かせないツールです。ここでは、最小限の基本構文から、よく使う保存・再生の方法まで、実践で即使える使い方に絞って解説します。
最小限の基本構文
tcpdumpは引数を指定しないとエラーになることが多く、まずは正しい構文を把握することが重要です。最初に理解すべきは、どのインターフェースで何を観測するかという視点です。
インターフェースの指定
tcpdumpは、どのネットワーク経路（インターフェース）を監視するかを明示的に指定しないと、正しく起動できません。ここで言う「ネットワークインターフェース」とは、Linuxが持っている物理または仮想の通信口（NIC）のことです。たとえば、有線LANなら eth0、無線LANなら wlan0、自分自身との通信確認用に使われる lo などがあります。 どのインターフェースが使えるのかを確認するには、以下のコマンドを使用します。
tcpdump -D
このコマンドを実行すると、番号付きで監視可能なインターフェース一覧が表示されます。
以下はその一例です。
1.eth0
2.wlan0
3.lo
4.any (Pseudo-device that captures on all interfaces)
| 番号 | インターフェース名 | 説明 |
|---|---|---|
| 1 | eth0 | 有線LANポート（多くのサーバで使用） |
| 2 | wlan0 | 無線LAN（Wi-Fi）用のインターフェース |
| 3 | lo | ループバック（127.0.0.1）。自分自身との通信確認用 |
| 4 | any | 全てのインターフェースをまとめて監視する仮想デバイス |
この番号または名前を -i オプションで指定してtcpdumpを実行します。
tcpdump -i eth0
または番号指定も可能です。
tcpdump -i 1
正しいインターフェースを選ばないと、通信が一切表示されない場合があります。仮想マシンや複数NIC環境では、どのインターフェースが通信に使われているのかを事前に確認しておくことが重要です。インターフェースの確認には ip addr や ip link などのコマンドも併用すると、IPアドレスの付与状況も含めて把握できます。
ポート・プロトコルの主なフィルタ条件一覧
ネットワークのパケットを効率よく確認するには、必要な通信だけを的確に抽出することが重要です。tcpdumpでは多彩なフィルタ指定が可能で、特定ポートやプロトコルを絞り込むことで無駄な情報を省けます。以下は代表的なフィルタ指定とその構文の一覧です。
| 条件 | 構文例 | 説明 |
|---|---|---|
| ポート番号で絞る | tcpdump -i eth0 port 80 | ポート80（HTTP）の通信のみ表示 |
| 送信元IPを指定 | tcpdump -i eth0 src host 192.168.1.100 | 指定IPからの通信のみ表示 |
| 宛先ポートを指定 | tcpdump -i eth0 dst port 443 | 宛先がポート443（HTTPS）の通信を抽出 |
| 条件を複合指定 | tcpdump -i eth0 src 192.168.1.100 and port 22 | IPとポートを組み合わせて絞り込む |
| プロトコル指定 | tcpdump -i eth0 icmp | ICMP（Pingなど）のみを対象にする |
tcpdumpによるパケットの保存・再生
リアルタイム表示だけではなく、後からパケットを見直すためにはファイル保存と再生の機能を活用します。tcpdumpには専用のオプションが用意されており、保存したデータを再解析することで、より確実なトラブル調査が可能になります。以下に代表的な構文をまとめます。
| 機能 | オプション | 構文例 | 用途 |
|---|---|---|---|
| パケットを保存 | -w | tcpdump -i eth0 -w /tmp/capture.pcap | Wiresharkなどで後から解析する |
| 保存ファイルを読む | -r | tcpdump -r /tmp/capture.pcap | 保存されたパケットを表示 |
| 再生時にフィルタ | -r と組み合わせ | tcpdump -r /tmp/capture.pcap port 80 | 保存ファイルからHTTPだけ抽出 |
tcpdumpの主要オプション一覧
以下は、現場で頻繁に使われるtcpdumpオプションの早見表です。構文と目的を明確に把握しておくことで、効率よくパケット調査が行えます。
| オプション | 構文例 | 目的 | 補足説明 |
|---|---|---|---|
| -i | tcpdump -i eth0 | 監視対象のインターフェースを指定 | 未指定では起動失敗。tcpdump -D で一覧確認可能 |
| -n | tcpdump -n | IPやポート番号を数値のまま表示 | 名前解決を抑止。表示速度・視認性が向上 |
| -v / -vv | tcpdump -vv | 詳細なヘッダー情報を表示 | -vでTTLなど、-vvでTCPオプションまで出力 |
| -X | tcpdump -X | データ部分を16進＋ASCIIで表示 | HTTPリクエストやログイン情報の可視化に有効 |
| -XX | tcpdump -XX | ヘッダー含む全パケットを表示 | より低層からのトラブル調査向き。情報量が多い |
疎通確認の具体例
サーバ冗長化構成を導入しているシステムでは、ネットワークトラブルの原因を特定するために、パターン別の通信確認が欠かせません。特に、宛先が固定されているケースと、負荷分散が行われるケースでは、tcpdumpの確認方法が異なります。ここでは、2つの代表的な構成に対する疎通確認の実例を解説します。
サーバ冗長化構成（宛先固定）
この構成では、クライアントからの通信はロードバランサーを経由しますが、リクエストは常に特定のApacheサーバ（Webサーバ）へ転送されます。つまり、1対1の通信関係が継続される点が特徴です。
確認のポイントは以下の通りです。
| 確認箇所 | 確認コマンド | 目的 |
|---|---|---|
| Webサーバ（Apache） | tcpdump -i eth0 port 8080 | mod_proxyを通じてTomcatへのリクエスト転送を確認 |
| APサーバ（Tomcat） | tcpdump -i eth0 port 5432 | DBサーバへのJDBCアクセスを確認 |
| DBサーバ（PostgreSQL） | tcpdump -i eth0 host {TomcatのIP} | 特定TomcatからのDBアクセスを限定して確認 |
この構成では、通信の流れが明確なため、tcpdumpで各区間の疎通を逐次トレースすることで、障害箇所を迅速に特定できます。
サーバ冗長化構成（宛先固定）の疎通確認手順
宛先固定構成では、Webブラウザ（WB）ごとに接続先のAPサーバが固定されています。そのため、WB01→AP01、WB02→AP02の両パターンをそれぞれ確認する必要があります。
- AP01で以下のコマンドを実行して、WB01/WB02からの通信を監視します。
tcpdump -i <インターフェース> port 8009 and host WB01
tcpdump -i <インターフェース> port 8009 and host WB02
- AP02でも以下のコマンドを同様に実行します。
tcpdump -i <インターフェース> port 8009 and host WB01
tcpdump -i <インターフェース> port 8009 and host WB02
- WB01から以下のコマンドを実行し、通信がAP01に向いていることを確認します。
curl http://www.example.com/app1/ -kL
- WB02からも同様に以下のコマンドを実行し、通信がAP02に向いていることを確認します。
curl http://www.example.com/app1/ -kL
※ 宛先固定構成では、クライアントごとに接続先が決まっているため、逆のパターン（WB02→AP02／WB01→AP01）も必ず確認します。
- ログ確認：
- WB01のリクエスト時、AP01に以下のようなログが表示され、AP02には表示されないことを確認します。
IP WB01.52430 > AP01.8009: Flags [P.], length 512
（AP02はログなし）
- WB02のリクエスト時、AP02に以下のようなログが表示され、AP01には表示されないことを確認します。
IP WB02.52431 > AP02.8009: Flags [P.], length 512
（AP01はログなし）
- WB01のリクエスト時、AP01に以下のようなログが表示され、AP02には表示されないことを確認します。
APサーバ冗長化構成（負荷分散）
この構成では、ApacheがTomcat複数台へリクエストを振り分ける負荷分散（mod_proxy_balancer）を構成しています。リクエストごとに宛先Tomcatが変わるため、常に同じサーバでログやパケットを観測できるとは限りません。
確認のポイントは以下の通りです。
| 確認箇所 | 確認コマンド | 補足 |
|---|---|---|
| Apache（リクエスト分配元） | tcpdump -i eth0 port 8080 | 転送先Tomcatが動的に切り替わることを確認 |
| Tomcat（2台構成） | tcpdump -i eth0 port 5432 | 両方のTomcatでそれぞれ確認が必要 |
| DBサーバ | tcpdump -i eth0 port 5432 | JDBCアクセス元が複数存在するため、src IPを分離 |
この構成では、1台のTomcatだけを監視しても全体像が見えません。すべてのTomcatサーバでtcpdumpを並行実行し、どのサーバがどのタイミングで処理を受けているのかをログと突き合わせて判断する必要があります。
APサーバ冗長化構成（負荷分散）の疎通確認手順
この構成では、Apacheが複数のTomcatサーバに対してラウンドロビンなどの方式でリクエストを分配します。そのため、同じURLに対してcurlを複数回実行すると、リクエストが異なるTomcatに届く可能性があります。どのTomcatが受信したかを確認するには、全APサーバでtcpdumpを並行して実行し、それぞれの応答を観測する必要があります。
- AP01で以下のコマンドを実行してパケットを監視します。
tcpdump -i <インターフェース> port 8009 and host WB01
tcpdump -i <インターフェース> port 8009 and host WB02
- AP02でも以下のコマンドを同様に実行します。
tcpdump -i <インターフェース> port 8009 and host WB01
tcpdump -i <インターフェース> port 8009 and host WB02
- WB01で以下のコマンドを複数回実行し、リクエストがAP01/AP02に分散しているか確認します。
curl http://www.example.com/app1/ -kL
- WB02でも以下のコマンドを複数回実行し、同様に確認します。
curl http://www.example.com/app1/ -kL
- AP01とAP02それぞれで以下のようなログが交互またはバラけて表示されることを確認します。
IP WB01.52430 > AP01.8009: Flags [P.], length 512
IP WB02.52431 > AP02.8009: Flags [P.], length 512
この手順は「ラウンドロビンなどの明示的な分散設定がされている場合」に有効です。セッション維持や状態管理が有効になっている環境では、curlを繰り返しても同じサーバに到達するケースがあります。その場合でも、tcpdumpで複数の宛先に通信が到達しているかを観測すれば、負荷分散が機能する構成であること自体は検証できます。
通信トラブル診断のための使い方
tcpdumpは通信の流れを目で確認するための強力なツールです。しかし、tcpdumpの「出力の意味」を理解していないと、単なる文字列の羅列に見えてしまいます。本記事では、実際の出力イメージを見ながら、トラブルシューティングの実践的な流れを解説していきます。
クライアント側での確認ポイント
クライアント側では、tcpdumpを使って対象サーバーへ送信されたパケットがきちんと出ているかどうかを確認します。tcpdumpの出力で確認すべきは、宛先IP・ポート・フラグ（Flags）・長さ（length）などです。 例えば、以下のように表示されていれば、クライアント側は正常に通信を開始しています。
[root@client01 ~]# tcpdump -i eth0 port 8009 and host 192.168.1.10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:12:05.123456 IP client01.48766 > server01.8009: Flags [S], seq 1234567890, win 29200, length 0
このように、Flagsが [S]（SYN）であれば、接続開始を試みていることがわかります。逆にこの行が出てこなければ、クライアントからの通信が出ていないということになり、アプリケーション設定や名前解決の問題が考えられます。
サーバー側での確認ポイント
サーバー側では、tcpdumpを使ってクライアントから届いたSYNパケットに対して、SYN-ACKで応答しているかどうかを確認します。 以下は、接続が成功している時のサーバー側出力例です。
[root@server01 ~]# tcpdump -i eth0 port 8009 and host 192.168.1.20
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:12:05.123456 IP client01.48766 > server01.8009: Flags [S], seq 1234567890, win 29200, length 0
09:12:05.123789 IP server01.8009 > client01.48766: Flags [S.], seq 987654321, ack 1234567891, win 28960, length 0
09:12:05.124000 IP client01.48766 > server01.8009: Flags [.], ack 987654322, win 28960, length 0
このように [S] → [S.] → . の順でやり取りされていれば、いわゆる3ウェイハンドシェイクが成立しており、通信は正常に確立されています。
SYN/ACKのやり取りから判断する手順
tcpdumpの出力を見れば、どこで通信が止まっているのかが一目でわかります。以下の表を参考にすれば、出力内容から現在の接続状況を正確に判断できます。
| 出力内容 | Flags | 意味 | 判断ポイント |
|---|---|---|---|
| クライアント → サーバー | [S] | 接続開始（SYN） | 通信開始を試みている |
| サーバー → クライアント | [S.] | 応答（SYN-ACK） | 正常応答がある |
| クライアント → サーバー | [.] | 接続確立完了（ACK） | 3ウェイハンドシェイク成功 |
| 以後の通信 | [P.] | データ送信 | 実通信が始まっている |
また、通信確立後のやり取りの一例も掲載しておきます。
[root@WBXX]# tcpdump -i eth0 port 8009 and host AP01
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:21:05.075091 IP WB01.48766 > AP01.8009: Flags [P.], seq 4227198812:4227199124, ack 326741960, win 2560, length 312
02:21:05.076308 IP AP01.8009 WB01.48766: Flags [P.], seq 1:210, ack 312, win 550, length 209
02:21:05.076319 IP WB01.48766 > AP01.8009: Flags [.], ack 210, win 2560, length 0
このように、Flags [P.] が続いている間はアプリケーション通信が継続している状態です。
トラブル調査でよくある誤解
通信トラブルが発生した際、多くの技術者が最初に使うのがtcpdumpです。しかし、現場での利用においては、基本的な誤解や使い方のミスが原因で、肝心な情報を見逃してしまうケースが非常に多く見受けられます。tcpdumpの力を正しく引き出すためには、ツールの本質と誤解されやすい落とし穴を知っておく必要があります。
「tcpdumpを1台で使えば充分」の危険性
tcpdumpは「通信の中身を片側から覗き見る」ためのツールです。そのため、1台のサーバーにtcpdumpを仕掛けて、通信のすべてを把握できると思っていると、大きな見落としに繋がります。
実際の通信は送信側と受信側の両者で構成されており、どちらか一方だけで確認できる情報には限界があります。たとえば、クライアント側ではSYNパケットを送っているにも関わらず、サーバー側では何も受信していないケースでは、ネットワーク機器の途中で遮断されている可能性があります。このような状況は、どちらか片方だけを確認していると原因特定に行き詰まります。
以下は、通信の確立過程をtcpdumpで追跡した場合の出力例です。
[root@client01 ~]# tcpdump -i eth0 port 8009 and host 192.168.1.10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:34:01.123456 IP client01.48766 > server01.8009: Flags [S], seq 1000000000, win 29200, length 0
この出力では、クライアントからサーバーへのSYN（接続要求）パケットが送信されていることがわかります。しかし、サーバー側で以下のような応答がなければ、通信は成立していません。
[root@server01 ~]# tcpdump -i eth0 port 8009 and host 192.168.1.20
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
（出力なし）
このように、送信したつもりでも受信されていないパターンは非常に多く、双方を同時にtcpdumpで監視することで初めて原因が浮かび上がります。
フィルタ条件を誤ると何も見えない
tcpdumpでは「何をキャプチャするか」を明示するためにフィルタ条件を指定します。しかし、この指定が少しでも間違っていると、対象のパケットが一切表示されないという事態が発生します。これは「通信していない」わけではなく、「見ていない」だけの状態です。
たとえば、宛先ポートを指定する際に以下のようなミスが起きることがあります。
tcpdump -i eth0 port 8080 and host 192.168.1.10（← 実際はポート8009で通信していた）
このような場合、tcpdumpは8080ポートの通信だけを探すため、本来の8009ポート通信は画面に一切表示されません。これにより、「通信が一切行われていない」と早合点してしまうリスクが高まります。
逆に、ポート番号を省略すれば、全トラフィックを取得できますが、不要な情報も大量に流れてしまい、目的の通信を見失ってしまう危険性があります。そのため、正確なポート番号と対象ホストのIPアドレスを把握してからtcpdumpを実行することが重要です。
正しいフィルタ条件を指定した場合のtcpdumpコマンド例は以下の通りです。
tcpdump -i eth0 port 8009 and host 192.168.1.10
また、ARPやICMPのようにポート番号が存在しないプロトコルの場合は、icmpやarpといったキーワードを使ってキャプチャ対象を明示する必要があります。
tcpdump診断を成功させるための基本フロー
最後に、tcpdumpを使った診断を確実に成功させるために、現場で有効な基本フローを以下の表にまとめます。
| ステップ | 目的 | 必要な確認 |
|---|---|---|
| ① 実行前準備 | フィルタ条件の設定 | IP/ポート/プロトコルの確認 |
| ② クライアント側で確認 | 送信が行われているか | SYNパケットが出ているか |
| ③ サーバー側で確認 | 受信されているか | SYNを受け取っているか |
| ④ 応答の有無 | SYN-ACKの戻り確認 | サーバーから応答があるか |
| ⑤ 通信継続の確認 | ACK/データ送受信 | 3WHSや[P.]の存在 |
このように、tcpdumpはその出力結果だけでなく、「どこで」「どの条件で」「どの方向で」使うかが極めて重要です。設定ミスや誤解によって、誤った診断結果に導かれることがないよう、常に正確な前提知識と操作が求められます。
tcpdumpの注意点と制限事項
tcpdumpはLinux環境で定番のパケットキャプチャツールですが、便利な一方で使用時に気をつけるべき注意点や制限事項があります。特に実際のトラブル調査や通信の可視化に使う際には、これらの制限を理解していないと正しい結果が得られず、誤った判断につながる危険性があります。
root権限が必要な理由
tcpdumpは基本的にroot権限での実行が求められます。これはネットワークインターフェースを「プロミスキャスモード」で操作する必要があるためです。
一般ユーザー権限では、ネットワーク層の情報を直接取得することができません。そのため、たとえば以下のようなコマンドを打っても、rootでなければ実行できず、エラーになります。
tcpdump -i eth0 port 80
このような場合には、必ずsudoを使って実行してください。
sudo tcpdump -i eth0 port 80
このときsudoersの設定やポリシーにより、パスワードを求められる可能性があります。
ネットワークカードの制限
tcpdumpが正しく動作するためには、対応しているネットワークカードであることが前提です。仮想環境（特に古い仮想NIC）や一部のクラウド環境では、そもそもtcpdumpが意図した通りに動作しないケースがあります。
これは、NICが「Promiscuous Mode」に対応していない、もしくは対応していても仮想ハードウェア上でそれが無効化されている場合に発生します。たとえば以下のようなケースです。
| 環境 | 動作可否 | 備考 |
|---|---|---|
| 物理サーバー（Intel NIC） | ○ | 最も安定して使用可能 |
| 仮想環境（VMware + E1000） | △ | 一部の通信が見えない場合あり |
| クラウド（AWS EC2） | × | Promiscuous Modeが無効 |
仮想NICを使っている環境では、ブリッジ構成かつ通信相手のIPが明確な場合に限定して活用するほうが無難です。また、tcpdumpを用いた診断の信頼性が落ちる可能性も常に考慮しておくべきです。
加えて、インターフェースを間違えると何も見えない、ということも発生します。使用中のネットワークデバイスはあらかじめ以下のコマンドで確認しておきましょう。
ip a
出力されたインターフェース（例: eth0, ens33など）を指定してtcpdumpを実行してください。
sudo tcpdump -i ens33 port 22
また、特に冗長化されたネットワーク環境では、管理者が意図していない経路を通っている場合もあるため、tcpdumpでパケットが「見えない」場合は、インターフェースや構成ミスの可能性も考慮する必要があります。
キャプチャ対象とキャプチャポイントのズレ
tcpdumpはあくまで「そのインターフェースから見えている世界」のみを表示します。そのため、通信が発生しているはずなのに見えない、という現象が起こることがあります。たとえば、以下のようなコマンドをサーバーICWB01上で実行したとします。
tcpdump -i eth0 port 8009 and host ICAP01
期待する通信ログは以下のようになります。
02:21:05.075091 IP ICWB01.48766 > ICAP01.8009: Flags [P.], seq 4227198812:4227199124, ack 326741960, win 2560, options [nop,nop,TS val 255325841 ecr 254837952], length 312
02:21:05.076308 IP ICAP01.8009 > ICWB01.48766: Flags [P.], seq 1:210, ack 312, win 550, options [nop,nop,TS val 255324694 ecr 255325841], length 209
このように、明確な送信・応答パケットが見えるのが理想ですが、対象NICを間違えたり、そもそもフィルター条件に誤りがあると、通信が存在していても「何も見えない」という結果になることもあります。
また、ファイアウォールやiptablesでローカルへの転送処理が制限されているケースでも、tcpdump上で見えないことがあります。これはtcpdumpが「カーネルに入ってくる前のデータ」または「カーネルから出た後のデータ」を取得しているためで、アプリケーション内部の動作とはズレることがあります。
