tcpdump y tshark: captura y análisis de tráfico de red en Linux

Hay un momento en todo troubleshooting de red en que ping y curl dejan de responder. El puerto está abierto, el servicio responde, pero algo entre tu servidor y el cliente se está comiendo paquetes, reescribiendo cabeceras o reintentando sin que tú lo veas. En ese punto la pregunta ya no es «¿está caído?», sino «¿qué paquetes están pasando realmente por el cable?».

Para eso existen dos herramientas que todo sysadmin debería tener instaladas y que, sin embargo, se usan mucho más de lo que se les enseña: tcpdump captura el tráfico en la línea de comandos y tshark lo descompone campo por campo. Son las dos caras de la misma moneda, pero hablan dos idiomas distintos, y ese es exactamente el punto donde se traba casi todo el mundo.

En este artículo vamos a capturar tráfico real en loopback, leerlo con tshark, exportar campos a una tabla que se pueda ordenar y contar, y entender por qué el mismo filtro escrito de una forma funciona y de la otra no. Todo con las salidas reales de los comandos, porque las dos herramientas fallan de maneras distintas y una de esas maneras es silenciosa.

Instalar las dos herramientas y saber qué versión tienes

Antes de nada, una distinción que evita horas de frustración: las versiones que publica el proyecto no son las que te instala tu distribución, y eso importa porque los valores por defecto y la sintaxis cambian entre ramas.

El proyecto tcpdump publica la estable 4.99.7, del 21 de septiembre de 2026, y esa versión exige libpcap 1.10.5 o posterior para pasar todas sus pruebas. La libpcap estable es la 1.10.7, del 5 de septiembre de 2026, y la que está en pruebas es la 1.11.0, del 13 del mismo mes. Del lado de Wireshark, la estable es la 4.6.9, la estable anterior la 4.4.19 y la de desarrollo la 5.0.0rc2; las dos estables se publicaron el 23 de septiembre de 2026, y el anuncio atribuye el volumen de correcciones de seguridad a la tendencia reciente de reportes de vulnerabilidad asistidos por inteligencia artificial.

Ahora lo que te da tu sistema. En un Debian 13 recién instalado, el paquete tcpdump es la 4.99.5-2 y el paquete tshark es la 4.4.19-0+deb13u1, que además viene marcado como paquete de seguridad en el archivo de Debian. Si instalas tshark en Debian 13 y esperas la 4.6.9 del proyecto, no la vas a obtener: vas a tener la 4.4.19 de tu distribución. No es un error de instalación, es la política de la distro.

# Instalar las dos herramientas en Debian o Ubuntu
sudo apt install tcpdump tshark
# Ver las versiones que realmente tienes
tcpdump --version
tshark --version

En un Debian 13 real la salida es esta:

tcpdump version 4.99.5
libpcap version 1.10.5 (with TPACKET_V3)
TShark (Wireshark) 4.4.19.

Un detalle de esa salida que vale la pena mirar: la versión de libpcap que aparece no es la que te da el kernel, es la con la que se compiló el binario. Si ves una versión antigua ahí y tu kernel es nuevo, es una pista sobre por qué se te comporta raro.

Capturar el tráfico propio: la pseudo-interfaz any y su trampa

Lo primero que hay que resolver es dónde te pones. El manual de Wireshark es explícito en el orden de los pasos: primero se confirma que tienes autorización, después se configura la máquina, y solo en el paso 3 se empieza a capturar el tráfico propio. El orden importa porque cada paso depende del anterior.

Para tu propio tráfico, la pseudo-interfaz any es la respuesta rápida. En Linux captura desde todas las interfaces regulares del sistema. Pero tiene tres trampas que se ven en la salida real:

# Capturar desde todas las interfaces
sudo tcpdump -i any -c 3 -n

