LinuxParty

Aprende a capturar, filtrar e interpretar el tráfico de red para diagnosticar problemas de navegación, conexiones lentas, fallos de DNS y errores en el correo electrónico

Wireshark es una de las herramientas más completas para analizar redes. Permite capturar los paquetes que entran y salen de un equipo, identificar los protocolos utilizados y descubrir por qué una conexión falla, responde lentamente o se interrumpe.

En esta guía veremos cómo instalar y utilizar Wireshark en Linux para examinar cuatro de los grupos de protocolos más habituales: HTTP/HTTPS, TCP/IP, DNS y SMTP.

Instalar Wireshark en Linux

En Debian, Ubuntu y distribuciones derivadas:

sudo apt update
sudo apt install wireshark

En Fedora:

sudo dnf install wireshark wireshark-cli

En Arch Linux y derivadas:

sudo pacman -S wireshark-qt

Durante la instalación puede preguntarse si los usuarios sin privilegios pueden capturar paquetes. Si respondemos afirmativamente, debemos añadir nuestra cuenta al grupo de Wireshark:

sudo usermod -aG wireshark "$USER"

Después tendremos que cerrar la sesión y volver a entrar para que se aplique el cambio.

No es recomendable ejecutar toda la interfaz gráfica como root. Wireshark emplea el componente dumpcap para realizar las capturas con los permisos necesarios.

Cómo comenzar una captura

Al abrir Wireshark aparecerá una lista de interfaces de red. Debemos seleccionar la que esté utilizando el equipo:

• enp3s0, eth0 o similar para Ethernet.
• wlan0, wlp2s0 o parecido para una conexión Wi-Fi.
• lo para comunicaciones internas del propio equipo.
• any para escuchar simultáneamente en todas las interfaces, cuando esté disponible.

Hacemos doble clic sobre la interfaz y Wireshark comenzará a recopilar paquetes. Después podemos generar el tráfico que queremos estudiar y detener la captura mediante el botón rojo.

Solo debemos capturar tráfico en equipos y redes propios o para los que tengamos autorización.

Filtros de captura y filtros de visualización

Wireshark dispone de dos clases de filtros que no deben confundirse.

Un filtro de captura decide qué paquetes se guardarán desde el principio. Por ejemplo:

port 53

Este filtro únicamente captura tráfico que utilice el puerto 53.

Un filtro de visualización se aplica después o durante la captura y oculta temporalmente aquello que no nos interesa:

dns

Los paquetes ocultos continúan dentro del archivo. Podemos borrar el filtro y volver a verlos cuando queramos.

Para empezar resulta más seguro capturar todo el tráfico durante unos segundos y aplicar después filtros de visualización.

1. Analizar HTTP y HTTPS

HTTP se utiliza para transferir páginas y otros recursos web. HTTPS protege esa comunicación mediante TLS.

Para generar una petición HTTP de prueba podemos ejecutar:

curl -v http://example.com/

En Wireshark aplicamos el filtro:

http

También podemos mostrar únicamente las peticiones:

http.request

O solamente las respuestas:

http.response

Una petición podría aparecer así:

GET / HTTP/1.1
Host: example.com
User-Agent: curl/8.x

La respuesta puede contener:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

Cómo interpretar el resultado

Los códigos HTTP más habituales son:

• 200 OK: la petición se procesó correctamente.
• 301 o 302: el servidor redirige al navegador hacia otra dirección.
• 403 Forbidden: el servidor entiende la petición, pero rechaza el acceso.
• 404 Not Found: el recurso solicitado no existe en esa ruta.
• 500 Internal Server Error: se produjo un error en el servidor.
• 502 Bad Gateway: un proxy no obtuvo una respuesta válida del servidor posterior.
• 503 Service Unavailable: el servicio no está disponible temporalmente.

Wireshark incluye el campo http.time, que permite estudiar el tiempo transcurrido entre una petición y su respuesta.

Para aislar una conversación, seleccionamos un paquete y usamos:

Analizar → Seguir → Flujo HTTP

También podemos seleccionar:

Analizar → Seguir → Flujo TCP

Wireshark reconstruirá la conversación en el orden en que fue transmitida.

Qué ocurre con HTTPS

Para examinar conexiones HTTPS empleamos:

tls

O podemos combinar TLS con el puerto tradicional de HTTPS:

tcp.port == 443

Normalmente veremos el establecimiento de la conexión, las direcciones IP, los certificados, la versión TLS, el volumen de datos y posibles alertas, pero no el contenido de la página, las contraseñas ni los formularios. Esa información está cifrada.

Un ejemplo simplificado sería:

Client Hello
Server Hello
Application Data
Application Data

Client Hello y Server Hello muestran la negociación de la conexión segura. Los paquetes Application Data contienen información cifrada.

