Si hubiera una utilidad de red que desearía haber sido desmitificada para mí como ingeniero de soporte, es tcpdump herramienta. No puedo contar la cantidad de veces que me encontré con una situación en la que necesitaba usarlo para solucionar problemas, pero no entendía completamente ni qué opciones necesitaba saber. Hoy, profundizo en el tcpdump herramienta:para qué se utiliza y qué necesita saber. También lo guío a través de una maqueta de una situación en la que me encontré anteriormente. Saltemos a ello.
¿Qué es tcpdump?
El tcpdump La herramienta se desarrolló a fines de la década de 1980 y ha sido un elemento básico para la solución de problemas de red desde entonces. Se distribuye bajo una licencia BSD y su descarga y uso son gratuitos. Funciona en la mayoría de los sistemas operativos *nix y tiene una versión portada para Windows. En el nivel más básico, tcpdump es una herramienta de captura de paquetes utilizada para solucionar problemas de conectividad de red. Probablemente se compare más estrechamente con Wireshark. Sin embargo, es mucho más ligero y es solo de línea de comandos (que yo sepa, no hay GUI disponible).
Instalación
Antes de comenzar a hurgar con el comando, echemos un vistazo a su instalación. Por lo general, se envía con la mayoría de los sistemas operativos Linux modernos, por lo que probablemente ya lo tenga. Puede verificar esto ejecutando which tcpdump . Si no está instalado, no se preocupe, la instalación es sencilla. Ejecute el siguiente comando:
$ sudo yum install -y tcpdump Uso básico
Ahora que tenemos la herramienta lista para usar, veamos las funciones más básicas. Para comenzar a capturar paquetes a través de una interfaz, necesitamos ver las interfaces de red disponibles para la captura. Para hacer esto, usamos:
$ sudo tcpdump -D Aquí hay una muestra de mi máquina 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] Este comando es extremadamente útil en entornos empresariales donde se utilizan interfaces específicas para mover tipos particulares de datos. Analizamos esta situación un poco más de cerca en las últimas partes de este artículo. Ahora, capturemos algunos paquetes para que podamos ver el resultado y qué información estamos reuniendo aquí.
Para una captura básica, utilice lo siguiente:
[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
Aquí, usamos el -i bandera para indicar la interfaz, any , en este caso el que queremos escuchar. Tenga en cuenta que tcpdump continúa capturando paquetes hasta que una señal de interrupción se da a través de Ctrl+C . La otra opción que puedes usar es -c bandera para limitar el número de paquetes capturados. Honestamente, en mi opinión, este límite es una de las mejores formas de usar el comando, porque la mayor parte del tiempo está tratando de averiguar la conectividad (que se puede diagnosticar con bastante rapidez).
[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
Tengo otro consejo rápido para solucionar problemas con tcpdump . De forma predeterminada, convierte las direcciones IP y los números de puerto en nombres (ver más arriba). En entornos grandes donde los esquemas de nombres son un poco complicados, puede deshabilitar esta resolución para obtener direcciones IP y números de puerto. Desde una perspectiva técnica de solución de problemas, encuentro esto mucho menos confuso. También hace que la búsqueda a través de la salida de su captura sea un poco más fácil. Usamos el -nn marcar para deshabilitar la resolución de nombre y puerto :
[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 Otros filtros útiles
Para filtrar por dirección IP:
$ sudo tcpdump host x.x.x.x Para filtrar por interfaz:
$ sudo tcpdump eth0 Para filtrar por fuente:
$ sudo tcpdump src x.x.x.x Para filtrar por destino:
$ sudo tcpdump dst x.x.x.x Para filtrar por protocolo:
$ sudo tcpdump icmp Hay una gran cantidad de opciones y filtros para perfeccionar realmente sus capturas y reducir solo el tráfico más útil. Si necesita más información, consulte la página del manual u otras fuentes en línea.
Aplicación práctica
Como mencioné anteriormente, durante mi tiempo como ingeniero de soporte, pasé una cantidad considerable de tiempo solucionando problemas de replicación de datos desde entornos de producción hasta entornos de recuperación ante desastres. Un cliente a menudo tendría una interfaz de replicación designada configurada para enviar tráfico desde su servidor de producción a un servidor de destino de replicación. Veamos cómo se ve eso en un nivel básico y usemos tcpdump para verificar el tráfico desde nuestra interfaz de origen hasta el destino.
Condiciones previas
- Servidor de origen:172.25.1.5
- Servidor de destino:172.25.1.4
- Interfaz de replicación - enp0s8
En teoría, cuando comenzamos un trabajo de replicación de datos, deberíamos ver un flujo de tráfico de 172.25.1.5 a 172.25.1.4.
Empecé una "replicación" rápida (ping ) trabajo en segundo plano en el servidor de origen. A continuación, ejecutamos tcpdump en los servidores de origen y destino para ver si estamos recibiendo el tráfico.
De la fuente:
[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 Puede ver que el tráfico anterior es solo una solicitud; no recibimos una respuesta del objetivo. En un escenario real, esto indicaría un problema en el destino, ya que podemos ver claramente que el tráfico se envía a través de la interfaz de origen.
Después de volver a activar la interfaz de destino...
Estas son las capturas de tráfico desde el origen y el destino después de que se identificó y resolvió el problema.
Fuente:
[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 Destino:
[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 Una mirada más cercana a la salida muestra que el tráfico se envía correctamente desde el servidor de origen al servidor de destino.
Resumen
Aprendimos el qué y el por qué de tcpdump actualidad, así como opciones para conocer. Incluso echamos un vistazo a un caso de uso del mundo real. Obviamente, hay otras consideraciones en un entorno en vivo. Todo, desde interfaces inactivas (como en este ejemplo) hasta malas contraseñas a través del cable, puede causar fallas. Solo la experiencia te enseña estas lecciones, pero al menos ahora sabes cómo empezar a identificar un problema. Mi próximo artículo explora un poco más las opciones de filtro, cómo exportar sus capturas a un archivo y usar grep para encontrar la aguja en tu pajar. Asegúrate de estar atento a eso.
Para obtener información más detallada sobre el uso de tcpdump, consulte esta introducción al uso de tcpdump en la línea de comandos de Linux en Opensource.com, y vea la documentación oficial en el Portal del cliente de Red Hat para comprender mejor tcpdump dentro de Red Hat Enterprise Linux. entorno.
[ ¿La red se sale de control? Consulte Automatización de redes para todos, un libro gratuito de Red Hat. ]