サーバーを停止・廃止する前に、
「このサーバーを止めても、他システムに影響はないか」
を確認したいことがあります。
その際、tcpdump を使えば、実際にサーバーが送受信している通信を確認できます。
ただし、ARPやブロードキャスト、マルチキャストなどの通信も大量に流れるため、単純に tcpdump を実行するだけでは、本当に確認したい通信が埋もれてしまうことがあります。
この記事では、サーバー停止前の影響調査を目的として、tcpdumpでどのように通信を確認すればよいかを整理します。
1. まずは通信をすべて保存する
最初に、後から調査できるよう、通信をpcapファイルとして保存しておくと便利です。
sudo tcpdump -i eth0 -nn -s 0 -w /tmp/before_shutdown.pcap
オプションの意味は以下です。
-
-i eth0- キャプチャ対象のNICを指定
-
-nn- IPアドレスやポート番号を名前解決しない
-
-s 0- パケットを省略せず取得する
-
-w- 結果をpcapファイルへ保存する
NIC名が分からない場合は、次のように確認できます。
ip -br addr
可能であれば、数分だけではなく、実際に利用される可能性のある時間帯を含めて一定時間取得するのが望ましいです。
例えば、1時間に1回だけ行われる定期処理は、5分間のキャプチャでは見つかりません。
2. ブロードキャスト・マルチキャストを除外して確認する
まず確認したいのは、特定のホスト間で行われている通常の通信です。
sudo tcpdump -i eth0 -nn -- \
'(tcp or udp) and not broadcast and not multicast'
これにより、主にTCP・UDPのユニキャスト通信を確認できます。
例えば、
10.0.0.25.54321 > 10.0.0.10.443
10.0.0.10.12345 > 10.0.0.30.3306
のような通信が確認できた場合、
-
10.0.0.25がこのサーバーのHTTPSを利用している - このサーバーが
10.0.0.30のMySQLへアクセスしている
といった可能性を調査できます。
サーバー停止前の確認では、こうした特定ホストとの通信が特に重要です。
3. このサーバーへの新規TCP接続を確認する
TCP通信の場合、既存通信のACKなどをすべて眺めるよりも、
「誰がこのサーバーへ新しく接続しているか」
を見ると、サーバーの利用状況を把握しやすくなります。
例えばサーバーのIPアドレスが、
10.0.0.10
の場合、次のように確認できます。
sudo tcpdump -i eth0 -nn -- \
'dst host 10.0.0.10 and tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack = 0'
これは、
このサーバー宛てのSYNパケット
を取得しています。
つまり、TCPの新規接続開始を確認できます。
例えば、
10.0.0.25.52134 > 10.0.0.10.443: Flags [S]
10.0.0.30.41231 > 10.0.0.10.22: Flags [S]
という通信があれば、
-
10.0.0.25がHTTPSへ接続 -
10.0.0.30がSSHへ接続
していることが分かります。
サーバー停止影響を確認するうえでは、かなり重要な情報です。
4. このサーバーが開始しているTCP接続を確認する
逆方向も確認します。
つまり、
「このサーバー自身が、どこへ接続しているか」
です。
sudo tcpdump -i eth0 -nn -- \
'src host 10.0.0.10 and tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack = 0'
例えば、
10.0.0.10.45000 > 10.0.0.30.3306: Flags [S]
という通信があれば、このサーバーが 10.0.0.30:3306 に対して接続を開始しています。
つまり、このサーバーが別システムを利用して何らかの処理を実行している可能性があります。
サーバーが、
- バッチサーバー
- 監視サーバー
- データ連携サーバー
- ジョブ実行サーバー
などの場合は、特にこちらの通信確認も重要です。
5. UDP通信を確認する
UDPには、TCPのSYNのような「接続開始」を示すパケットがありません。
そのため、UDPについては実際の通信を確認します。
sudo tcpdump -i eth0 -nn -- \
'udp and not broadcast and not multicast'
例えば、
10.0.0.10.50000 > 10.0.0.20.53
であれば、DNS通信の可能性があります。
また、
10.0.0.40.60000 > 10.0.0.10.514
であれば、このサーバーがsyslogサーバーとして使われている可能性があります。
UDPはTCPのように接続状態を確認できないため、見落とさないよう注意します。
6. ブロードキャスト・マルチキャストは「無視」ではなく別途確認する
ブロードキャストやマルチキャストは大量に流れることがあるため、通常通信を見るときには除外すると見やすくなります。
ただし、
ブロードキャスト・マルチキャストだから停止影響がない
とは限りません。
そのため、別途確認します。
sudo tcpdump -i eth0 -nn -- \
'broadcast or multicast'
例えばARPでは、
ARP, Request who-has 10.0.0.20 tell 10.0.0.10
のような通信が発生します。
ARP自体は通常のネットワーク通信に必要な仕組みであり、
「このサーバーが重要なサービスを提供している」
ことを直接意味するわけではありません。
一方で、ブロードキャスト・マルチキャストを利用するものには、
- DHCP
- VRRP
- ルーティングプロトコル
- サービスディスカバリ
- クラスタのハートビート
などもあります。
そのため、ブロードキャストやマルチキャストは通常通信とは分離して確認する、という考え方が安全です。
7. SSH作業中なら、自分の通信を除外する
SSH経由でサーバーへログインして tcpdump を実行している場合、自分自身のSSH通信が大量に表示されます。
例えば作業端末のIPアドレスが、
192.168.1.50
なら、
sudo tcpdump -i eth0 -nn -- \
'(tcp or udp) and not broadcast and not multicast and not host 192.168.1.50'
とすることで、作業端末との通信を除外できます。
SSHだけ除外したい場合は、
sudo tcpdump -i eth0 -nn -- \
'not port 22'
という方法もあります。
ただし、この方法では他のホストからのSSHアクセスまで除外してしまうため、停止影響調査では作業端末のIPアドレスを指定して除外する方が安全です。
8. ss も合わせて確認する
tcpdump だけではなく、ss も合わせて確認するとサーバーの役割を把握しやすくなります。
待ち受けポートを確認します。
ss -lntup
例えば、
LISTEN 0 128 0.0.0.0:443
LISTEN 0 128 0.0.0.0:22
なら、
- 443/TCP
- 22/TCP
を待ち受けています。
現在確立されている通信は、
ss -ntup
で確認できます。
つまり、
-
ss- サーバーが何を待ち受けているか
- 現在どこへ接続しているか
-
tcpdump- 実際にどの通信が流れているか
を見ることができます。
両方を組み合わせることで、より確実にサーバーの利用状況を確認できます。
サーバー停止前に確認するコマンドまとめ
通信全体をpcapへ保存
sudo tcpdump -i eth0 -nn -s 0 -w /tmp/before_shutdown.pcap
通常のTCP・UDPユニキャスト通信
sudo tcpdump -i eth0 -nn -- \
'(tcp or udp) and not broadcast and not multicast'
このサーバーへの新規TCP接続
sudo tcpdump -i eth0 -nn -- \
'dst host SERVER_IP and tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack = 0'
このサーバーから開始するTCP接続
sudo tcpdump -i eth0 -nn -- \
'src host SERVER_IP and tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack = 0'
UDP通信
sudo tcpdump -i eth0 -nn -- \
'udp and not broadcast and not multicast'
ブロードキャスト・マルチキャスト
sudo tcpdump -i eth0 -nn -- \
'broadcast or multicast'
待ち受けポート
ss -lntup
現在のTCP接続
ss -ntup
まとめ
サーバー停止前に通信影響を確認するときは、単純に
tcpdump
の出力を眺めるだけでは、ARPやブロードキャストなどに埋もれてしまいます。
そのため、
- まず通信全体をpcapとして保存する
- TCP・UDPのユニキャスト通信を確認する
- このサーバーへの新規TCP接続を確認する
- このサーバーが開始しているTCP接続を確認する
- UDPを確認する
- ブロードキャスト・マルチキャストは別枠で確認する
-
ssで待ち受けポートや現在の接続も確認する
という流れにすると、サーバーが実際にどのような用途で使われているのかを把握しやすくなります。
特に重要なのは、
「ブロードキャストだから無視する」のではなく、「通常のユニキャスト通信とは分離して確認する」
という点です。
なお、tcpdump で一定時間通信が確認できなかったからといって、必ずしも未使用サーバーとは限りません。
日次・週次・月次バッチなど、低頻度でしか通信しない処理もあるため、実際にサーバーを停止する場合は、ジョブ設定、監視設定、サービス設定、構成管理情報なども合わせて確認するのが安全です。