La ausencia de HTTP legible en una conexión HTTPS no representa un error: significa que el cifrado está funcionando. Algunas conexiones modernas utilizan HTTP/2 o HTTP/3, QUIC y mecanismos como ECH, por lo que determinados nombres y campos tampoco estarán siempre visibles.

2. Analizar TCP/IP

IP se encarga de dirigir los paquetes entre sus orígenes y destinos, mientras que TCP proporciona una comunicación fiable y ordenada entre aplicaciones.

Para visualizar tráfico IPv4:

ip

Para IPv6:

ipv6

Para mostrar los paquetes relacionados con una dirección concreta:

ip.addr == 192.168.1.50

Para filtrar TCP:

tcp

Y para examinar un puerto determinado:

tcp.port == 443

El establecimiento de una conexión TCP

Una conexión TCP normal comienza con tres paquetes:

Cliente → Servidor: SYN
Servidor → Cliente: SYN, ACK
Cliente → Servidor: ACK

Este proceso recibe el nombre de negociación de tres pasos o three-way handshake.

Si observamos varios paquetes SYN sin ninguna respuesta, las causas posibles son:

• El servidor está apagado o no responde.
• El puerto está cerrado.
• Un cortafuegos descarta los paquetes.
• Existe un problema de enrutamiento.
• La dirección IP utilizada no es correcta.

Si el servidor responde inmediatamente con RST, ACK, normalmente el equipo es accesible, pero no existe un servicio escuchando en ese puerto o la conexión ha sido rechazada.

Retransmisiones y pérdidas

Para localizar posibles retransmisiones podemos utilizar:

tcp.analysis.retransmission

También resulta útil:

tcp.analysis.fast_retransmission

Una retransmisión aislada no siempre indica un problema grave. Muchas retransmisiones consecutivas, acompañadas de pausas y reducción del rendimiento, pueden señalar pérdida de paquetes, saturación, mala cobertura Wi-Fi o un enlace defectuoso.

El filtro siguiente muestra diferentes avisos generados por el analizador TCP:

tcp.analysis.flags

Entre ellos podemos encontrar:

• TCP Retransmission: se envía nuevamente un segmento.
• Dup ACK: el receptor repite una confirmación porque falta información anterior.
• Out-of-Order: los segmentos llegaron en un orden diferente.
• ZeroWindow: el receptor no puede aceptar temporalmente más datos.
• Previous segment not captured: falta un segmento anterior en la captura.

Algunas advertencias pueden deberse al propio punto desde el que realizamos la captura y no necesariamente a un fallo real de la red.

3. Analizar consultas DNS

DNS convierte nombres como linuxparty.es en direcciones IP.

Podemos generar una consulta desde el terminal:

dig linuxparty.es

Después aplicamos en Wireshark:

dns

Para mostrar únicamente las consultas:

dns.flags.response == 0

Para visualizar solo las respuestas:

dns.flags.response == 1

También podemos buscar un dominio concreto:

dns.qry.name == "linuxparty.es"

Una captura normal podría mostrar:

Standard query A linuxparty.es
Standard query response A linuxparty.es 192.0.2.20

El registro A solicita una dirección IPv4. Un registro AAAA busca una dirección IPv6, mientras que MX consulta los servidores encargados de recibir el correo de un dominio.

Interpretar errores DNS

Entre las respuestas más importantes encontramos:

• NOERROR: el servidor procesó correctamente la consulta.
• NXDOMAIN: el nombre consultado no existe.
• SERVFAIL: el servidor DNS no pudo completar la resolución.
• REFUSED: el servidor rechazó realizar la consulta.

Si observamos una consulta repetida varias veces sin respuesta, puede existir un problema con el servidor DNS, un cortafuegos o la conectividad.

Si la respuesta llega, pero tarda demasiado, podemos comparar el tiempo entre la consulta y la contestación. Wireshark también dispone del campo:

dns.time

Por ejemplo:

dns.time > 1

muestra respuestas DNS que han tardado más de un segundo.

Hay que tener en cuenta que los navegadores y sistemas modernos pueden utilizar DNS sobre HTTPS o DNS sobre TLS. En esos casos no veremos paquetes identificados directamente como dns, porque las consultas estarán cifradas dentro de conexiones HTTPS o TLS.

4. Analizar el correo SMTP

SMTP se utiliza para enviar correo electrónico desde un cliente a un servidor o entre servidores de correo.

El filtro básico es:

smtp

También podemos examinar los puertos empleados habitualmente:

tcp.port == 25 || tcp.port == 587 || tcp.port == 465

El puerto 25 suele utilizarse entre servidores; el 587 se emplea normalmente para el envío autenticado y el 465 para SMTP sobre TLS implícito.

Una conversación SMTP sin cifrar podría contener:

