Howto de Wireshark: retransmisiones TCP, three-way-handshake y detección de puntos de rendimiento

Este Wireshark-Howto comienza con requisitos claros y una lista de verificación pragmática, para que pueda acotar retransmisiones TCP, problemas de three-way-handshake y puntos de rendimiento en su red de manera rápida y fiable. La palabra clave de enfoque Wireshark-Howto figura deliberadamente al principio: el objetivo son instrucciones prácticas para administradores, ingenieros de sistemas, operadores y proveedores de servicios TI. Explico términos técnicos como RTT (Round-Trip-Time: tiempo de ida y vuelta) o Zero Window (el receptor indica que actualmente no puede almacenar datos en el búfer) de forma concisa y muestro por qué un hallazgo suele ser del lado de la red o del host.

Capture-Strategie: Wo mitscheiden und warum es zählt

La validez de su análisis depende principalmente del punto de captura. Una captura en el lugar equivocado produce patrones de retransmisión engañosos o enmascara el enrutamiento asimétrico. Planifique las capturas de modo que pueda seguir la dirección del flujo de mensajes.

Capture-Orte im Vergleich

• Client‑nah: Cubre la pila del cliente, firewalls locales, clientes VPN y retransmisiones de WLAN.
• Server‑nah: Muestra si el servidor recibe SYNs, cómo responde y si límites locales (backlog, ulimits) están en efecto.
• Firewall/Load‑Balancer‑nah: Importante en escenarios con NAT, conntrack o TLS‑Inspection; a menudo solo se ve una dirección, por lo que es recomendable un capture adicional.
• SPAN vs. TAP: Los puertos SPAN son de fácil acceso, pero pueden descartar paquetes bajo alta carga; los TAP ofrecen datos más completos, pero requieren hardware y planificación.

Betriebsrisiken und Compliance

• Datenschutz: Las capturas suelen contener datos de usuario y deben minimizarse, anonimizarse o eliminarse rápidamente conforme a los requisitos de protección de datos.
• Performance: Capturar en hosts productivos puede aumentar la carga de CPU/IO. Utilice Ringbuffer o almacenamiento remoto para los archivos pcap.
• TLS: El cifrado oculta el contenido de la carga útil, no el timing, las banderas ni el estado de ventana; esos metadatos son suficientes para análisis de la mecánica TCP.

Pragmatische Capture‑Beispiele

Utilice filtros específicos y Ringbuffer para generar PCAPs confiables. Aquí dos ejemplos probados en campo para Linux y Windows.

# Linux: gezielt Host/Port mitschneiden, Ringbuffer nutzen
sudo tcpdump -i eth0 -s 0 -nn 
  'host 10.20.30.40 and tcp port 443' 
  -C 200 -W 10 -w /var/tmp/capture_%Y%m%d_%H%M%S.pcap

# Windows: pktmon verwenden, dann ins pcap-Format konvertieren
pktmon filter remove
pktmon filter add -p 443
pktmon start --etw -m real-time
# Tests durchführen, dann stoppen:
pktmon stop
pktmon format PktMon.etl -o capture.pcap

Ejecute casos de prueba antes y después de los cambios siempre con los mismos parámetros, para que las mediciones sean comparables.

Wichtige Wireshark‑Ansichten für TCP

Wireshark ofrece varias funciones especialmente útiles: Display‑Filter (para vistas dirigidas), Conversations (flujos), Follow TCP Stream (ordena el flujo) y Time‑Sequence‑Graph (visualiza secuencias, ACKs y retransmisiones). Estas vistas ayudan a reconocer patrones y a determinar la dirección del problema.

Offloading‑Effekte verstehen

Términos como TSO (TCP Segmentation Offload), GRO (Generic Receive Offload) y LRO (Large Receive Offload) significan que la tarjeta de red asume partes del trabajo TCP. Las capturas en el host pueden por ello mostrar segmentos sobredimensionados o la ausencia de segmentos pequeños. Ante hallazgos contradictorios, compruebe la captura en un TAP o desactive temporalmente el Offloading.

