サポートエンジニアとして私がわかりやすく説明してほしいネットワークユーティリティが1つあるとしたら、それはtcpdumpです。 道具。トラブルシューティングに使用する必要がある状況に遭遇した回数を数えることはできませんが、それを完全に理解していないか、どのオプションを知る必要がありますか。今日は、tcpdumpについて詳しく説明します。 ツール—何に使用され、何を知る必要があるか。また、以前に自分が遭遇した状況のモックアップについても説明します。それに飛び込みましょう。
tcpdumpとは何ですか？
tcpdump ツールは1980年代後半に開発され、それ以来、ネットワークのトラブルシューティングの定番となっています。 BSDライセンスの下で配布されており、無料でダウンロードして使用できます。ほとんどの*nixオペレーティングシステムで動作し、Windows用に移植されたバージョンがあります。最も基本的なレベルでは、tcpdump は、ネットワーク接続の問題のトラブルシューティングに使用されるパケットキャプチャツールです。おそらくWiresharkと最も密接に比較されます。ただし、これははるかに軽量で、コマンドラインのみです（私の知る限りGUIはありません）。
インストール
コマンドをいじくり回す前に、コマンドのインストールを見てみましょう。通常、最新のLinux OSに同梱されているため、おそらくすでにお持ちです。これは、which tcpdumpを実行することで確認できます。 。インストールされていなくても心配しないでください。インストールは簡単です。次のコマンドを実行します：
$ sudo yum install -y tcpdump 基本的な使用法
ツールを使用する準備ができたので、最も基本的な機能を見てみましょう。インターフェイスを介してパケットのキャプチャを開始するには、キャプチャに使用できるネットワークインターフェイスを確認する必要があります。これを行うには、次を使用します：
$ sudo tcpdump -D これが私のRedHatEnterpriseLinuxマシンからのサンプルです：
[tcarrigan@server ~]$ sudo tcpdump -D
[sudo] password for tcarrigan:
1.enp0s3 [Up, Running]
2.enp0s8 [Up, Running]
3.lo [Up, Running, Loopback]
4.any (Pseudo-device that captures on all interfaces) [Up, Running]
5.virbr0 [Up]
6.bluetooth-monitor (Bluetooth Linux Monitor) [none]
7.nflog (Linux netfilter log (NFLOG) interface) [none]
8.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
9.usbmon0 (All USB buses) [none]
10.usbmon1 (USB bus number 1)
11.virbr0-nic [none] このコマンドは、特定のタイプのデータを移動するために特定のインターフェイスが使用されるエンタープライズ環境で非常に役立ちます。この状況については、この記事の後半でもう少し詳しく見ていきます。それでは、出力とここで収集している情報を確認できるように、いくつかのパケットをキャプチャしてみましょう。
基本的なキャプチャには、次を使用します。
[root@server ~]# tcpdump -i any
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:42:10.914742 IP server.example.com.55018 > 216.126.233.109.ntp: NTPv4, Client, length 48
18:42:10.915759 IP server.example.com.59656 > router.charter.net.domain: 1974+ PTR? 109.233.126.216.in-addr.arpa. (46)
18:42:10.959920 IP router.charter.net.domain > server.example.com.59656: 1974 ServFail 0/0/0 (46)
18:42:10.960089 IP server.example.com.42825 > router.charter.net.domain: 1974+ PTR? 109.233.126.216.in-addr.arpa. (46)
*** Shortened output ***
^C
17 packets captured
18 packets received by filter
1 packet dropped by kernel
ここでは、-i を使用します インターフェイスを示すフラグ、any 、この場合は聞きたいです。 tcpdumpに注意してください 割り込み信号までパケットをキャプチャし続けます Ctrl + Cを介して与えられます 。使用できる他のオプションは、-cです。 キャプチャされるパケットの数を制限するフラグ。この制限は、正直なところ、私の意見ではコマンドを使用するための最良の方法の1つです。これは、多くの場合、接続性を把握しようとしているためです（これはかなり迅速に診断できます）。
[root@server ~]# tcpdump -i any -c 3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:51:54.509439 IP server.example.com.58249 > 216.126.233.109.ntp: NTPv4, Client, length 48
18:51:54.510413 IP server.example.com.46277 > router.charter.net.domain: 9710+ PTR? 109.233.126.216.in-addr.arpa. (46)
18:51:54.570112 IP 216.126.233.109.ntp > server.example.com.58249: NTPv4, Server, length 48
3 packets captured
10 packets received by filter
1 packet dropped by kernel
tcpdumpを使用してトラブルシューティングするための別の簡単なヒントがあります 。デフォルトでは、IPアドレスとポート番号を名前に解決します（上記を参照）。命名スキームが少し難しい大規模な環境では、この解決策を無効にしてIPアドレスとポート番号を取得できます。技術的なトラブルシューティングの観点から、これははるかに混乱が少ないと思います。また、キャプチャの出力の検索が少し簡単になります。 -nnを使用します 名前とポートの解決を無効にするフラグ ：
[root@server ~]# tcpdump -i any -c3 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
19:56:12.804327 IP 10.0.3.15.41153 > 64.79.100.196.123: NTPv4, Client, length 48
19:56:12.867789 IP 64.79.100.196.123 > 10.0.3.15.41153: NTPv4, Server, length 48
19:56:13.739885 IP 10.0.3.15.50968 > 216.126.233.109.123: NTPv4, Client, length 48
3 packets captured
3 packets received by filter
0 packets dropped by kernel その他の便利なフィルター
IPアドレスでフィルタリングするには：
$ sudo tcpdump host x.x.x.x インターフェースでフィルタリングするには：
$ sudo tcpdump eth0 ソースでフィルタリングするには：
$ sudo tcpdump src x.x.x.x 宛先でフィルタリングするには：
$ sudo tcpdump dst x.x.x.x プロトコルでフィルタリングするには：
$ sudo tcpdump icmp キャプチャを最も有用なトラフィックのみに絞り込むためのオプションとフィルターは多数あります。詳細が必要な場合は、manページまたはその他のオンラインソースを確認してください。
実用的なアプリケーション
先に述べたように、サポートエンジニアとしての時間は、本番環境からディザスタリカバリ環境へのデータレプリケーションのトラブルシューティングにかなりの時間を費やしました。多くの場合、顧客は、本番サーバーからレプリケーションターゲットサーバーにトラフィックを送信するように指定されたレプリケーションインターフェイスを設定します。基本的なレベルでどのように見えるかを見ていき、tcpdumpを使用してみましょう。 送信元インターフェースから宛先へのトラフィックを確認します。
前提条件
- ソースサーバー-172.25.1.5
- 宛先サーバー-172.25.1.4
- レプリケーションインターフェイス-enp0s8
理論的には、データレプリケーションジョブを開始すると、172.25.1.5から172.25.1.4へのトラフィックフローが表示されます。
簡単な「レプリケーション」を開始しました（ping ）ソースサーバーのバックグラウンドでのジョブ。次に、tcpdumpを実行します 送信元サーバーと宛先サーバーで、トラフィックを受信しているかどうかを確認します。
ソースから：
[root@server ~]# tcpdump -i enp0s8 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes
23:17:55.347648 ARP, Request who-has 172.25.1.4 tell 172.25.1.5, length 28
23:17:56.378194 ARP, Request who-has 172.25.1.4 tell 172.25.1.5, length 28
23:17:57.398294 ARP, Request who-has 172.25.1.4 tell 172.25.1.5, length 28
23:17:58.422946 ARP, Request who-has 172.25.1.4 tell 172.25.1.5, length 28
23:17:59.448412 ARP, Request who-has 172.25.1.4 tell 172.25.1.5, length 28
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel 上記のトラフィックは単なるリクエストであり、ターゲットからの応答はありません。実際のシナリオでは、送信元インターフェイスを介して送信されているトラフィックを明確に確認できるため、これは宛先に問題があることを示しています。
宛先インターフェースをオンに戻した後...
問題が特定されて解決された後の送信元と宛先からのトラフィックキャプチャは次のとおりです。
出典：
[root@server ~]# tcpdump -i enp0s8 -c3 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes
23:22:04.694919 IP 172.25.1.5 > 172.25.1.4: ICMP echo request, id 7168, seq 911, length 64
23:22:04.695346 IP 172.25.1.4 > 172.25.1.5: ICMP echo reply, id 7168, seq 911, length 64
23:22:05.724968 IP 172.25.1.5 > 172.25.1.4: ICMP echo request, id 7168, seq 912, length 64
3 packets captured
3 packets received by filter
0 packets dropped by kernel 目的地：
[root@client ~]# tcpdump -i enp0s8 -c3 -nn
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s8, link-type EN10MB (Ethernet), capture size 262144 bytes
23:22:13.916519 IP 172.25.1.5 > 172.25.1.4: ICMP echo request, id 7168, seq 920, length 64
23:22:13.916569 IP 172.25.1.4 > 172.25.1.5: ICMP echo reply, id 7168, seq 920, length 64
23:22:14.935720 IP 172.25.1.5 > 172.25.1.4: ICMP echo request, id 7168, seq 921, length 64
3 packets captured
4 packets received by filter
0 packets dropped by kernel 出力を詳しく見ると、トラフィックがソースサーバーからターゲットサーバーに正常に送信されていることがわかります。
概要
tcpdumpの内容と理由を学びました 今日、そして知っておくべきオプション。実際のユースケースも調べました。明らかに、ライブ環境には他の考慮事項があります。 （この例のように）インターフェースがダウンしていることから、ネットワーク上の不正なパスワードまで、すべてが失敗の原因となる可能性があります。経験だけがこれらのレッスンを教えてくれますが、少なくとも今では、問題の特定を開始する方法を知っています。次の記事では、フィルターオプション、キャプチャをファイルに出力する方法、およびgrepを使用する方法について詳しく説明します。 干し草の山から針を見つけるために。必ず注意してください。
tcpdumpの使用の詳細については、Opensource.comのLinuxコマンドラインでtcpdumpの使用の概要を確認し、Red HatEnterpriseLinux内のtcpdumpの詳細についてはRedHatカスタマーポータルの公式ドキュメントを参照してください。環境。
[ネットワークが制御不能になっていますか？ Red Hatの無料の本、みんなのためのネットワーク自動化をチェックしてください。 ]