tcpdumpは「嘘をつかない」。BPFフィルターで真実のパケットを射抜く技術
NOCの現場で深夜3時、バックエンドの疎通が断続的に途切れるというアラートが鳴り響くとき、我々が最後に頼るのはマネージドな監視ダッシュボードではない。カーネル直下で蠢くパケットの生データだ。
tcpdumpは単なるデバッグツールではない。それはネットワークという神経系を流れる「血流」を可視化するメスである。しかし、10Gbpsを超えるトラフィックが流れる現代のデータセンターで、フィルターなしのtcpdumpを実行することは自殺行為に等しい。CPU負荷は跳ね上がり、パケットロスを誘発し、さらに事態を悪化させる。
ここで真価を発揮するのが、Berkeley Packet Filter（BPF）構文だ。本稿では、単なるフィルタリングを超え、アーキテクトが知るべきパケットレベルの深淵を紐解いていく。
—
BPFフィルターで「ノイズ」を消し去る
BPFの美学は「カーネル空間で不要なパケットを早期にドロップする」ことにある。ユーザー空間にゴミを送らないだけで、パフォーマンスへの影響は劇的に改善する。
基本にして最強の構文
まずは、特定のホスト間、特定のポートにおける通信のみを抽出する基本形を叩き込む。
# 特定のクライアントIPとサーバーの443ポート（TLS）のみをキャプチャ
# -n: 名前解決を無効化（DNS遅延によるパケットロスを防ぐ）
# -i any: 全インターフェースを対象にするが、高負荷時は特定のNICを指定すること
# -s 0: パケット全体をキャプチャ（スナップショット長を最大に）
tcpdump -n -i eth0 host 192.168.1.50 and port 443ここで重要なのは、tcpdumpのフィルタリングは「パケットのヘッダー解析」に過ぎないという点だ。TLSハンドシェイクのClientHelloやServerHelloを解析する際、BPFフィルターでポートを絞るだけでは不十分な場合がある。
—
TLSハンドシェイクの深淵を覗く
パフォーマンスのボトルネックは、多くの場合、3ウェイハンドシェイク後のTLSネゴシエーションで発生する。RTT（Round Trip Time）を削るために、TCPのInitial Window設定やTCP Fast Open（TFO）を導入しているなら、それらが正しく機能しているかをパケットレベルで監視する必要がある。
特に、TCP_NODELAY（Nagleアルゴリズムの無効化）を適用しているにもかかわらず、小さなパケットがバッファリングされて遅延している場合、tcpdumpで以下のようにフラグを監視する。
# TCPフラグを詳細に監視する（SYN, FIN, ACKの挙動を追う）
# 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0' は接続開始と終了のみを抽出する強力な式
tcpdump -n -i eth0 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-fin) != 0)'このコマンドで、サーバーがSYN/ACKを返した直後にFINを投げつけていないか、あるいはクライアントからのACKが異常に遅れていないかをRTTレベルで追跡できる。
—
脆弱性回避とセキュリティ監視への応用
昨今のインフラ運用において、tcpdumpはセキュリティ監査の要でもある。例えば、平文のHTTPが誤って流れていないか、あるいは許可されていないプロトコルで通信が試行されていないかを検知する。
以下は、異常なポートスキャンや、許可外のプロトコルが混入していないかを監視するための高度なフィルタリング例だ。
# 80/443以外で流れるTCP通信を検出する（シャドーITや不正アクセス検知）
tcpdump -n -i eth0 'tcp and not port 80 and not port 443'ここで得られたパケットの挙動から、TCPバッファの枯渇を確認することも可能だ。もしwindow sizeが頻繁に0になっていれば、それはアプリケーション側の処理が追いついていない（バックプレッシャーの発生）証拠である。sysctlの net.ipv4.tcp_rmem や net.ipv4.tcp_wmem を調整すべきサインだ。
—
実践：パケット損失の真因を特定する
「パケットロス」と言われたとき、それが物理層の問題なのか、カーネルのキュー溢れなのかを切り分ける必要がある。tcpdumpでretransmissionを観測せよ。
# 再送パケットのみを抽出する（TCPヘッダーのシーケンス番号の重複を監視）
# これはネットワークの不安定さを特定する際の「銀の弾丸」となる
tcpdump -n -i eth0 'tcp[tcpflags] & tcp-push != 0'pushフラグが立っているパケットが何度も流れている場合、そのストリームはどこかでパケットロスを起こし、TCPの再送制御（Retransmission Timeout）が働いている。
—
最後に：CLIという名の相棒と
インフラアーキテクトにとって、tcpdumpは単なるコマンドではない。OSがどう考え、NICがどうパケットを処理し、ルーターがどう転送したか。その「真実」を教えてくれる唯一のツールだ。
GUIの分析ツールがいくら進化しようとも、コマンドラインでパケットの断片を眺め、脳内でプロトコルスタックを構築するスキルは廃れない。トラブルに直面したとき、焦らずにBPFフィルターを書き、パケットの脈動を感じ取ってほしい。ネットワークは、いつだって正しい答えをパケットの中に隠しているのだから。
今夜もまた、どこかのデータセンターでパケットが流れている。君のCLIコマンドが、その混乱を紐解く鍵になることを願っている。
コメント