# Offloading (temporär) deaktivieren - Linux
sudo ethtool -K eth0 tso off gso off gro off

Analizar el Three‑Way‑Handshake

El Three‑Way‑Handshake (SYN, SYN‑ACK, ACK) confirma que se puede establecer una conexión TCP. Si este paso falla, típicamente no se produce transmisión de datos. Preste atención a las opciones TCP en SYN/SYN‑ACK: MSS (Maximum Segment Size), Window Scale (escala de ventana) y SACK (Selective Acknowledgement) ofrecen indicios sobre problemas de MTU, de ventana y de retransmisión.

Secuencia de comprobación en el handshake

1. Filtrar el flujo: 5‑Tuple (IP del cliente, IP del servidor, puerto cliente, puerto servidor, protocolo).
2. ¿Se ve el SYN del cliente? ¿Responde el servidor con un SYN‑ACK?
3. ¿Falta el ACK final? Compruebe la captura en ambos extremos para verificar el camino de retorno.

Las causas típicas de handshakes fallidos son ACLs de firewall, enrutamiento asimétrico (un dispositivo stateful descarta respuestas), SYN‑Proxy/SYN‑Cookies o límites del servidor como backlogs completos.

Clasificar correctamente las retransmisiones TCP

Las retransmisiones son la reacción de TCP ante una pérdida de paquetes sospechada. Distinciones importantes:

• Fast Retransmission: Ocurre tras ACKs duplicados y señala pérdida real de paquetes.
• RTO Retransmission: Se produce tras un timeout y afecta fuertemente al rendimiento.
• Spurious Retransmission: Parece existir, pero puede deberse a reordenamiento o a artefactos de captura.

Filtros de visualización útiles

• tcp.analysis.retransmission
• tcp.analysis.fast_retransmission
• tcp.analysis.duplicate_ack
• tcp.analysis.out_of_order
• tcp.analysis.zero_window || tcp.analysis.zero_window_probe

Consejos de interpretación: ACKs duplicados sin retransmisiones indican reordenamiento (p. ej. ECMP). Retransmisiones sin ACKs duplicados pueden deberse a lagunas en la captura o a RTO reales.

Puntos de rendimiento: causas típicas y patrones de medición

Si el handshake se completa correctamente, permanecen distintos estados de espera que limitan el rendimiento. Las causas más habituales y sus firmas son:

RTT alta y jitter

Una RTT alta (Round‑Trip‑Time) o un jitter muy variable señalan colas (buffers llenos), sobrecarga del enlace, retransmisiones en WLAN o inspección por firewall. En el Time‑Sequence‑Graph observará intervalos prolongados entre segmentos de datos y ACKs.

Zero Window: ¿problema del host o de la aplicación?

Zero Window significa que el receptor pone su receive‑window a 0 porque el búfer de la aplicación está lleno. Esto suele ser un problema de la aplicación o de I/O (procesamiento lento, garbage collection o escrituras bloqueantes). Solo si las latencias de red son tan altas que retrasan los ACKs, se trata principalmente de un problema de red.

Problemas de MTU / MSS

Problemas de Path‑MTU (p. ej. por túneles como GRE, VPN o PPPoE) provocan fragmentación o la caída de segmentos mayores si el DF‑Flag está establecido y los mensajes ICMP están bloqueados. Compruebe el MSS en el SYN y utilice pings con DF para validar.

# Probar MTU (Linux): establecer flag DF, ajustar payload
ping -M do -s 1472 10.20.30.40
# En caso de fallo: reducir iterativamente

Pruebas específicas de Firewall y NAT

Los dispositivos Firewall (stateful) y NAT/Conntrack son causas frecuentes de aparentes pérdidas de paquetes o flujos asimétricos. Aquí algunas pruebas y comandos prácticos.

Comprobar límites y timeouts de Conntrack

Conntrack (Connection Tracking) es un mecanismo en las firewalls que gestiona los flujos TCP en una tabla. Si la tabla está llena o los timeouts son demasiado cortos, las sesiones se descartan.

