Las utilidades de la lección anterior trabajan sobre resúmenes: ping te da tiempos, curl te da fases, traceroute te da saltos. Pero a veces el resumen no basta. ¿Por qué esa conexión tarda 3 segundos en establecerse? ¿Qué está pidiendo exactamente ese equipo al DNS? ¿Se están perdiendo paquetes dentro de la VPN con Bilbao? Para responder hay que dejar de inferir y ver los paquetes de verdad, uno a uno, con sus cabeceras de cada capa. Eso es la captura de tráfico, y sus dos herramientas canónicas son Wireshark (gráfica) y tcpdump (terminal). Esta lección es, además, la gran recompensa del curso: todo lo que has estudiado en abstracto — la encapsulación del módulo 2, las capas del 3 y el 4, el three-way handshake — vas a verlo por fin en paquetes reales de la red de Meridiano.

⚠️ Advertencia legal y ética — léela antes de capturar nada

Capturar tráfico es leer las comunicaciones que pasan por una red. Interceptar comunicaciones de terceros sin autorización es un delito (en España, tipificado en el Código Penal, y contrario al RGPD cuando hay datos personales; existen equivalentes en prácticamente todos los países). Las reglas de este curso, y de tu vida profesional, son:

• Captura solo en redes propias o con autorización explícita de su responsable. "Es la Wi-Fi de la cafetería y estaba abierta" no es autorización.
• En una empresa, la autorización no basta con ser informal: hazlo conforme a las políticas internas (autorización del responsable de sistemas/seguridad, registro de la actuación, propósito definido).
• Las capturas contienen datos personales y credenciales: guárdalas cifradas, el tiempo imprescindible, compártelas solo con quien deba verlas y bórralas al cerrar la incidencia. Un fichero .pcap olvidado en un escritorio compartido es una fuga de datos.
• Todo lo que hagamos aquí es diagnóstico de la propia red de Meridiano, con autorización: ese es el único contexto legítimo que este curso enseña.

1. Cuándo capturar: los límites de las utilidades básicas
2. Wireshark: instalación y anatomía de la interfaz
3. El panel de detalle ES la encapsulación
4. Filtros de captura vs filtros de visualización
5. Seguir una conversación TCP: el handshake, visto de verdad
6. tcpdump: capturar en un servidor sin interfaz gráfica
7. Análisis guiado (a): DNS + GET a la intranet, paquete a paquete
8. Análisis guiado (b): la videollamada lenta Valencia–Bilbao

Señales de que toca abrir el capturador:

• El síntoma es de contenido, no de conectividad: la conexión se establece, pero la aplicación se comporta raro (respuestas truncadas, cabeceras inesperadas, redirecciones extrañas).
• El síntoma es temporal: "tarda mucho en empezar", "se congela a ratos". Los tiempos entre paquetes solo se ven capturando.
• Dos herramientas se contradicen: ping va bien pero la aplicación va fatal → probablemente pérdida selectiva o retransmisiones que el resumen no muestra.
• Necesitas pruebas: para escalar al proveedor de la VPN o al ISP, "va lento" no vale; una captura con retransmisiones cronometradas, sí.

Regla de oro: la captura es el último escalón, no el primero. Es la herramienta más potente y la más cara en tiempo de análisis; llega a ella con una hipótesis formada por las utilidades de 06-01.

Wireshark es libre y gratuito (wireshark.org), disponible para Windows, Linux y macOS. Dos apuntes de instalación que conviene entender conceptualmente:

• Capturar exige acceso privilegiado a la tarjeta de red, que se pone en modo de escucha. En Windows lo proporciona el driver Npcap (se instala con Wireshark); en Linux, o ejecutas con permisos o (mejor) añades tu usuario al grupo wireshark.
• En un switch moderno solo verás tu propio tráfico y el broadcast (el switch conmuta por MAC, módulo 2, y no te reenvía conversaciones ajenas). Para ver el tráfico de otro equipo — siempre con autorización — se configura un puerto espejo (port mirroring/SPAN) en el switch, o se captura directamente en el servidor implicado, que es lo que haremos con tcpdump.

Al abrir Wireshark eliges una interfaz (la Ethernet o la Wi-Fi), pulsas el botón de captura y la ventana se organiza en tres paneles apilados:

Consejo de lectura de la lista: la columna de tiempo por defecto es relativa al inicio de la captura; los saltos grandes entre filas consecutivas de una misma conversación son tu primer indicador de "aquí se atascó".

