SubnetMaster
TroubleshootingPacket analysisWireshark

Wireshark para troubleshooting de redes

Aprende a capturar y leer tráfico con Wireshark: elegir el punto de captura, usar filtros, seguir conversaciones y convertir paquetes en evidencia.

Volver a troubleshootingVer comandos de red

Qué aporta Wireshark

Wireshark es un analizador de protocolos: captura o abre paquetes y decodifica campos de cientos de protocolos. Su valor en troubleshooting es mostrar qué ocurrió en el cable o interfaz desde el punto de captura, en lugar de inferirlo únicamente a partir de mensajes de aplicación.

No es una herramienta mágica. Una captura sólo ve el tráfico que llega al punto seleccionado y muchos protocolos modernos cifran su contenido. Aun así, tiempos, direcciones, tamaños, flags y secuencias siguen aportando evidencia valiosa.

Elegir bien el punto de captura

Antes de capturar, decide dónde puede observarse el fenómeno. Capturar en el cliente responde preguntas distintas que capturar en el servidor, router o SPAN/mirror de un switch. Si el paquete sale del cliente pero nunca aparece en el servidor, el problema está en el camino; si llega y no existe respuesta, la investigación cambia de dirección.

En switching, un puerto normal no ve todo el tráfico de la VLAN. Para observar flujos de otros equipos suele necesitarse port mirroring/SPAN o una captura en un dispositivo por el que realmente pase el tráfico.

Capture filters vs display filters

Wireshark tiene dos mecanismos diferentes. Los capture filters deciden qué paquetes se guardan durante la captura y usan sintaxis pcap/BPF. Los display filters deciden qué paquetes ya capturados se muestran y usan el lenguaje de filtros de Wireshark.

Un display filter no elimina paquetes del fichero de captura; sólo cambia la vista. Por eso, cuando no estás seguro de qué necesitarás después, suele ser más seguro capturar un conjunto razonable y filtrar al analizar. En enlaces muy ocupados, un capture filter bien diseñado reduce carga y tamaño.

Display filters básicos

Ejemplos útiles son arp, dns, icmp, icmpv6, tcp, udp, ip.addr == 192.0.2.10 o tcp.port == 443. Puedes combinar expresiones con and, or y paréntesis.

Para investigar establecimiento TCP, tcp.flags.syn == 1 ayuda a localizar SYN/SYN-ACK. Para DNS, filtros como dns.flags.response == 1 permiten centrarse en respuestas. Usa el autocompletado y la referencia oficial porque los nombres de campos dependen del dissector.

Capture filters básicos

Los capture filters usan sintaxis pcap, por ejemplo host 192.0.2.10, port 53 o tcp port 443. Esta sintaxis no debe copiarse directamente al campo de display filter.

En TShark, la opción -f configura el filtro de captura y -Y el de visualización. La documentación oficial señala expresamente que son mecanismos y lenguajes distintos.

Cómo leer un paquete

La vista típica separa lista de paquetes, árbol de protocolos y bytes. Empieza por tiempo, origen, destino, protocolo y resumen; después expande las capas necesarias. En Ethernet observa MAC y EtherType; en IP, direcciones y TTL/Hop Limit; en TCP, puertos, flags, números de secuencia y ACK.

No interpretes un único paquete fuera de conversación. Muchos diagnósticos dependen del intercambio: solicitud y respuesta, SYN/SYN-ACK/ACK, consulta DNS y respuesta, ARP request/reply o mensajes ICMP asociados.

TCP: handshake, retransmisiones y cierre

En una conexión TCP normal se espera el establecimiento SYN → SYN/ACK → ACK. Un SYN repetido sin respuesta sugiere pérdida o filtrado en algún punto, mientras un RST puede indicar rechazo explícito o ausencia de servicio según el contexto.

Wireshark marca ciertos patrones como retransmisiones, ACK duplicados u out-of-order mediante análisis heurístico. Son pistas, no sentencias absolutas: captura incompleta, offloading de NIC o un punto de observación parcial puede alterar la interpretación.

