tcpdump: mirar paquetes como herramienta de verdad

Cuando una aplicación deja de responder y los logs no dicen nada útil, cuando la monitorización muestra latencias extrañas pero no se sabe dónde está el cuello de botella, cuando dos servicios insisten en que el problema está en el otro lado, alguien acaba abriendo una terminal y escribiendo un comando que lleva décadas resolviendo discusiones: tcpdump. No es la herramienta más moderna ni la más cómoda, pero sigue siendo la que termina con las especulaciones.

Hay algo casi ritual en capturar paquetes de red. Es como abrir el capó de un coche para ver qué está pasando de verdad, más allá de lo que dice el cuadro de mandos. Los dashboards de monitorización muestran agregados, promedios, percentiles. tcpdump muestra conversaciones reales: qué máquina habló con cuál, cuándo, qué dijo exactamente y qué contestó. Esa granularidad tiene un precio en complejidad, pero cuando se necesita, no hay sustituto.

La pregunta no es si tcpdump es útil. La pregunta es cuándo usarlo y cómo no ahogarse en información.

Por qué sigue siendo relevante

En un mundo de herramientas de observabilidad con interfaces gráficas, APIs REST y agentes que envían métricas a plataformas centralizadas, tcpdump parece un anacronismo. Pero sigue apareciendo en situaciones donde todo lo demás falla. Parte de su valor está en que trabaja a un nivel más bajo que casi cualquier otra herramienta de diagnóstico: captura lo que realmente viaja por la red, sin depender de que la aplicación esté funcionando correctamente, sin necesitar agentes instalados, sin confiar en que los logs estén bien configurados.

Es habitual encontrarse con aplicaciones que reportan errores vagos: timeout, connection refused, network unreachable. ¿El problema está en el cliente, en el servidor, en algún firewall intermedio, en el balanceador? tcpdump permite ver el handshake TCP, confirmar que los paquetes llegan a destino, observar si hay retransmisiones, detectar resets inesperados. No interpreta, no agrega: muestra.

Otro escenario común: dos equipos discutiendo sobre quién tiene la culpa de una latencia. El equipo de aplicación dice que el servidor de base de datos es lento. El equipo de base de datos dice que las consultas llegan tarde. Capturar tráfico en ambos extremos resuelve la discusión en minutos. Se puede ver cuándo sale exactamente una petición, cuándo llega al otro lado, cuándo se envía la respuesta y cuándo se recibe. Los timestamps no mienten.

Antes de abrir tcpdump

Antes de capturar paquetes, conviene confirmar qué está pasando a nivel de sockets y puertos. La combinación habitual es tirar primero de ss -tulpn para ver qué servicios están escuchando y en qué interfaces, y de ss -s para un resumen de conexiones activas:

bash

# ¿Qué está escuchando y en qué puerto?
ss -tulpn

# Resumen de conexiones activas
ss -s

Con ese contexto, la captura posterior tiene mucho más sentido. Si en el blog ya has leído cómo comprobar los puertos en uso en Linux, este es el paso anterior natural.

Los filtros son la clave

La mayor dificultad de tcpdump no es técnica: es cognitiva. Una captura sin filtros en una máquina con tráfico moderado puede generar miles de paquetes por segundo. Encontrar los cinco paquetes relevantes en medio de ese flujo requiere saber qué buscar y cómo reducir el ruido desde el principio.

Los filtros usan sintaxis BPF (Berkeley Packet Filter) y son la diferencia entre una herramienta útil y un generador de frustración. La referencia completa está en man pcap-filter, que merece tenerla a mano.

Algunos filtros de uso habitual:

bash

# Ver las interfaces disponibles
tcpdump -D

# Capturar en una interfaz concreta
tcpdump -i eth0

# Solo tráfico de un puerto
tcpdump -i eth0 port 443

# Solo de o hacia una IP específica
tcpdump -i eth0 host 192.168.1.10

# Solo tráfico entre dos máquinas
tcpdump -i eth0 src 10.0.0.1 and dst 10.0.0.2

# Solo SYN: ver intentos de conexión entrante
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

# Solo DNS
tcpdump -i eth0 port 53

# Solo HTTP (no HTTPS cifrado)
tcpdump -i eth0 port 80

# Guardar la captura en fichero para analizarla después
tcpdump -i eth0 port 443 -w captura.pcap

# Limitar bytes capturados por paquete (solo cabeceras, más rápido)
tcpdump -i eth0 -s 96

# Desactivar resolución DNS inversa (muy recomendable, evita lentitud)
tcpdump -i eth0 -n

# Desactivar resolución DNS y de puertos
tcpdump -i eth0 -nn