Detente en esto, porque es el momento en que el curso "cierra el círculo". Selecciona cualquier paquete y el panel de detalle muestra algo como:

Cada línea desplegable es una capa de encapsulación, exactamente el "muñeco ruso" que estudiaste en el módulo 2 y formalizaste con OSI (módulo 3) y TCP/IP (módulo 4):

• Frame → la capa física/enlace vista por el capturador (capa 1: cuántos bytes pasaron por el cable).
• Ethernet II → capa 2: las MAC de Marta y del servidor de la intranet, la trama del módulo 2.
• Internet Protocol → capa 3: IPs, TTL, fragmentación. Despliégala y verás el campo TTL que llevas usando desde el módulo 2.
• TCP → capa 4: puertos, números de secuencia, flags (SYN, ACK, FIN, RST...), ventana.
• TLS / HTTP / DNS... → capa de aplicación.

Wireshark no "dibuja" las capas por didáctica: decodifica el paquete real en ese orden porque así está construido. Cuando en el módulo 2 dijimos que HTTP viaja dentro de TCP, dentro de IP, dentro de Ethernet, describíamos literalmente estos cuatro desplegables. A partir de ahora, cuando dudes de qué capa hace qué, abre una captura: la respuesta está delante.

Una interfaz de oficina genera cientos de paquetes por segundo; sin filtrar, te ahogas. Wireshark tiene dos sistemas de filtrado que los principiantes confunden constantemente:

Estrategia recomendada para empezar: captura ancho (a lo sumo un filtro de captura suave, como host de la máquina investigada) y filtra en visualización, que es reversible. Un filtro de captura demasiado agresivo puede descartar justo el paquete que explicaba el problema (por ejemplo, filtras port 443 y te pierdes la consulta DNS fallida que era la causa real).

Filtros de visualización esenciales, con la red de Meridiano:

Se combinan con && (y), || (o), ! (no). Si la barra del filtro se pone verde, la sintaxis es válida; roja, no lo es (el clásico: escribir port 443 — sintaxis de captura — donde va la de visualización).

En el módulo 2 estudiaste el three-way handshake con un diagrama. Ahora, Marta abre la intranet y capturamos en su PC con el filtro ip.addr == 192.168.10.10 && tcp:

Línea a línea:

• Paquete 12 — SYN: Marta (puerto efímero 52814, módulo 2) llama al 443 del servidor. Fíjate en el MSS=1460 anunciado: es el MSS que calculamos con la MTU en el módulo 4 (1500 − 40).
• Paquete 13 — SYN, ACK: el servidor acepta. Si en lugar de esto vieras un RST, sería el "connection refused" de 06-01: puerto cerrado. Si no viera nada (SYN retransmitido varias veces), sería el timeout: host caído o firewall que descarta.
• Paquete 14 — ACK: conexión establecida. Tres paquetes, tal como prometía el diagrama del módulo 2 — pero ahora con tiempos: 0,6 ms de ida y vuelta, coherente con una LAN.
• Paquetes 15–16: sobre la conexión ya abierta arranca TLS. En el Client Hello viaja en claro el SNI (el nombre del servidor): es de las pocas cosas legibles de una conexión cifrada.

Dos gestos de Wireshark que debes conocer:

• Clic derecho → Follow → TCP Stream: aísla esa conversación completa y, si es tráfico sin cifrar, muestra el diálogo legible (verás un HTTP entero como texto). Con HTTPS verás datos cifrados — que es precisamente la garantía de TLS del módulo 2.
• Statistics → Conversations: tabla de todas las conversaciones de la captura con bytes y duración; ideal para encontrar "quién está comiéndose el ancho de banda".

El servidor de la intranet (192.168.10.10) es un Linux sin escritorio: allí no hay Wireshark. La herramienta es tcpdump, que usa la misma sintaxis BPF de los filtros de captura y requiere privilegios (sudo):

Claves de lectura y de uso:

• -i eth0: interfaz donde escuchar; -n: no resolver nombres (más rápido y no genera tráfico DNS propio que contamine la captura).
• El filtro port 443 and host 192.168.10.21 va al final, en sintaxis BPF.
• Los flags van abreviados: [S] = SYN, [S.] = SYN+ACK (el punto es ACK), [.] = ACK, [F] = FIN, [R] = RST. Ahí está otra vez el handshake completo, ahora en texto plano.
• Otras opciones útiles: -c 100 (parar tras 100 paquetes), -v (más detalle, incluye TTL), -A (mostrar el contenido en ASCII, útil con HTTP sin cifrar).