tcpdump: WARNING: any: That device doesn't support promiscuous mode
(Promiscuous mode not supported on the "any" device)
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
00:16:25.867991 enp0s31f6 In  IP 184.150.49.56.443 > 192.168.5.180.35210: Flags [P.], seq 2449835776:2449835900, ack 3835726843, win 9256, length 124

La primera es el aviso de que any no captura en modo promiscuo: solo ves el tráfico que la máquina realmente envía y recibe, no el de la red entera. La segunda es el tipo de enlace: LINUX_SLL2 (Linux cooked v2). Eso no es un detalle cosmético. Una captura hecha en any no lleva cabecera Ethernet, lleva cabecera SLL2, y las columnas de tshark quedan desplazadas respecto a lo que esperarías de una captura en una interfaz física. La tercera es la que más confunde: any en Linux no captura el tráfico de loopback. Lo comprobé generando tráfico TCP local y capturando con any: la cuenta salió en 0 packets captured con el filtro puesto sobre ese puerto. Si lo que quieres ver es lo que la máquina se habla a sí misma, tienes que capturar en lo explícitamente.

# Capturar el trafico de loopback, que 'any' no ve
sudo tcpdump -i lo -c 5 -n 'tcp port 443'
# Guardarlo directamente a disco en formato pcapng
sudo tcpdump -i lo -w /tmp/local.pcapng 'tcp port 443'

Y si no pasas -i, tcpdump elige la interfaz activa con el número más bajo, excluyendo loopback. En una máquina con varias interfaces eso puede ser la equivocada, y el síntoma es una captura vacía sin ningún error visible.

Filtrar en la captura: la sintaxis de libpcap

El filtro que se le pasa a tcpdump se escribe en la sintaxis de libpcap, la misma que usa tcpdump y libpcap desde hace décadas. Es una gramática de cuatro piezas: protocolo, dirección, tipo de entidad y combinación lógica.

Elemento	Ejemplo	Qué significa
Protocolo	tcp, udp, icmp, arp	El tipo de protocolo de capa superior
Dirección	src, dst, src or dst	De dónde o hacia dónde va el paquete
Tipo	host, net, port, portrange	La entidad contra la que se compara
Comparación	and, or, not	Combinación lógica entre condiciones

Los tres filtros que uso el 90% de las veces son tcp port 443

Los tres filtros que uso el 90% de las veces

, udp port 53 y host 10.0.0.5. Con portrange cubres rangos: portrange 8000-8100.

# Solo HTTPS de cualquier parte
sudo tcpdump -i any -n 'tcp port 443'
# DNS, con la direccion de origen
sudo tcpdump -i any -n 'udp port 53 and host 192.168.5.1'
# Un rango de puertos de un servidor
sudo tcpdump -i any -n 'tcp portrange 8000-8100 and host 10.0.0.5'

Y el filtro más útil cuando no sabes por dónde empezar: captura sin filtro y con corte por cantidad de paquetes. El flag -c corta la captura después de recibir ese número de paquetes, y es el seguro contra llenar el disco de una VPS.

# 200 paquetes como maximo, despues sale solo
sudo tcpdump -i any -c 200 -s 0 -w /tmp/diag.pcapng

Un detalle sobre -s 0 que se malinterpreta mucho: no significa «captura completa sin límite». Poner el valor en cero es lo mismo que dejar el valor por defecto, y el valor por defecto de tcpdump 4.99.7 es de 262144 bytes de captura por paquete, no 65535. El manual lo dice así, textualmente: «Snarf snaplen bytes of data from each packet rather than the default of 262144 bytes». Si necesitas el paquete completo, el valor a usar es un número mayor que el MTU real de tus tramas.

Leer la captura con tshark y exportar campos

Una vez que tienes el archivo, tshark lo descompone. Y aquí está la diferencia central, la que causa el 80% de los errores: tshark habla dos idiomas y no los mezcla.

Opción	Sintaxis	Cuándo se aplica
-f	libpcap, igual que tcpdump	Solo durante la captura, en vivo
-Y	Filtros de visualización de Wireshark	Al mostrar, tanto en vivo como leyendo archivo