Nota sobre -n y -nn: son opciones casi obligatorias en producción. Sin ellas, tcpdump intenta resolver cada IP en nombre de host, lo que ralentiza la captura y llena la salida de ruido. -n desactiva la resolución de IPs, -nn desactiva también la de números de puerto (port 443 aparece como 443 en lugar de «https»).

Quien administra sistemas aprende con el tiempo a formular preguntas precisas antes de capturar. No «¿qué está pasando en la red?», sino «¿este servidor está recibiendo paquetes SYN del balanceador?» o «¿cuánto tarda en resolverse esta consulta DNS?». Cuanto más concreta la pregunta, más útil la captura.

Flujo típico: de la captura al análisis

El flujo más habitual en producción es capturar con tcpdump en el servidor donde está el problema y analizar después con Wireshark en una estación de trabajo con más recursos y mejores herramientas. El fichero .pcap es el puente entre ambas herramientas.

(Ver diagrama de flujo arriba)

bash

# 1. Capturar en el servidor (máx. 1000 paquetes, solo puerto 5432)
tcpdump -i eth0 port 5432 -nn -c 1000 -w /tmp/bbdd.pcap

# 2. Copiar el fichero a tu estación local
scp usuario@servidor:/tmp/bbdd.pcap ./

# 3. Abrir con Wireshark para análisis visual
# O leer desde terminal con tshark:
tshark -r bbdd.pcap

Si no puedes o no quieres usar Wireshark, tshark es su alternativa de línea de comandos: decodifica protocolos, permite filtros avanzados, y es la opción cuando necesitas analizar capturas en un servidor sin entorno gráfico. En el blog tienes una mini-guía para usar Wireshark en Windows y Linux que complementa bien todo esto.

Cuándo no es la herramienta adecuada

tcpdump no es para uso continuo. Capturar todo el tráfico de una máquina en producción genera volúmenes de datos inmanejables y puede afectar al rendimiento del sistema. No es una herramienta de monitorización: es una herramienta de diagnóstico puntual. Se usa cuando hay un problema concreto que investigar, no para vigilancia permanente.

Tampoco sirve para todo tipo de problemas. Si el fallo está en la lógica de negocio de una aplicación, mirar paquetes no va a revelar nada útil. Si el problema es de rendimiento de disco o de consumo de memoria, hay herramientas más directas. tcpdump brilla cuando el problema tiene que ver con comunicación entre sistemas: conectividad, latencias de red, comportamiento de protocolos, fallos de DNS, problemas de routing.

Y hay que tener en cuenta que capturar tráfico puede recoger información sensible. Contraseñas en texto claro, tokens de autenticación, datos de usuarios. En entornos con requisitos de cumplimiento normativo, usar tcpdump sin precaución puede crear problemas legales. Siempre conviene filtrar lo mínimo necesario y eliminar las capturas en cuanto se termine el análisis.

Errores habituales

Un error frecuente es capturar en la interfaz equivocada. En máquinas con varias interfaces de red, o en entornos con interfaces virtuales, contenedores o túneles, el tráfico puede no pasar por donde se espera. Antes de capturar, conviene confirmar por qué interfaz viaja realmente el tráfico que interesa:

bash

# Ver todas las interfaces disponibles
tcpdump -D

# O con ip
ip link show

En entornos con Docker o Kubernetes, esto se complica un poco. El tráfico entre contenedores puede viajar por interfaces virtuales (docker0, cni0, vethXXXXXX) que no son visibles a simple vista. En ese caso:

bash

# Ver las interfaces del host incluyendo las virtuales de Docker
ip link show | grep veth

# Capturar en la bridge de Docker
tcpdump -i docker0 port 8080 -nn

# Si necesitas capturar dentro del namespace de red de un contenedor
# primero obtenemos el PID del contenedor:
docker inspect --format '{{.State.Pid}}' <nombre_contenedor>
# y luego entramos en su namespace de red:
nsenter -t <PID> -n tcpdump -i eth0

Otro fallo común: no tener en cuenta el buffering. Las capturas se escriben a disco con cierto retraso. Si el sistema se cae o se interrumpe la captura bruscamente, se pueden perder los últimos segundos de tráfico, que a menudo son los más interesantes. La opción -U fuerza escritura inmediata tras cada paquete:

bash

tcpdump -i eth0 -w captura.pcap -U

También es habitual olvidar que tcpdump solo ve lo que pasa en la máquina donde se ejecuta. Si el problema está en un firewall intermedio que descarta paquetes, o en un router que los reenvía mal, capturar en los extremos no mostrará esa parte de la historia. A veces hace falta capturar en varios puntos del camino para entender qué está pasando. Aquí es donde traceroute y herramientas como SNMP toman el relevo: tenemos en el blog una guía sobre SNMP y Traceroute que cubre bien ese territorio.