# Estadísticas de conntrack (Linux nftables/conntrack-tools)
sudo conntrack -S
# Comprobar número de entradas
sudo conntrack -L | wc -l

Reduzca timeouts innecesariamente agresivos para conexiones establecidas y compruebe la agotación de puertos en máquinas NAT (agotamiento de puertos de origen con un alto número de conexiones por IP).

Detectar enrutamiento asimétrico

Si las solicitudes siguen un camino y las respuestas otro (p. ej. por ECMP, cambio de ruta o Multi‑ISP), una firewall stateful descartará las respuestas porque no existe state. Dos capturas (inside/outside) eliminan rápidamente la incertidumbre.

Métricas, umbrales y monitorización

Para una resolución de problemas sostenible debe definir y vigilar métricas. Métricas importantes:

• Retransmisiones por segundo y como porcentaje de los paquetes enviados
• ACKs duplicados por flujo
• RTT medio y percentil 95
• Eventos Zero‑Window por minuto
• Carga de la tabla Conntrack

Como referencia: retransmisiones aisladas son normales; tasas sostenidas de retransmisión >1–2% del tráfico indican un problema serio. Los umbrales dependen del tipo de aplicación (las aplicaciones interactivas son sensibles a la latencia, las transferencias bulk son más tolerantes).

Procedimientos prácticos de resolución de problemas

1. Aislar el flujo: Conversations → Top Talkers → aplicar filtro 5‑tuple.
2. Comprobar el handshake: comparar SYN/SYN‑ACK/ACK en ambos extremos.
3. Cuantificar retransmisiones: usar filtros tcp.analysis.*, determinar cantidad y dirección.
4. Verificaciones de middlebox: comprobar Conntrack, NAT, logs de firewall y estado de los load balancers.
5. Comprobaciones en el host: CPU, I/O, buffers de socket, netstat/tcpstat

# Ejemplo: estadísticas de sockets TCP (Linux)
ss -tan state established sport = :443
# Contadores TCP del kernel (Rx/Tx/retransmisiones)
cat /proc/net/snmp | egrep 'Tcp|TcpExt' -n
# Comprobar errores en el switchport (ejemplo dependiente del proveedor)

Cambios, pruebas y rollback

Los cambios en firewalls, MTU o NAT son efectivos pero pueden tener efectos secundarios. Siga estas reglas:

• Limitar el alcance: aplicar cambios primero a una subred, VIP o segmento de prueba.
• Antes/Después: mismos casos de prueba, mismo punto de captura, conservar PCAPs.
• Preparar rollback: exportar la configuración antes del cambio, definir una ventana temporal y métricas para el criterio de reversión.

Errores típicos y cómo evitarlos

• Artefactos de captura: caídas del puerto SPAN, offloading o marcas de tiempo pueden falsear la interpretación. Si es posible, usar un TAP o desactivar el offloading.
• Datos incompletos: capturar solo un lado a menudo conduce a asignaciones erróneas. Dos lados son la regla.
• Filtros incorrectos: filtros demasiado amplios saturan, demasiado estrechos ocultan patrones. Empiece amplio y luego acote.
• Protección de datos: Conservar las grabaciones solo el tiempo estrictamente necesario; anonimizar el flujo de datos sensibles.

Conclusión

Este Wireshark-Howto proporciona un modo de trabajo estructurado: comience por el punto de captura adecuado, verifique el Three‑Way‑Handshake como validación básica, cuantifique los Retransmits y clasifíquelos según sus firmas (Fast Retransmit vs. RTO). Zero Window suele indicar problemas en el host o en la aplicación, mientras que los Duplicate ACKs y los Fast Retransmits apuntan a errores de red o de enlace. Especialmente en problemas con firewall y NAT, las capturas sincronizadas en ambos extremos y las comprobaciones de Conntrack son decisivas. Planifique los cambios con rollback y mida antes/después: eso reduce riesgos operativos y acelera la resolución.