El filtro de captura va con -f y el de visualización con -Y. Y aquí está la trampa más cara del post, porque el error es explícito pero muchos lo ignoran:

# MAL: filtro de captura pasado a -Y
tshark -r traza.pcapng -Y "tcp port 8099"

tshark: "port" was unexpected in this context.
    tcp port 8099
        ^~~~
  Note: That read filter code looks like a valid capture filter;

El propio tshark te avisa de que parece un filtro de captura válido, que es exactamente lo que es: lo escribiste en el idioma equivocado. La forma correcta es la sintaxis de campos:

# BIEN: sintaxis de visualizacion de Wireshark
tshark -r traza.pcapng -Y "tcp.dstport == 8099"

    1   0.000000    127.0.0.1 → 127.0.0.1    TCP 74 35048 → 8099 [SYN] Seq=0 Win=65495 Len=0 MSS=65495 SACK_PERM
    3   0.000030    127.0.0.1 → 127.0.0.1    TCP 66 35048 → 8099 [ACK] Seq=1 Ack=1 Win=65536 Len=0
    4   0.000293    127.0.0.1 → 127.0.0.1    HTTP 144 GET / HTTP/1.1

Ahora la parte que convierte una captura en algo accionable:

Exportar campos: de líneas sueltas a una tabla

exportar campos en vez de leer líneas. Con -T fields le pides columnas concretas y tshark te devuelve una tabla. Con -e nombras cada campo, y la propia manual avisa que hay que dar al menos uno.

tshark -r traza.pcapng -T fields -e frame.number -e ip.src -e tcp.srcport

La salida real, con el separador por defecto que es tabulador:

1	127.0.0.1	35048
2	127.0.0.1	8099
3	127.0.0.1	35048
4	127.0.0.1	35048

Los tabuladores son incómodos para trabajar en terminal. Con -E separator= cambias el separador y con -E quote=d entrecomillas los valores, que es lo que necesitas para que una coma dentro de un valor no descoloque las columnas:

tshark -r traza.pcapng -T fields -E separator=, -E quote=d -e frame.number -e ip.src -e tcp.dstport

"1","127.0.0.1","8099"
"2","127.0.0.1","35048"
"3","127.0.0.1","8099"
"4","127.0.0.1","8099"

Con eso ya tienes una tabla de verdad, y la potencia aparece cuando la encadenas con las herramientas de texto. Para responder «¿quién más me está pidiendo el mismo puerto?»:

# Los 10 origenes que mas veces contactan el puerto 443
tshark -r traza.pcapng -Y "tcp.dstport == 443" -T fields -E separator=, -E quote=d -e ip.src | sort | uniq -c | sort -rn | head -10

Y para ver los nombres de host resueltos en una captura de DNS, que es donde empieza lo interesante cuando estás investigando una fuga:

tshark -r traza.pcapng -Y "dns" -T fields -E separator=, -E quote=d -e dns.qry.name -e dns.a

Un aviso que aparece en el manual y conviene tener presente: con -w los filtros de visualización no funcionan. La razón es que tshark está copiando paquetes crudos al archivo, no decodificándolos. Si quieres guardar Y filtrar al mismo tiempo, tienes que hacerlo en dos pasos: capturas con -f, analizas con -r y -Y.

Las tres cuentas de tcpdump: el diagnóstico que casi nadie mira

Cuando una captura termina, tcpdump imprime tres números. No son decoración: son el diagnóstico más rápido que existe para separar «mi filtro está mal» de «mi máquina no da abasto».

sudo tcpdump -i lo -c 4 -w traza.pcapng 'tcp port 8099'

tcpdump: listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
4 packets captured
100 packets received by filter
0 packets dropped by kernel