220 mail.example.net ESMTP
EHLO equipo.local
250-mail.example.net
MAIL FROM:<Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.>
RCPT TO:<Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.>
DATA
250 Message accepted
QUIT

Interpretar las respuestas SMTP

Los códigos más frecuentes son:

• 220: el servidor está preparado.
• 250: la orden se procesó correctamente.
• 354: el servidor espera el contenido del mensaje.
• 421: servicio temporalmente no disponible.
• 450 o 451: fallo temporal; el mensaje puede reintentarse.
• 535: error de autenticación.
• 550: destinatario rechazado, buzón inexistente o envío no permitido.
• 552: mensaje demasiado grande o cuota superada.
• 554: transacción rechazada, frecuentemente por políticas antispam.

Un código 4xx suele representar un error temporal. El servidor remitente puede intentar entregar nuevamente el mensaje. Un código 5xx señala normalmente un rechazo permanente que exige corregir la dirección, la autenticación o la configuración.

Para reconstruir una sesión SMTP podemos seleccionar uno de sus paquetes y abrir:

Analizar → Seguir → Flujo TCP

Si se utiliza STARTTLS, al principio podremos ver comandos como EHLO y STARTTLS, pero el resto de la conversación aparecerá cifrado. Con SMTPS en el puerto 465, prácticamente toda la sesión estará protegida desde el comienzo.

No conviene realizar pruebas con credenciales reales sobre una conexión SMTP sin cifrar, ya que Wireshark podría mostrarlas en texto legible.

Filtros rápidos para guardar

Estos filtros cubren buena parte de un diagnóstico inicial:

http
tls
tcp
tcp.analysis.flags
dns
smtp
ip.addr == 192.168.1.50
tcp.port == 443
dns.qry.name == "linuxparty.es"
http.response.code >= 400

Podemos guardarlos desde el marcador situado junto a la barra de filtros o desde:

Analizar → Filtros de visualización

Herramientas estadísticas de Wireshark

Además de revisar los paquetes individualmente, Wireshark incorpora varias vistas útiles:

• Estadísticas → Jerarquía de protocolos: muestra qué protocolos aparecen y cuánto tráfico representa cada uno.
• Estadísticas → Conversaciones: agrupa las comunicaciones entre dos extremos.
• Estadísticas → Puntos finales: enumera direcciones IP, puertos y dispositivos.
• Estadísticas → Gráficos de E/S: permite representar la actividad a lo largo del tiempo.
• Analizar → Información experta: reúne retransmisiones, errores, advertencias y otros sucesos relevantes.

La información experta ayuda a encontrar anomalías, pero no constituye por sí sola un diagnóstico. Cada aviso debe interpretarse teniendo en cuenta el contexto y el lugar desde el que se realizó la captura.

Un ejemplo completo de diagnóstico

Supongamos que una página web no carga. Podemos seguir este orden:

1. Aplicar dns y comprobar si el dominio obtiene una dirección IP.
2. Aplicar tcp y localizar la negociación SYN, SYN-ACK, ACK.
3. Aplicar tls para comprobar si comienza correctamente la sesión segura.
4. Buscar alertas TLS o cierres de conexión.
5. Si la conexión no está cifrada, aplicar http y revisar el código de respuesta.
6. Buscar retransmisiones con tcp.analysis.retransmission.
7. Consultar Estadísticas → Conversaciones para verificar qué equipos intercambiaron datos.

Si DNS devuelve NXDOMAIN, el problema se produce antes de contactar con el servidor web. Si DNS funciona, pero solamente vemos paquetes SYN sin respuesta, el fallo puede encontrarse en la conectividad, el puerto o el cortafuegos. Si TCP y TLS se establecen correctamente, pero recibimos un error HTTP 500, debemos revisar la aplicación o el servidor web.

Conclusión

Wireshark no se limita a mostrar miles de paquetes incomprensibles. Utilizando filtros adecuados podemos reconstruir el camino seguido por una comunicación y localizar en qué capa aparece el problema.

DNS nos indica si el nombre se resuelve; IP muestra hacia dónde viajan los paquetes; TCP permite comprobar si la conexión se establece y transmite de forma fiable; TLS protege el contenido; HTTP revela la respuesta del servidor web, y SMTP ayuda a diagnosticar el envío del correo.

La clave no consiste únicamente en capturar tráfico, sino en formular una pregunta concreta, aplicar el filtro correspondiente y relacionar cada respuesta con la fase anterior de la comunicación.

Fuentes

• Guía oficial de Wireshark
• Filtros de visualización de Wireshark
• Cómo seguir un flujo de protocolos
• Referencia oficial de filtros HTTP
• Referencia oficial de filtros DNS
• Referencia oficial de filtros SMTP
• Referencia oficial de filtros TLS