DNS en Wireshark

Filtra con dns y compara ID, consulta, tipo y código de respuesta. Un NXDOMAIN significa que el nombre consultado no existe según esa respuesta; SERVFAIL indica que el resolver no pudo completar la resolución correctamente.

Si una aplicación parece lenta antes de conectar, revisa cuánto tarda DNS y si existen reintentos. Relaciona el análisis con la guía de DNS.

ARP y Neighbor Discovery

arp permite ver requests y replies IPv4. Para IPv6, Neighbor Discovery se transporta sobre ICMPv6; filtros icmpv6 ayudan a observar Neighbor Solicitation y Neighbor Advertisement.

Repetidas solicitudes sin respuesta pueden explicar por qué el host nunca llega a enviar el paquete IP esperado al siguiente salto.

Follow Stream y conversaciones

Wireshark puede reconstruir una conversación mediante funciones como Follow TCP Stream. Es útil para mantener juntos paquetes relacionados y entender el intercambio, aunque el contenido de protocolos cifrados seguirá protegido salvo que dispongas legítimamente de las claves y configuración necesaria.

Las vistas Statistics → Conversations y Endpoints ayudan a identificar quién habla con quién, volúmenes y protocolos dominantes.

Expert Information y estadísticas

Expert Information resume eventos que los dissectors consideran destacables. Úsalo como índice para investigar, no como diagnóstico automático. Una advertencia puede ser normal para una aplicación concreta y una captura sin advertencias puede seguir conteniendo un fallo lógico.

IO Graphs, Protocol Hierarchy, Conversations y TCP Stream Graphs permiten pasar de paquetes individuales a patrones temporales y volumétricos.

Qué puedes ver cuando hay cifrado

TLS, SSH, IPsec y otros protocolos protegen contenido. Incluso sin descifrar, normalmente puedes observar endpoints, puertos, establecimiento de sesiones, tamaños, tiempos y algunos metadatos. Eso suele bastar para distinguir «no llega», «se rechaza» y «se establece pero la aplicación falla después».

El descifrado sólo debe hacerse en entornos autorizados y con manejo seguro de claves. Nunca conviertas una captura de producción en un repositorio de secretos.

Privacidad y manejo de capturas

Los PCAP pueden contener datos personales, tokens, consultas DNS, nombres internos, direcciones privadas e incluso payloads en claro. Limita duración y alcance, controla el acceso y anonimiza antes de compartir.

Conserva también hora, interfaz y punto de captura. Un fichero sin contexto puede resultar difícil de interpretar semanas después.

Flujo práctico de análisis

1) Define el flujo: cliente, servidor, protocolo y hora. 2) Captura en un punto relevante. 3) Filtra por endpoints/protocolo. 4) Localiza el primer intercambio anómalo. 5) Comprueba si el fallo está antes o después de ese punto. 6) Si hace falta, captura simultáneamente en otro extremo para comparar.

Combina paquetes con los comandos del host, logs y métricas. Wireshark muestra tráfico; no sustituye la tabla de rutas ni la configuración del equipo.

Documentación y siguiente paso

La documentación oficial de Wireshark distingue capture filters y display filters y mantiene una referencia de campos actualizada. TShark usa el mismo motor de display filters y permite automatizar análisis desde CLI.

Si la captura revela descartes por política o fallos de establecimiento de túneles, continúa con ACL o VPN/IPsec.

Comparar capturas en dos puntos

Cuando una sola captura no basta, tomar dos capturas sincronizadas —por ejemplo en cliente y servidor— permite localizar dónde desaparece o cambia un paquete. Si el SYN aparece en el cliente pero no en el servidor, el fallo está en el camino; si llega al servidor y sale un RST, la red entregó el paquete y debes investigar servicio o política local.

Correlaciona por direcciones, puertos, números de secuencia y tiempo. Este enfoque encaja con el método general de troubleshooting: cada nueva captura debe responder una pregunta y reducir la zona sospechosa.