Utilice esta guía como base para los Runbooks de su equipo: rutas de verificación claramente definidas, pruebas reproducibles y una estrecha coordinación entre los equipos de red, firewall y sistemas aceleran la localización de fallos y aumentan la fiabilidad de su entorno de producción.

Wireshark-Howto: Automatización de capturas, sincronización horaria e integración con SIEM

Como complemento al howto práctico, conviene integrar el trabajo de captura en los procesos operativos existentes. Este capítulo describe aspectos de arquitectura y operación que son determinantes en incidentes prolongados, en requisitos de cumplimiento normativo o en comprobaciones de rendimiento recurrentes. La palabra clave de enfoque Wireshark-Howto ayuda a ubicar la guía en su documentación.

Arquitectura: puntos de captura centralizados frente a temporales

• Collectors permanentes: Una interfaz de agregación dedicada (TAP o Mirror + host de captura dedicado) almacena PCAPs durante varios días o semanas, permite análisis a largo plazo y indexación automática. Ventaja: base de comparación consistente. Inconveniente: almacenamiento, protección de datos y control de accesos.
• Capturas efímeras: capturas de corta duración durante incidentes; son flexibles, pero menos adecuadas para análisis de tendencias. Combine ambas: extracción permanente de metadatos y PCAPs completos a corto plazo ante una alerta.

Sincronización horaria y correlación

Las marcas temporales son la columna vertebral de los análisis distribuidos. Si los hosts y los collectors de red no están sincronizados, no es posible correlacionar de forma fiable ACKs, Retransmits y logs de firewall. Verifique la fuente de tiempo en todos los dispositivos implicados:

# NTP/chrony prüfen (Linux)
timedatectl status
# oder für chrony
chronyc tracking

Para análisis de latencias muy finas puede ser necesario PTP; para errores TCP típicos basta con una sincronización NTP consistente.

Extracción automática de métricas

Los PCAPs completos son grandes. Extraiga de forma automatizada indicadores (Retransmits, Duplicate ACKs, percentiles de RTT) con tshark e indexe los resultados en su SIEM o en una base de datos de series temporales. Ejemplo: contar Retransmits por flujo en un PCAP.

tshark -r capture.pcap -Y "tcp.analysis.retransmission" 
  -T fields -e ip.src -e tcp.srcport -e ip.dst -e tcp.dstport 
  | sort | uniq -c | sort -rn

La salida puede enviarse mediante un log‑forwarder a Elasticsearch/Prometheus y vincularse a reglas de alertas (p. ej. Retransmit‑Rate > X% durante 5 minutos).

Entornos containerizados y espacios de nombres

En entornos con contenedores, las interfaces suelen ser efímeras (veths, bridge). Las capturas en el host no siempre ven la pila interna en los namespaces. Utilice agentes de captura específicos por namespace o funciones de CNI que espejen puertos para obtener flujos completos.

Retención segura, redacción y cumplimiento

• Establezca plazos de retención claros y trabajos automatizados de eliminación para minimizar los riesgos de DSGVO/P11D.
• Reduzca el volumen de captura mediante filtros (IP/puerto) o modo solo encabezado de paquete cuando la carga útil no sea necesaria.
• Asegure los archivos PCAP cifrados y registre los accesos.

Operacionalización / Pasos del runbook

1. Alarma definida → desencadenar snapshot automático (PCAP completo).
2. Extraer metadatos (tshark/Zeek) y actualizar el panel de control.
3. Análisis inicial: correlación tiempo/flujo, tasa de retransmisiones, eventos Zero‑Window.
4. Realizar el cambio con alcance, métricas y plan de rollback (como ya se describió).

Estas extensiones operativas hacen su guía de Wireshark reproducible y escalable: extracción automatizada, base temporal precisa y retención conforme a la ley reducen el esfuerzo operativo y aceleran la resolución de incidencias en el equipo entre responsables de red, firewall y sistemas.

Para este tema también son importantes las retransmisiones TCP y el análisis del handshake TCP. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en el día a día.