【図解】tcpdumpの使い方｜Linuxネットワーク障害のパケット解析・トラブルシューティング

2026.01.22

はじめに

LinuxでNetwork障害が発生した場合、ip、ss、nstatなどを使うことで、Interface、Routing、Neighbor、TCP / Socketなどを順番に切り分けることができます。

しかし、「TCP Connectionが確立しない」「Timeoutが発生する」「Retransmissionが増えている」といったところまで分かっても、実際にどのPacketが送信され、どの応答が返ってきているのかまでは通常の統計情報だけでは分からないことがあります。

このような場合に有効なのが tcpdumpです。tcpdumpを利用すると、Linux ServerのNetwork Interfaceを流れるPacketをCaptureし、TCP 3-way Handshake、RST、Retransmission、DNS Query / ResponseなどをPacket Levelで確認できます。

本記事では、Linuxトラブルシューティング連載のPacket解析編として、tcpdumpの基本的な取得方法だけでなく、取得したPacketをEvidenceとしてNetwork障害をどのように切り分けるかを実践的に解説します。

tcpdumpとは

tcpdumpは、Network Interfaceを通過するPacketをCaptureし、Header情報を表示したりpcap形式のファイルとして保存したりできるPacket Analyzerです。

Network障害では、ログや統計情報だけでは「Packetを送信したのか」「相手から応答が返ったのか」「途中でConnectionがResetされたのか」が分からないことがあります。tcpdumpを使うことで、実際のPacket Flowから通信の事実を確認できます。

確認したいことPacketで見るポイント
TCP Connectionが確立しているかSYN → SYN/ACK → ACK
接続を拒否されていないかRST / RST,ACK
Packet Lossが疑われるかRetransmission、ACKの状況
Serverが応答しているかRequest後にResponse Packetが返っているか
DNS名前解決が成功しているかDNS Query → Response、Response Code

重要なのは、tcpdumpを「とりあえず全Packetを取得するTool」として使わないことです。まず通常のNetwork調査で仮説を立て、その仮説をPacket Levelで確認するために利用します。

tcpdumpによるPacket解析の全体像

Network障害が発生したら、最初からtcpdumpを実行するのではなく、まずip、ss、nstatなどで異常箇所を絞り込みます。そのうえで「TCP Handshakeが失敗しているのではないか」「Packet Lossが発生しているのではないか」などの仮説を立て、tcpdumpで検証します。

tcpdumpの基本的な使い方

基本構文

tcpdump [オプション] [Capture Filter]

tcpdumpでは、「どのInterfaceで取得するか」「どのように表示・保存するか」「どの通信を取得するか」を指定します。

Interfaceを指定する

# tcpdump -i eth0 -n
Option意味見るポイント
-i eth0CaptureするInterfaceを指定実際に通信が通るInterfaceを指定
-nnHost名・Service名への変換を行わないIP AddressとPort番号を数値のまま確認する

どのInterfaceを通るか分からない場合は、事前にip route getなどでDestinationへのOutput Interfaceを確認します。調査目的によっては-i anyも利用できます。

Capture Filterで取得対象を絞る

本番環境では、IP Address、Port、Protocolなどで対象を絞ることが重要です。無条件に全通信を取得すると、必要なPacketを探しにくくなるだけでなく、取得量や保存容量も増加します。

特定Hostとの通信

# tcpdump -i eth0 -nn host 10.0.0.5

特定Portの通信

# tcpdump -i eth0 -nn port 443

TCPのみ取得

# tcpdump -i eth0 -nn tcp

HostとPortを組み合わせる

# tcpdump -i eth0 -nn host 192.168.1.10 and port 443

実務では対象HostとPortを組み合わせ、障害対象の通信だけに絞る方法が有効です。

送信元・宛先を限定する

# tcpdump -i eth0 -nn src host 192.168.1.10
# tcpdump -i eth0 -nn dst host 192.168.1.20
# tcpdump -i eth0 -nn src port 443
# tcpdump -i eth0 -nn dst port 443

tcpdump取得例

接続先ホストおよびポート番号を指定して、tcpdumpを取得した例を以下に記載します。

pcapファイルとして安全に取得する

ファイルに保存する

# tcpdump -i eth0 -nn host 192.168.1.10 and port 443 -w /tmp/capture.pcap

-wを指定するとPacketをpcapファイルへ保存できます。pcapとして保存しておけば、取得後に解析条件を変えて確認できるため、障害時のEvidence取得に適しています。

pcapを読み込む

$ tcpdump -nn -r /tmp/capture.pcap

サイズ制限・ローテーション

# tcpdump -i eth0 -nn -w /tmp/capture.pcap -C 100 -W 5

上記は約100 MBごとにファイルを切り替え、最大5ファイルの循環Bufferとして取得する例です。Traffic量が多い環境では、Disk枯渇を防ぐため取得量を必ず制御してください。

TCP 3-way Handshakeを解析する

TCP Connectionの問題では、まず3-way Handshakeを確認します。

表示意味見るポイント
[S]SYNConnection開始要求
[S.]SYN + ACKServerからの応答
[.]ACK受信確認など
[P.]PSH + ACKApplication Dataを含むことが多い
[F.]FIN + ACKConnection終了処理
[R] / [R.]RSTConnection Reset

SYN → SYN/ACK → ACKの3つのPacketが確認できれば、少なくともCapture PointではTCP 3-way Handshakeが正常に進んでいることを確認できます。SYNだけが繰り返され、SYN/ACKが観測できない場合は、Serverへの到達性、Firewall、Network経路、Server側の状態などを確認します。