El flujo de trabajo profesional combina ambas herramientas — capturar donde ocurre, analizar donde se está cómodo:

Recuerda la advertencia inicial: ese .pcap contiene comunicaciones reales. Trátalo como el dato sensible que es.

Reproduzcamos con captura el flujo completo que estudiaste al final del módulo 4: Marta abre https://intranet.grupomeridiano.example/api/proyectos con la caché DNS vacía. Captura en su PC, filtro de visualización dns || (ip.addr == 192.168.10.10 && tcp):

Observa el guion, que ya te sabes de memoria pero ahora tiene números:

1. DNS (paquetes 1–2): pregunta al DNS configurado (el router .10.1), que responde el registro A en 1,8 ms. Va sobre UDP puerto 53 — compruébalo desplegando la capa de transporte del paquete 1. Si repites la prueba, estos dos paquetes desaparecen: la respuesta quedó en caché (el TTL de registro de 06-01 en acción).
2. TCP (3–5): el handshake.
3. TLS (6–8): el saludo criptográfico. En el paquete 7 puedes desplegar y examinar el certificado del servidor.
4. HTTP (9–10): el GET y su respuesta viajan como "Application Data" — cifrados. Sabes que ahí dentro va GET /api/proyectos porque lo lanzaste tú, pero Wireshark no puede (ni debe) leerlo.

Tiempo total: menos de 20 ms. Guarda mentalmente esta captura "sana": es tu patrón de referencia para el siguiente análisis, donde algo va mal.

Síntoma: las videollamadas entre Marta (Valencia) y Jon (Bilbao) se congelan a ratos desde hace unos días; la navegación "parece" normal. Un ping -t 192.168.20.7 desde Valencia muestra pérdidas ocasionales (2 de cada ~30) y jitter alto — indicio, no diagnóstico. Con autorización del responsable de sistemas, capturamos en el PC de Marta durante una llamada de prueba y una transferencia de ficheros simultánea hacia Bilbao, y aplicamos el filtro:

Y en Statistics → TCP Stream Graphs (o simplemente contando con el filtro): ~3% de los segmentos hacia Bilbao son retransmisiones, concentradas en ráfagas. Interpretación, apoyada en lo que sabes de TCP (módulo 2) y de la VPN (módulo 4):

• Una retransmisión significa que TCP envió un segmento y no recibió su ACK a tiempo: el segmento (o su ACK) se perdió por el camino. Los Dup ACK son el receptor diciendo "me falta un trozo, reenvía".
• La navegación "parece normal" porque TCP repara la pérdida retransmitiendo — pagando latencia, que en una web apenas se nota. La videollamada usa UDP en tiempo real: lo perdido no se reenvía (no tendría sentido reenviar un fotograma viejo), así que la misma pérdida que TCP disimula, en la llamada se ve como congelación. Dos síntomas distintos, una sola causa: pérdida de paquetes en el trayecto Valencia–Bilbao.
• ¿Dónde? La captura en la LAN de Valencia muestra que los segmentos salen; el ping dentro de la sede no pierde nada; la pérdida aparece solo hacia la otra sede → el problema está en la VPN o en la línea de Internet que la transporta, no en las LAN. Es el mismo razonamiento de acotación del traceroute de 06-01, ahora con pruebas cuantificadas.
• Cierre del caso: con la captura como evidencia (3% de retransmisiones en ráfagas, marcas de tiempo), Meridiano abre incidencia con su ISP, que detecta saturación en la línea de Valencia en las horas de las ráfagas. Sin la captura, la conversación habría sido "va lento" / "por nosotros está bien".

• Capturar sin autorización "solo para aprender". No. Practica en tu propia red doméstica o en máquinas virtuales. En la empresa, sigue el procedimiento aunque tengas los permisos técnicos para saltártelo.
• Confundir las dos sintaxis de filtro. port 443 en la barra de visualización da error (rojo); tcp.port == 443 en un filtro de captura, también. Captura con BPF, visualiza con sintaxis Wireshark.
• Filtrar demasiado al capturar. Lo descartado no se recupera. Captura ancho, filtra en visualización.
• Esperar leer HTTPS. Verás handshake TLS, SNI y tamaños/tiempos — que ya es muchísimo para diagnóstico — pero no el contenido. Si necesitas el contenido de tu propia aplicación, la vía es mirar en los extremos (logs del servidor, curl -v), no romper el cifrado.
• Capturar en el sitio equivocado. En un switch no verás las conversaciones de otros equipos. Captura en el extremo implicado (PC o servidor) o pide un puerto espejo.
• Olvidar -n en tcpdump. Sin él, cada IP genera una consulta DNS inversa: la salida va a trompicones y tu propia captura se llena de tráfico DNS tuyo.
• Interpretar cualquier retransmisión como catástrofe. Alguna retransmisión aislada es vida normal en Internet. Preocupan los porcentajes sostenidos (≳1–3%) y las ráfagas correlacionadas con el síntoma.
• Dejar los .pcap tirados. Cifrados mientras vivan, borrados al cerrar la incidencia.