• packets captured: los que realmente se guardaron en el archivo.
• packets received by filter: los que llegaron al kernel y que el filtro evaluó. La diferencia con el primero es lo que el filtro descartó.
• packets dropped by kernel: los que el kernel tiró antes de que el filtro los viera. Este es el número que duele.

Cuando el tercero es cero, tu captura es íntegra y puedes culpar a la red con propiedad. Cuando salen en miles, el problema no es el filtro: la máquina no está dando abasto. Y el manual dice por qué, al final, que el kernel se queda sin espacio en su búfer de captura.

Ahí la palanca es -B, que define el tamaño del búfer de captura del sistema en KiB, es decir 1024 bytes. Subirlo reduce las pérdidas en tráfico saturado:

# Búfer de captura de 16 MiB
sudo tcpdump -i any -B 16384 -c 500 -w /tmp/busy.pcapng

Pero antes de subir el búfer, prueba la vía más simple: recorta el tráfico. Un filtro de captura estrecho, un -c más bajo o capturar en la ventana de menos carga. Subir el búfer sin acotar el tráfico solo aplaza el problema.

Y para capturas largas en un servidor, hay rotación de archivos.

Rotar archivos sin llenar el disco

-C corta el archivo cada cierto tamaño y -G lo rota cada cierto tiempo. Ojo con la unidad de -C: es el millón de bytes, 1000000 bytes, no 1048576. Con sufijo k, m o g pasa a KiB, MiB y GiB respectivamente.

# Archivos de 100 MiB, quedandose con los 5 mas recientes
sudo tcpdump -i any -C 100m -W 5 -w /tmp/rot-%Y%m%d-%H%M.pcapng

Permisos: por qué a veces funciona con sudo y a veces no

Capturar requiere privilegios. El manual de Wireshark lo dice de la forma más clara posible en el paso 1: solo debes capturar tráfico en redes donde tengas autorización, porque la política de tu empresa o la ley aplicable pueden prohibírtelo. Si tienes que cambiar cableado para capturar, asegúrate de tener autorización también para eso: a los administradores de red no les gusta que reorganicen su cableado sin avisar.

El caso típico es este:

tshark -i lo -a duration:3 -w traza.pcapng

Capturing on 'Loopback: lo'
tshark: You do not have permission to capture on device "lo".
(socket: Operation not permitted)
Please check to make sure you have sufficient privileges.

Lo interesante es por qué.

El mecanismo real de Debian: setcap sobre dumpcap

En una instalación de Debian, el mecanismo real no es el que mucha gente asume. El script de post-instalación de wireshark-common hace esto:

chown root:$GROUP $PROGRAM
if command -v setcap > /dev/null ; then
        chmod u=rwx,g=rx,o=r $PROGRAM
        if ! setcap cap_net_raw,cap_net_admin=eip $PROGRAM; then
                chmod u=rwxs,g=rx,o=r $PROGRAM
        fi
else
        chmod u=rwxs,g=rx,o=r $PROGRAM
fi

Tres cosas que se leen ahí y que importan. La primera: el binario al que se le dan las capacidades es dumpcap, no tshark. Es tshark quien lanza a dumpcap como proceso hijo para hacer la captura. La segunda: el grupo es wireshark y las capacidades son cap_net_raw y cap_net_admin. La tercera: si setcap falla, cae a chmod u=rwxs, o sea el bit setgid.

Y hay un detalle de configuración que decide el resultado sin que se note. La instalación de Debian pregunta si quieres el mecanismo de setuid activado, y el valor que quedó guardado en la máquina donde hice las pruebas fue false: con esa opción, el postinst deja los binarios en root:root con u=rwx,go=rx, sin grupo wireshark y sin capacidades. Por eso el mensaje de arriba.

El camino correcto en Debian es el que el propio paquete propone:

# Verificar el estado actual
getcap /usr/bin/dumpcap
ls -l /usr/bin/dumpcap