Connection Refused / RSTを解析する

Connection Refusedでは、ClientがSYNを送信した後、RSTが返るケースがあります。代表例は到達したHostで対象TCP PortがLISTENしていない場合です。

RSTを確認した場合は、RSTを誰が返しているのかを確認します。Server自身だけでなく、Firewall、Load Balancer、ProxyなどがRSTを返す場合もあります。

RSTの送信元がServerの場合は、対象PortでProcessがLISTENしているか確認します。

# ss -lntp | grep :443

TCP Retransmissionを解析する

Network遅延やTimeoutが発生している場合は、TCP Retransmissionが発生していないか確認します。TCPでは、送信したDataに対するACKが期待どおり返らない場合などにSegmentが再送されます。

tcpdumpではSequence NumberやACK Number、Timestampを確認できます。ただしRetransmissionの判定はPacketの前後関係を追う必要があるため、pcapとして保存し、WiresharkのTCP Analysis機能を併用すると解析しやすくなります。

Retransmissionが確認できても、直ちにNetwork機器が原因とは断定できません。Capture Point、Packet Dropの発生位置、Client / Serverの処理状況、輻輳などを含めて調査します。

# nstat -az | grep -E 'TcpRetransSegs|TcpAttemptFails|TcpEstabResets'

nstatでTcpRetransSegsの増加傾向を検知したら、tcpdumpで対象Connectionに絞り、Sequence Number、ACK Number、Timestampを時系列で確認します。nstatで異常の傾向を把握し、tcpdumpで対象TCP FlowをPacket Levelで検証するという使い分けが有効です。

nstatコマンドの表示例：

TimeoutをPacketから解析する

「Timeout」という症状だけでは、TCP Connectionを確立できないのか、Connection確立後にApplicationのResponseが返らないのか判断できません。tcpdumpを使うと、Timeoutが通信のどの段階で発生しているかを切り分けられます。

TCP Connection確立前のTimeout

SYNが送信されているのにSYN/ACKが観測できない場合は、Serverへの到達性、Firewall、Network経路、Server側の状態などを確認します。

TCP Connection確立後のTimeout

Handshakeが完了し、RequestもServerまで到達しているにもかかわらずResponseが長時間返っていない場合は、Application、Thread Pool、Connection Pool、Database、Backend APIなどNetwork以外の処理遅延も疑います。

DNS Query / Responseを解析する

Hostnameでの接続だけが失敗する場合や、名前解決に時間がかかっている場合は、DNS QueryとDNS Responseを確認します。tcpdumpを使うと、ClientからDNS Queryが送信されているか、DNS ServerからResponseが返っているかをPacket Levelで確認できます。

確認の流れは、ClientからDNS ServerへQueryを送信し、それに対応するResponseが返っているかを時系列で追うことです。

# tcpdump -i eth0 -nn port 53
確認項目見るポイント
DNS QueryClientからQueryが送信されているか
DNS ResponseDNS ServerからResponseが返っているか
Transaction IDQueryとResponseが対応しているか
Response CodeNOERROR、NXDOMAIN、SERVFAIL、REFUSEDなどを確認

DNSは一般にUDP Port 53を利用しますが、応答サイズや処理内容などによってTCP Port 53が利用される場合もあります。調査時は必要に応じてTCPも確認します。

Wiresharkでpcapを詳細解析する

tcpdumpはServer上で素早くPacketを取得するのに適していますが、長いTCP FlowやRetransmission、Sequence Number、DNSなどを詳細に解析する場合はWiresharkを利用すると効率的です。

【初心者向け】Wiresharkによるパケット解析の基礎｜見方・使い方をやさしく解説

本番環境でtcpdumpを使用する際の注意点

注意点内容対策
Performance高Traffic環境で広範囲にCaptureすると負荷が増える可能性対象と取得時間を限定
Disk容量pcapが肥大化する-C / -Wなどで制限
機密情報Payloadに認証情報、個人情報、業務Dataなどを含む可能性Security Policyに従って保存・転送・削除
Capture PointCapture地点で観測できるPacketだけが記録されるどこで取得したDataかを明確にする

特に重要なのは、取得目的、対象IP / Port、取得時間、保存先を事前に決めることです。「念のため全部取る」のではなく、調査仮説に必要なPacketを取得します。

まとめ

  1. ip / ss / nstat：通常のNetwork情報から問題範囲を絞る。
  2. 仮説：TCP、DNS、Packet Lossなど何を確認するか明確にする。
  3. tcpdump：Host / Portなどで対象を絞ってPacketを取得する。
  4. Handshake：SYN → SYN/ACK → ACKを確認する。
  5. RST / Retransmission：Resetや再送の有無を確認する。
  6. Timeout：Connection確立前かApplication Request後かを切り分ける。
  7. DNS：QueryとResponseを対で確認し、Response Codeなどから名前解決の状態を切り分ける。
  8. Wireshark：pcapからTCP Flowを詳細解析する。

tcpdumpで重要なのはPacketを大量に取得することではありません。「何を確認したいのか」という仮説を持ち、必要なPacketを取得し、RequestとResponseを時系列で追うことです。

「Networkが怪しい」という曖昧な状態から、どのPacketがどこまで到達し、どこから期待した応答が返っていないのかをEvidenceとして確認できるようになると、Networkトラブルシューティングの精度を高めることができます。

スポンサーリンク

コメント