1. En una captura del PC de Ana ves, tres veces seguidas y con ~1, 2 y 4 segundos de separación, el mismo paquete: 192.168.10.24 → 203.0.113.40 TCP [SYN] 51330 → 443. No hay ningún SYN/ACK ni RST de vuelta. ¿Qué está pasando, qué diferencia hay con recibir un RST, y con qué síntoma de usuario se corresponde?
2. Quieres capturar en el servidor de la intranet (sin entorno gráfico) todo el tráfico DNS que el propio servidor genera o recibe, guardarlo en un fichero y analizarlo después en tu PC con Wireshark. Escribe el comando de captura y describe los dos pasos siguientes. ¿Qué condición previa no técnica debes cumplir antes de ejecutar nada?
3. Durante el análisis de la videollamada, un compañero propone: "filtremos la captura con tcp.analysis.retransmission desde el inicio, como filtro de captura, así el fichero pesa menos". Explica los dos errores de la propuesta.

1. Es el patrón de SYN sin respuesta con retransmisión exponencial: el sistema de Ana reintenta el SYN duplicando la espera (1 s, 2 s, 4 s...) porque nadie contesta. O el host 203.0.113.40 está caído, o —más frecuente— un firewall descarta silenciosamente el paquete (política drop). La diferencia con un RST es crucial: el RST es una respuesta activa ("host vivo, puerto cerrado" → error inmediato connection refused), mientras que el silencio produce un timeout largo: el usuario ve la aplicación "colgada" 20-30 segundos antes del error. Es la pareja "puerto cerrado vs host caído" del módulo 3, vista en paquetes.
2. Condición previa: autorización conforme a las políticas internas (es el servidor de la empresa y el tráfico DNS revela actividad de usuarios). Comando: sudo tcpdump -i eth0 -n port 53 -w /tmp/dns-intranet.pcap (DNS usa el puerto 53; -w guarda en formato pcap; se detiene con Ctrl+C o añadiendo -c N). Pasos siguientes: (1) copiar el fichero al PC de análisis (por ejemplo con scp), (2) abrirlo en Wireshark (File → Open) y analizarlo con filtros de visualización (dns). Al cerrar la incidencia, borrar el .pcap.
3. Primer error, sintáctico-conceptual: tcp.analysis.retransmission es un filtro de visualización; los filtros de captura usan sintaxis BPF y no existe tal filtro en ella — de hecho no puede existir, porque detectar una retransmisión exige comparar cada paquete con los anteriores de su flujo, y el filtro de captura decide paquete a paquete, sin memoria. Segundo error, metodológico: aunque se pudiera, te quedarías solo con las retransmisiones y sin su contexto (los paquetes originales, los Dup ACK, los tiempos entre ellos), que es justo lo que permite calcular el porcentaje de pérdida y localizarla. Se captura ancho y se filtra al visualizar.

Ya sabes bajar al nivel donde los paquetes no mienten: Wireshark con sus tres paneles (y la revelación de que el panel de detalle es la encapsulación de los módulos 2–4), la disciplina de los dos tipos de filtro, el three-way handshake contemplado por fin en paquetes reales de Marta contra la intranet, tcpdump para capturar en servidores y llevarte el .pcap a analizar con calma, y dos análisis completos: el flujo DNS→TCP→TLS→HTTP sano como patrón de referencia, y la videollamada lenta resuelta detectando retransmisiones en la VPN. Y, envolviéndolo todo, el marco que no es opcional: solo en redes propias o autorizadas, conforme a las políticas de la empresa, tratando las capturas como los datos sensibles que son. Tienes las utilidades rápidas (06-01) y el microscopio (06-02); lo que falta es lo que distingue al profesional del aficionado con herramientas: un método que decida qué comprobar, en qué orden y cuándo parar. Ese método sistemático — enfoques por capas, los 7 pasos, el árbol de decisión y tres incidencias de Meridiano resueltas de principio a fin — es la próxima y última lección del módulo.