S'il y avait un utilitaire réseau que j'aurais aimé démystifier pour moi en tant qu'ingénieur de support, c'est le tcpdump outil. Je ne peux pas compter le nombre de fois où je me suis retrouvé dans une situation où j'avais besoin de l'utiliser pour le dépannage, mais je ne le comprenais pas complètement ou quelles options j'avais besoin de connaître. Aujourd'hui, je plonge profondément dans le tcpdump outil - à quoi il sert et ce que vous devez savoir. Je vous guide également à travers une maquette d'une situation dans laquelle je me suis trouvé auparavant. Allons-y.
Qu'est-ce que tcpdump ?
Le tcpdump L'outil a été développé à la fin des années 1980 et est depuis lors un incontournable du dépannage réseau. Il est distribué sous licence BSD et peut être téléchargé et utilisé gratuitement. Il fonctionne sur la plupart des systèmes d'exploitation *nix et dispose d'une version portée pour Windows. Au niveau le plus basique, tcpdump est un outil de capture de paquets utilisé pour résoudre les problèmes de connectivité réseau. Il est probablement le plus étroitement comparé à Wireshark. Cependant, il est beaucoup plus léger et n'est disponible qu'en ligne de commande (pas d'interface graphique disponible à ma connaissance).
Installation
Avant de commencer à fouiller avec la commande, jetons un coup d'œil à son installation. Il est généralement livré avec la plupart des systèmes d'exploitation Linux modernes, vous l'avez donc probablement déjà. Vous pouvez le vérifier en exécutant which tcpdump . S'il n'est pas installé, ne vous inquiétez pas, l'installation est simple. Exécutez la commande suivante :
$ sudo yum install -y tcpdump Utilisation de base
Maintenant que nous avons l'outil prêt à l'emploi, examinons les fonctions les plus élémentaires. Pour commencer à capturer des paquets sur une interface, nous devons voir les interfaces réseau disponibles pour la capture. Pour ce faire, nous utilisons :
$ sudo tcpdump -D Voici un exemple de ma machine Red Hat Enterprise Linux :
[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] Cette commande est extrêmement utile dans les environnements d'entreprise où des interfaces spécifiques sont utilisées pour déplacer des types particuliers de données. Nous examinons cette situation un peu plus près dans les dernières parties de cet article. Maintenant, capturons quelques paquets afin que nous puissions voir la sortie et les informations que nous recueillons ici.
Pour une capture de base, utilisez ce qui suit :
[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
Ici, nous utilisons le -i drapeau pour indiquer l'interface, any , dans ce cas que nous voulons écouter. Notez que tcpdump continue de capturer les paquets jusqu'à ce qu'un signal d'interruption est donné via Ctrl+C . L'autre option que vous pouvez utiliser est le -c flag pour limiter le nombre de paquets capturés. Cette limite est honnêtement l'une des meilleures façons d'utiliser la commande à mon avis, car la plupart du temps, vous essayez de comprendre la connectivité (qui peut être diagnostiquée assez rapidement).
[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
J'ai un autre conseil rapide pour le dépannage avec tcpdump . Par défaut, il résout les adresses IP et les numéros de port en noms (voir ci-dessus). Dans les grands environnements où les schémas de nommage sont un peu délicats, vous pouvez désactiver cette résolution pour obtenir les adresses IP et les numéros de port. Du point de vue du dépannage technique, je trouve cela beaucoup moins déroutant. Cela facilite également la recherche dans la sortie de votre capture. Nous utilisons le -nn drapeau pour désactiver la résolution de nom et de port :
[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 Autres filtres utiles
Pour filtrer par adresse IP :
$ sudo tcpdump host x.x.x.x Pour filtrer par interface :
$ sudo tcpdump eth0 Pour filtrer par source :
$ sudo tcpdump src x.x.x.x Pour filtrer par destination :
$ sudo tcpdump dst x.x.x.x Pour filtrer par protocole :
$ sudo tcpdump icmp Il existe un grand nombre d'options et de filtres pour vraiment affiner vos captures jusqu'au trafic le plus utile. Si vous avez besoin de plus d'informations, consultez la page de manuel ou d'autres sources en ligne.
Application pratique
Comme je l'ai dit plus tôt, pendant mon temps en tant qu'ingénieur de support, j'ai passé beaucoup de temps à dépanner la réplication de données de la production aux environnements de reprise après sinistre. Un client aurait souvent une interface de réplication désignée configurée pour envoyer le trafic de son serveur de production vers un serveur cible de réplication. Passons en revue à quoi cela ressemble à un niveau de base et utilisons tcpdump pour vérifier le trafic de notre interface source vers la destination.
Conditions préalables
- Serveur source - 172.25.1.5
- Serveur de destination - 172.25.1.4
- Interface de réplication - enp0s8
En théorie, lorsque nous démarrons une tâche de réplication de données, nous devrions voir le trafic passer de 172.25.1.5 à 172.25.1.4.
J'ai lancé une "réplication" rapide (ping ) travail en arrière-plan sur le serveur source. Ensuite, nous exécutons tcpdump sur les serveurs source et de destination pour voir si nous recevons le trafic.
De la source :
[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 Vous pouvez voir que le trafic ci-dessus n'est qu'une demande - nous n'obtenons pas de réponse de la cible. Dans un scénario réel, cela indiquerait un problème sur la destination, car nous pouvons clairement voir le trafic envoyé sur l'interface source.
Après avoir rallumé l'interface de destination...
Voici les captures de trafic depuis la source et la destination après l'identification et la résolution du problème.
Origine :
[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 Destinataire :
[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 Un examen plus approfondi de la sortie montre que le trafic est envoyé avec succès du serveur source au serveur cible.
Résumé
Nous avons appris le quoi et le pourquoi de tcpdump aujourd'hui, ainsi que des options à connaître. Nous avons même examiné un cas d'utilisation réel. Évidemment, il y a d'autres considérations dans un environnement en direct. Tout, des interfaces en panne (comme dans cet exemple) aux mauvais mots de passe sur le réseau, peut provoquer des échecs. Seule l'expérience vous enseigne ces leçons, mais au moins maintenant vous savez comment commencer à identifier un problème. Mon prochain article explore un peu plus les options de filtrage, comment sortir vos captures dans un fichier et utiliser grep pour trouver l'aiguille dans ta botte de foin. Assurez-vous de garder un œil sur cela.
Pour des informations plus détaillées sur l'utilisation de tcpdump, consultez cette introduction à l'utilisation de tcpdump sur la ligne de commande Linux sur Opensource.com, et consultez la documentation officielle sur le portail client Red Hat pour une meilleure compréhension de tcpdump dans Red Hat Enterprise Linux. environnement.
[ Le réseau devient incontrôlable ? Découvrez l'automatisation du réseau pour tous, un livre gratuit de Red Hat. ]