Y si no está aplicado, aplicarlo. El setcap sobre el archivo es lo que da los privilegios sin dejar el binario completamente en manos de root:

sudo chown root:wireshark /usr/bin/dumpcap
sudo chmod u=rwx,g=rx,o=r /usr/bin/dumpcap
sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap
# Verificar que quedo aplicado
getcap /usr/bin/dumpcap

Y tu usuario tiene que pertenecer al grupo wireshark para poder ejecutarlo:

sudo usermod -aG wireshark $USER
id -nG $USER

Aquí hay un detalle fino que se aprende de la manera dura. Con el permiso o=r puesto y el usuario sin estar en el grupo, el error que aparece no es «no tienes permisos», sino este, que parece un fallo de permisos del todo:

tshark -i lo -a duration:3 -w traza.pcapng

Capturing on 'lo'
tshark: Couldn't run dumpcap in child process: Permission denied
0 packets captured

Y 0 packets captured con eso parece una captura vacía legítima. No lo es: es el hijo que no arrancó. Con el usuario dentro del grupo, la misma captura funciona sin sudo:

sg wireshark -c 'tshark -i lo -a duration:3 -w traza.pcapng'

Capturing on 'Loopback: lo'
242 packets captured

Un apunte sobre el otro método, el que documenta Linux From Scratch: crear el grupo con groupadd -g 62 wireshark, hacer chown root:wireshark /usr/bin/tshark y chmod 6550. Sirve y es el patrón clásico, pero en Debian el mecanismo que el propio paquete instala es el de setcap sobre dumpcap, y son dos cosas distintas. Si mezclas los dos acabas con un dumpcap al que le quitaste el bit de ejecución para los demás sin querer, que es justo el error de arriba.

Capturar sin llenar el disco: cortar por tiempo, tamaño y cantidad

Para capturas de larga duración, tshark trae un criterio de parada automática con -a, que toma la forma test:value. Los cuatro tests son duration, files, filesize y packets.

# 60 segundos de captura, un solo archivo
tshark -i any -a duration:60 -w /tmp/diag.pcapng
# Cortar cuando el archivo llega a 10 MiB
tshark -i any -a filesize:10240 -w /tmp/diag.pcapng
# Cortar tras 500 paquetes que pasan el filtro
tshark -i any -a packets:500 -w /tmp/diag.pcapng

Un matiz que importa para contar: el criterio packets de -a no cuenta los paquetes que no pasan el filtro de visualización, así que puede diferir de un -c de conteo de captura.

Y cuando necesitas reensamblar respuestas o ver el orden de una transacción completa, está el análisis en dos pasadas:

tshark -r traza.pcapng -2 -Y "tcp.stream eq 0"

La opción -2 no se puede usar en captura en vivo ni al leer desde una tubería, porque necesita poder saltar hacia atrás en la entrada. Lee siempre desde un archivo.

Para acortar el detalle de cada paquete y quedarte solo con lo relevante, -O te deja elegir qué protocolos se muestran en detalle. Las abreviaturas válidas las sacas del propio binario:

tshark -G protocols | head -3

Lua Dissection	Lua Dissection	_ws.lua	T	T	T
Expert Info	Expert	_ws.expert	T	T	F
CBOR Item Decoder	CBOR Item Decoder	_ws.wscbor	T	T	F

Y si solo quieres saber qué se capturó sin desarmar nada, capinfos

Resumen del archivo con capinfos

da el resumen del archivo: tipo, encapsulación, cantidad de paquetes, duración y tasa.

capinfos traza.pcapng

File name:           traza.pcapng
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 262144 bytes
Number of packets:   4
File size:           446 bytes
Data size:           358 bytes
Capture duration:    0.000293 seconds
Earliest packet time: 2026-11-14 00:14:37.440146
Latest packet time:   2026-11-14 00:14:37.440439

