Linuxの通信トラブル調査で、次のような状況に陥ったことはないでしょうか。
- 通信できない、もしくは極端に遅い
- tcpdump を実行しても何も表示されない
- 「パケットが来ていない？」と混乱する
この状態は、
tcpdumpが見ていない、もしくは見えないだけ
というケースがほとんどです。
本記事では、
- tcpdumpで「何も出ない」本当の理由
- よくある誤解と勘違い
- どう切り分ければ解決と判断できるか
を、実務目線で整理します。
前提：tcpdumpは「全ての通信」を見ているわけではない
まず重要な前提です。
tcpdump は、
指定したインターフェースを通過するパケット
しか表示しません。
つまり、
- そもそもそのIFを通っていない
- カーネル内部で完結している
通信は、最初から見えません。
原因1：見ているインターフェースが違う
最も多い原因です。
以下のような環境では、
- bond / team
- bridge
- veth
- 仮想NIC
実際の通信IFと、 tcpdumpで指定したIFが一致していないことがあります。
確認方法
ip route get 宛先IPどのIFを通るかを必ず確認します。
解決の判断基準：
正しいインターフェースで tcpdump に通信が表示される
原因2：localhost通信（lo）を見ていない
以下の通信は、
- 127.0.0.1
- 同一ホスト内の通信
で完結します。
この場合、
- eth0 では何も出ない
のは正常です。
対処
tcpdump -i lolocalhost通信が見えれば、 ネットワーク問題ではありません。
原因3：IPv6通信を見ていない
ss や ping は IPv6、 tcpdump は IPv4、
という食い違いは非常に多いです。
確認
ss -ant::: や v6 アドレスが見える場合、 IPv6 通信です。
対処
tcpdump -i eth0 ip6解決の判断基準：
IPv6 パケットが tcpdump に表示される
原因4：すでにセッションが確立済み
tcpdump を起動した時点で、
- 接続が ESTABLISHED
していると、
- 新しい SYN が出ない
ため、何も出ないように見えます。
対処
一度接続を切り、再度通信を発生させます。
解決の判断基準：
新規 SYN/ACK が tcpdump に表示される
原因5：フィルタ条件が厳しすぎる
以下のような指定は、
- ポート違い
- プロトコル違い
ですぐに何も出なくなります。
切り分け
tcpdump -i eth0まずはフィルタなしで確認します。
原因6：通信がカーネル内部で完結している
以下のケースでは、
- 同一コンテナ内
- 同一Pod内
veth を越えず、 tcpdumpでは見えないことがあります。
これは異常ではありません。
原因7：実は通信は届いていない
tcpdumpに何も出ない場合、
本当にパケットが届いていない
可能性もあります。
- クラウドFW
- セキュリティグループ
- WAF
Linux以前で遮断されていると、 tcpdumpには何も出ません。
判断基準
外部からの tcpdump でも SYN が見えなければ、 Linuxの問題ではありません。
実務での切り分け思考フロー
- 正しいIFかを確認
- lo / IPv6 を疑う
- フィルタを外す
- 通信を再発生させる
- それでも出なければ経路遮断
まとめ
- tcpdumpに出ない＝通信していないとは限らない
- ほとんどはIF・プロトコルの見誤り
- tcpdumpが見えない理由を一つずつ潰す
tcpdumpで何も出ない時は、
「どこを通っている通信なのか」
を考えることが、最短の解決ルートです。