Y luego está la tentación de capturar durante demasiado tiempo. Diez minutos de tráfico HTTP en un servidor web pueden ser decenas de gigabytes. Si no se sabe exactamente qué se busca, revisar esa cantidad de datos se vuelve impracticable. Mejor capturas cortas y específicas, repetidas si hace falta, que una captura masiva imposible de analizar.

tshark: cuando Wireshark no está disponible

tshark es la versión de línea de comandos de Wireshark. Comparte el motor de análisis pero funciona sin entorno gráfico, lo que lo hace ideal para servidores en producción. Decodifica protocolos, aplica filtros de visualización avanzados y puede exportar datos en varios formatos:

bash

# Leer y mostrar una captura existente
tshark -r captura.pcap

# Filtrar solo el tráfico HTTP en la lectura
tshark -r captura.pcap -Y "http"

# Ver solo los campos que te interesan
tshark -r captura.pcap -T fields -e ip.src -e ip.dst -e tcp.port

# Capturar directamente (como tcpdump, pero con decodificación de protocolos)
tshark -i eth0 -f "port 443"

La diferencia práctica respecto a tcpdump: donde tcpdump muestra bytes crudos, tshark dice «esto es una respuesta HTTP 200 con estos headers». Para diagnóstico de protocolos de aplicación, es muy superior.

Criterio para el día a día

La utilidad de tcpdump no está en dominarlo al detalle, sino en saber cuándo recurrir a él. Cuando los síntomas apuntan a red, cuando las herramientas de más alto nivel no dan respuestas, cuando dos partes discrepan sobre qué está pasando. En esos momentos, capturar tráfico suele ser más rápido que seguir especulando.

Conviene tener preparados algunos filtros habituales documentados en algún sitio accesible. Un simple fichero de texto o nota con los comandos más usados ahorra tiempo cuando hay presión. En el blog hemos hablado de gestión del conocimiento técnico precisamente para esto. También ayuda practicar en entornos sin estrés —un laboratorio con Vagrant o Docker es perfecto para ello—, para que cuando llegue el momento de usarlo en producción, los comandos salgan sin pensar.

Y es importante recordar que tcpdump no soluciona problemas por sí solo: proporciona datos. Interpretar esos datos requiere entender protocolos, conocer cómo funcionan las aplicaciones, tener contexto sobre la arquitectura del sistema. La herramienta es simple. El trabajo de análisis no lo es.

En un mundo donde cada vez más infraestructura es efímera, donde los contenedores aparecen y desaparecen, donde el tráfico se cifra por defecto y las redes se virtualizan, tcpdump sigue siendo esa herramienta que permite ver lo que realmente está pasando. No es elegante ni moderna, pero cuando todo lo demás falla, sigue funcionando. Y eso, en sistemas en producción, vale más que cualquier interfaz gráfica.

Herramientas relacionadas en el blog

• Mini-guía para usar Wireshark en Windows y Linux — el siguiente paso natural después de capturar
• Dominando DIG: Descubre los Secretos del DNS — cuando el problema es de resolución DNS

Para seguir aprendiendo

«TCP/IP Illustrated, Volume 1: The Protocols» de W. Richard Stevens y Kevin Fall (Addison-Wesley, 2ª edición 2011). La referencia clásica para entender cómo funcionan los protocolos que tcpdump captura, con ejemplos reales de tráfico y explicaciones detalladas. La segunda edición, actualizada por Kevin Fall, recoge IPv6 y cambios en TCP modernos.

«Practical Packet Analysis» de Chris Sanders (No Starch Press, 3ª edición). Guía práctica centrada en el análisis de capturas de red, con casos de uso comunes y técnicas de diagnóstico aplicables al trabajo diario. Muy alineada con el enfoque de este artículo.

Documentación oficial de tcpdump — tcpdump.org. Referencia completa de opciones, filtros y ejemplos de uso.

man pcap-filter — la referencia directa de los filtros BPF que usa tcpdump. Antes de buscar en Google cómo escribir un filtro complejo, vale la pena leerla: cubre combinaciones lógicas, filtros por flags TCP, offsets de bytes y mucho más.

Wireshark User’s Guide — documentación oficial del proyecto Wireshark. Aunque se centra en Wireshark, explica conceptos de análisis de protocolos aplicables también al trabajo con tcpdump y tshark.

«The Practice of Network Security Monitoring» de Richard Bejtlich (No Starch Press). Contexto sobre cómo el análisis de tráfico encaja en la monitorización de seguridad y operaciones, con perspectiva de entornos empresariales.