Ahí se ven tres cosas que acabas de ver confirmadas en datos reales. El límite de captura es 262144 bytes. La precisión de la marca de tiempo por defecto es el microsegundo; para el nanosegundo existen --nano y --time-stamp-precision. Y el tipo de archivo es pcapng, que es el formato nativo de tshark, aunque tcpdump también lo escribe cuando lo pides. tshark detecta el formato por su cuenta al leer, y también la compresión con gzip, Zstandard o LZ4 si las librerías se compilaron con ese soporte.

El archivo de captura es material sensible: trátalo como tal

Un archivo pcapng con tráfico HTTP en claro contiene credenciales, cookies y datos personales. Los tres errores que se repiten al manejar ese material son estos:

• Borrarlo cuando termines. No lo dejes en /tmp «por si acaso». Un /tmp sobrevive a reinicios en muchas máquinas y lo lee cualquiera que tenga acceso al sistema.
• Cifrarlo si lo vas a compartir. Un reporte de tickets con una captura adjunta viaja por correo y sistemas de tickets que registran todo.
• Revisarlo antes de adjuntarlo. Antes de mandarlo, mira qué contiene: strings sobre el archivo te muestra credenciales en claro si las hay.

# Revisar antes de compartir: buscar credenciales y cabeceras
strings traza.pcapng | grep -iE 'password|token|authorization|cookie'

Y aplica el mismo criterio al formato de salida: si vas a compartir una tabla CSV con -T fields, no tiene por qué incluir campos que no necesitas. -e dns.qry.name o -e http.host bastan; arrastrar -e http.request.uri con parámetros de autenticación en la URL no aporta nada al diagnóstico y sí expone datos.

Y el punto de partida, que el manual de Wireshark pone como paso 1 y que conviene repetir: captura solo en redes donde tengas autorización. Capturar el tráfico de una red ajena puede violar la política de tu empresa o la ley aplicable. En una red corporativa, el permiso para capturar viene del administrador, no de que técnicamente sea posible.

El flujo completo, de punta a punta

Para dejar esto en un procedimiento usable, el orden es este: primero capturas con filtro de captura, acotando con -c o con -a para no llenar el disco; luego lees el archivo con tshark -r aplicando el filtro de visualización en la sintaxis de Wireshark; después exportas los campos que te importan con -T fields; y si las tres cuentas de tcpdump muestran paquetes descartados, ajustas -B o reduces el tráfico antes de culpar a la red.

# 1. Capturar acotado y con filtro de captura
sudo tcpdump -i any -c 2000 -B 4096 -w /tmp/diag.pcapng 'tcp port 443 or tcp port 22'
# 3. Leer con filtro de visualizacion (sintaxis de Wireshark)
tshark -r /tmp/diag.pcapng -Y "tls.handshake.type == 1" | head -20
# 4. Exportar campos a CSV y contar por origen
tshark -r /tmp/diag.pcapng -Y "tls.handshake.type == 1" -T fields -E separator=, -E quote=d -e ip.src -e ip.dst -e tls.handshake.extensions_server_name | sort | uniq -c | sort -rn

Y para cerrar el círculo: editcap y mergecap vienen en el mismo paquete que tshark y sirven para recortar y para pegar capturas de varios hosts en un solo archivo. Es el flujo habitual cuando el problema aparece en varios servidores a la vez y quieres un único archivo que analizar.

# Recortar una captura a un rango de tiempo
editcap -A "2026-11-14 00:10:00" -B "2026-11-14 00:20:00" traza.pcapng recorte.pcapng
# Unir capturas de tres servidores
mergecap -w unido.pcapng srv1.pcapng srv2.pcapng srv3.pcapng

Preguntas frecuentes

Lee también

• mtr y traceroute: diagnóstico de red paso a paso en Linux
• nmap básico: audita tu red local con 10 escaneos útiles
• vnstat y nethogs: monitorear el tráfico de red en tu servidor
• Cómo configurar un firewall en Linux con nftables
• Cómo ver el ancho de banda con iftop