Wenn es ein Netzwerkdienstprogramm gibt, von dem ich wünschte, es wäre für mich als Supporttechniker entmystifiziert worden, dann ist es tcpdump Werkzeug. Ich kann nicht zählen, wie oft ich auf eine Situation gestoßen bin, in der ich es zur Fehlerbehebung verwenden musste, es aber nicht vollständig verstand oder welche Optionen ich kennen musste. Heute tauche ich tief in den tcpdump ein Werkzeug – wofür es verwendet wird und was Sie wissen müssen. Ich führe Sie auch durch ein Modell einer Situation, in der ich mich zuvor befand. Lassen Sie uns hineinspringen.
Was ist tcpdump?
Der tcpdump Das Tool wurde in den späten 1980er Jahren entwickelt und ist seit dieser Zeit ein fester Bestandteil der Netzwerkfehlerbehebung. Es wird unter einer BSD-Lizenz vertrieben und kann kostenlos heruntergeladen und verwendet werden. Es funktioniert auf den meisten *nix-Betriebssystemen und hat eine portierte Version für Windows. Auf der einfachsten Ebene tcpdump ist ein Tool zur Paketerfassung, das zur Behebung von Netzwerkverbindungsproblemen verwendet wird. Es wird wahrscheinlich am ehesten mit Wireshark verglichen. Es ist jedoch viel leichter und funktioniert nur über die Befehlszeile (meines Wissens ist keine GUI verfügbar).
Installation
Bevor wir anfangen, mit dem Befehl herumzustochern, werfen wir einen Blick auf die Installation. Es wird normalerweise mit den meisten modernen Linux-Betriebssystemen ausgeliefert, sodass Sie es wahrscheinlich bereits haben. Sie können dies überprüfen, indem Sie which tcpdump ausführen . Wenn es nicht installiert ist, machen Sie sich keine Sorgen – die Installation ist einfach. Führen Sie den folgenden Befehl aus:
$ sudo yum install -y tcpdump Grundlegende Verwendung
Nachdem wir das Tool nun einsatzbereit haben, schauen wir uns die grundlegendsten Funktionen an. Um mit dem Erfassen von Paketen über eine Schnittstelle zu beginnen, müssen wir die für die Erfassung verfügbaren Netzwerkschnittstellen sehen. Dazu verwenden wir:
$ sudo tcpdump -D Hier ist ein Beispiel von meinem Red Hat Enterprise Linux-Rechner:
[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] Dieser Befehl ist äußerst nützlich in Unternehmensumgebungen, in denen bestimmte Schnittstellen verwendet werden, um bestimmte Datentypen zu verschieben. Wir betrachten diese Situation in den späteren Teilen dieses Artikels etwas genauer. Lassen Sie uns nun einige Pakete erfassen, damit wir die Ausgabe sehen können und welche Informationen wir hier sammeln.
Verwenden Sie für eine einfache Erfassung Folgendes:
[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
Hier verwenden wir das -i Flag zur Angabe der Schnittstelle, any , in diesem Fall wollen wir weiterhören. Beachten Sie, dass tcpdump fährt fort, Pakete zu erfassen, bis ein Unterbrechungssignal auftritt erfolgt über Strg+C . Die andere Option, die Sie verwenden können, ist -c -Flag, um die Anzahl der erfassten Pakete zu begrenzen. Dieses Limit ist meiner Meinung nach ehrlich gesagt eine der besten Möglichkeiten, den Befehl zu verwenden, da Sie die meiste Zeit versuchen, die Konnektivität herauszufinden (die ziemlich schnell diagnostiziert werden kann).
[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
Ich habe noch einen schnellen Tipp zur Fehlerbehebung mit tcpdump . Standardmäßig löst es IP-Adressen und Portnummern in Namen auf (siehe oben). In großen Umgebungen, in denen Benennungsschemata etwas schwierig sind, können Sie diese Auflösung deaktivieren, um IP-Adressen und Portnummern zu erhalten. Aus Sicht der technischen Fehlerbehebung finde ich das weitaus weniger verwirrend. Es erleichtert auch das Durchsuchen der Ausgabe Ihrer Aufnahme. Wir verwenden den -nn Flag zum Deaktivieren der Namens- und Portauflösung :
[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 Weitere nützliche Filter
So filtern Sie nach IP-Adresse:
$ sudo tcpdump host x.x.x.x So filtern Sie nach Schnittstelle:
$ sudo tcpdump eth0 So filtern Sie nach Quelle:
$ sudo tcpdump src x.x.x.x So filtern Sie nach Ziel:
$ sudo tcpdump dst x.x.x.x So filtern Sie nach Protokoll:
$ sudo tcpdump icmp Es gibt eine Vielzahl von Optionen und Filtern, um Ihre Aufnahmen wirklich auf den nützlichsten Verkehr zu reduzieren. Wenn Sie weitere Informationen benötigen, sehen Sie sich die Manpage oder andere Online-Quellen an.
Praktische Anwendung
Wie bereits erwähnt, verbrachte ich während meiner Zeit als Support Engineer viel Zeit mit der Fehlerbehebung bei der Datenreplikation von Produktions- bis hin zu Disaster-Recovery-Umgebungen. Ein Kunde hat häufig eine bestimmte Replikationsschnittstelle eingerichtet, um Datenverkehr von seinem Produktionsserver an einen Replikationszielserver zu senden. Lassen Sie uns durchgehen, wie das auf einer grundlegenden Ebene aussieht, und verwenden Sie tcpdump um den Datenverkehr von unserer Quellschnittstelle zum Ziel zu überprüfen.
Voraussetzungen
- Quellserver - 172.25.1.5
- Zielserver - 172.25.1.4
- Replikationsschnittstelle - enp0s8
Wenn wir einen Datenreplikationsjob starten, sollten wir theoretisch einen Verkehrsfluss von 172.25.1.5 zu 172.25.1.4 sehen.
Ich habe eine schnelle "Replikation" gestartet (ping )-Job im Hintergrund auf dem Quellserver. Als nächstes führen wir tcpdump aus auf den Quell- und Zielservern, um zu sehen, ob wir den Datenverkehr empfangen.
Aus der Quelle:
[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 Sie können sehen, dass der obige Datenverkehr nur eine Anfrage ist – wir erhalten keine Antwort vom Ziel. In einem realen Szenario würde dies auf ein Problem am Ziel hindeuten, da wir deutlich sehen können, dass der Datenverkehr über die Quellschnittstelle gesendet wird.
Nachdem ich die Zielschnittstelle wieder eingeschaltet habe...
Hier sind die Verkehrsaufzeichnungen von der Quelle und dem Ziel, nachdem das Problem identifiziert und behoben wurde.
Quelle:
[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 Ziel:
[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 Ein genauerer Blick auf die Ausgabe zeigt, dass der Datenverkehr erfolgreich vom Quellserver zum Zielserver gesendet wird.
Zusammenfassung
Wir haben das Was und Warum von tcpdump gelernt heute, sowie Optionen zu wissen. Wir haben uns sogar einen Anwendungsfall aus der Praxis angesehen. Offensichtlich gibt es andere Überlegungen in einer Live-Umgebung. Alles, von ausgefallenen Schnittstellen (wie in diesem Beispiel) bis hin zu schlechten Passwörtern über die Leitung, kann zu Fehlern führen. Nur die Erfahrung lehrt Sie diese Lektionen, aber zumindest wissen Sie jetzt, wie Sie mit der Identifizierung eines Problems beginnen können. Mein nächster Artikel untersucht die Filteroptionen etwas weiter, wie Sie Ihre Aufnahmen in eine Datei ausgeben und grep verwenden um die Nadel im Heuhaufen zu finden. Achten Sie darauf.
Ausführlichere Informationen zur Verwendung von tcpdump finden Sie in dieser Einführung zur Verwendung von tcpdump in der Linux-Befehlszeile auf Opensource.com und in der offiziellen Dokumentation im Red Hat Kundenportal für ein besseres Verständnis von tcpdump in einem Red Hat Enterprise Linux Umgebung.
[ Netzwerk gerät außer Kontrolle? Sehen Sie sich Netzwerkautomatisierung für alle an, ein kostenloses Buch von Red Hat. ]