Captura de paquetes en Windows en la práctica — Cómo elegir entre pktmon, netsh trace y Wireshark

«La comunicación de la aplicación de negocio falla unas cuantas veces al mes. En el log solo aparece “tiempo de espera agotado”. Tampoco hay ningún error en el servidor, y no se conoce la condición de reproducción». En las investigaciones de fallos de comunicación, esta situación aparece con frecuencia.

Lo que se quiere saber entonces es si no se pudo conectar, o si la respuesta se detuvo después de conectar. Aunque el tiempo de espera sea el mismo, el siguiente lugar que investigar cambia.

En el log de la aplicación solo queda lo que la aplicación «decidió escribir». Con el solo resultado «tiempo de espera agotado» no se puede distinguir si el SYN no obtuvo respuesta, si el servidor se calló en una conexión ya establecida o si se cortó con un RST.

Examinar el nivel de abajo —los paquetes que realmente circularon por el cable— es la captura de paquetes. Frente a Process Monitor, que mira un nivel más abajo el acceso a archivos y al registro, esta mira un nivel más abajo la comunicación. Cuando se quiere confirmar hasta si el paquete llegó al destino, cobra importancia la captura en ambos lados que se trata en el capítulo 7.

flowchart TB
    accTitle: Los paquetes un nivel por debajo del log de la aplicación
    accDescr: En el log de la aplicación solo queda lo que se decidió escribir, y si el SYN no obtuvo respuesta, si se calló tras establecer, si se cortó con RST o si siquiera llegó, solo queda en los paquetes que realmente circularon por el cable
    log["Log de la aplicación"] --> dec["Solo queda lo que se decidió escribir"]
    dec --> to["El resultado es la palabra tiempo de espera"]
    to -->|Mirar un nivel más abajo| pkt["Paquetes que realmente circularon por el cable"]
    pkt --> q1["¿Sin respuesta al SYN?"]
    pkt --> q2["¿Silencio tras establecer?"]
    pkt --> q3["¿Corte con RST?"]
    pkt --> q4["¿Llegó al destino?"]

Figura 1: En el log solo queda el resultado; el desglose del tiempo de espera solo queda en los paquetes un nivel más abajo.

Aunque «no se pueda instalar Wireshark en el servidor del cliente», no hace falta renunciar a capturar. Aunque el control de cambios o la directiva de seguridad impidan añadir software, Windows tiene dos medios de captura de serie: pktmon y netsh trace.

La forma básica es el reparto capturar con la herramienta de serie en el terreno y leer con Wireshark en el propio equipo. Si se piensa la captura y el análisis como tareas distintas, la investigación avanza también en entornos con restricciones de instalación.

Este artículo se dirige al personal de sistemas de pequeñas y medianas empresas y a desarrolladores de aplicaciones Windows, y ordena cómo elegir entre pktmon, netsh trace y Wireshark, y el procedimiento práctico de cada uno. La trampa del tráfico de bucle invertido, el criterio de capturar en el cliente o en el servidor, cómo afrontar que TLS oculte el contenido, y la correlación con el log de la aplicación se explican a partir de fuentes primarias a agosto de 2026.

Leer a partir de lo que falla

Si es la primera lectura, fije el flujo de elegir la herramienta en el capítulo 2, capturar en los capítulos 3 y 4, y leer en el 5. Los capítulos 6 a 8 son precauciones sobre las condiciones de captura y el alcance de lo que se puede observar, y el 9 es el procedimiento para sacar una conclusión junto con el log de la aplicación.

1. Primero la conclusión

La captura y el análisis se pueden dejar a herramientas distintas

En el terreno se captura con pktmon o netsh trace, se convierte a pcapng y se analiza con Wireshark en el propio equipo. La salida de ambos es ETL, así que Wireshark no los abre tal cual. En pktmon se usa pktmon etl2pcap; en netsh trace, etl2pcapng, la herramienta de código abierto de Microsoft.¹²

El orden para elegir herramientas es primero pktmon, si no basta netsh trace, y el análisis de protocolo con Wireshark. La guía de investigación de Microsoft también indica este flujo.³

Antes de capturar, decida qué información dejar y dónde observar

pktmon viene de serie en Windows 10 / Windows Server 2019 o posterior y se usa en cuatro pasos: registrar un filtro, iniciar, detener, convertir. Su punto fuerte propio es saber dónde se descartó el paquete en la pila y el motivo de descarte. Sin embargo, de forma predeterminada solo quedan los primeros 128 bytes. Para leer el contenido, especifique --pkt-size 0 al iniciar.⁴⁵⁶

netsh trace es la herramienta de serie más antigua. Un escenario agrupa un conjunto de proveedores ETW y puede capturar paquetes junto con eventos internos de Windows. Para una captura que atraviesa un reinicio se usa persistent=yes.⁷⁸

El tráfico dirigido a localhost no pasa por la NIC física, así que no aparece en una captura del adaptador físico. Se usa el adaptador de bucle invertido de Npcap o la captura dentro de la pila de pktmon.⁹

Separe los hechos que se pueden leer del trato del archivo

Aunque TLS oculte el contenido, se puede investigar el establecimiento de la conexión, el éxito o fracaso del protocolo de enlace TLS, RST y quién se calló. El descifrado con SSLKEYLOGFILE es un medio limitado al entorno de desarrollo.¹⁰

En cambio, el archivo de captura contiene el propio contenido de la comunicación. Parta de que puede incluir credenciales e información personal, reduzca el destino y el período al mínimo, e incluya en el procedimiento de captura el acotado antes de sacarlo de la empresa.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (21 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Las tres herramientas de captura y cómo elegirlas

Los criterios son «qué se puede instalar en el terreno» y «qué se quiere dejar además de los paquetes». Primero se comparan las funciones de las tres herramientas.

Resulta más fácil pensarlo como pktmon y netsh trace «capturan», Wireshark «lee». Wireshark también puede capturar, pero no está disponible en entornos donde no se puede instalar.

También se puede convertir el ETL de las herramientas de serie a texto y leerlo. Sin embargo, convertir a pcapng y analizar en Wireshark avanza más la investigación que leer a ojo sin filtros de visualización ni análisis TCP.

flowchart TB
    accTitle: Capturar con la herramienta de serie, leer con Wireshark
    accDescr: En el terreno se captura ETL con pktmon o netsh trace, se convierte a pcapng con la herramienta de conversión de cada uno y se analiza con Wireshark en el propio equipo
    pk["pktmon (de serie)"] --> etla["Archivo ETL"]
    ns["netsh trace (de serie)"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["Analizar con Wireshark en el propio equipo"]

Figura 2: En el terreno se captura ETL con la herramienta de serie, se convierte a pcapng y se lee con Wireshark en el propio equipo.

La guía de investigación de pérdida de paquetes de Microsoft sigue el mismo esquema: primero capturar con pktmon y aislar la causa y, si no basta, pasar a un seguimiento de nivel de componente como netsh trace start scenario=InternetClient, y analizar el comportamiento del protocolo con Wireshark.³

Como premisa para leer qué muestra un paquete, la comprensión es más rápida si se puede imaginar el solapamiento de capas Ethernet, IP, TCP y datos de aplicación. La anatomía de las capas se ilustra en «Imaginar con claridad el modelo de referencia OSI».

3. pktmon en la práctica — Filtro, inicio, parada, conversión

La captura básica son cuatro pasos: registrar un filtro, iniciar, detener, convertir. Al terminar, también se limpian los filtros. Lo siguiente se ejecuta en una terminal con privilegios de administrador.

Antes de iniciar, compruebe los filtros existentes y cómo los limpiará después. El pktmon filter remove final no borra un filtro por nombre; borra todos los filtros registrados. En un entorno compartido con otra investigación, compruebe primero con pktmon filter list.

:: 1. Registrar primero un filtro para acotar el destino (TCP 8443 del servidor 192.168.10.20)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. Iniciar la captura. Registrar el paquete entero, sobrescribir en un búfer anular de 1 GB
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. Reproducir el suceso. Mientras se espera, los contadores muestran el caudal y los descartes
pktmon counters --drop-reason

:: 4. Detener y convertir a pcapng para Wireshark
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. Limpiar los filtros registrados (los filtros permanecen hasta que se borren de forma explícita).
::    Atención: filter remove no admite un nombre y borra «todos» los filtros registrados.
::    En un entorno donde queden filtros de otra investigación, compruebe primero con pktmon filter list
pktmon filter remove

flowchart TB
    accTitle: Procedimiento básico de pktmon
    accDescr: Acotar el destino con el registro de un filtro, iniciar la captura, reproducir el suceso, detener, convertir a pcapng con etl2pcap y, al final, borrar los filtros registrados
    fa["1. Acotar el destino con filter add"] --> st["2. Iniciar la captura con start --capture"]
    st --> re["3. Reproducir el suceso"]
    re -.-> ct["Comprobar caudal y descartes con counters"]
    re --> sp["4. Detener con stop"]
    sp --> cv["Convertir a pcapng con etl2pcap"]
    cv --> rm["5. Limpiar con filter remove"]

Figura 3: pktmon empieza por el registro del filtro y, tras capturar, detener y convertir, limpia el filtro de forma explícita.

Si se deciden estos cuatro puntos antes de ejecutar los comandos, se reduce el tener que volver a capturar.

Qué comprobar antes de capturar

Acotar el destino: varios filtros son una condición OR

Los filtros se registran antes de iniciar la captura. La documentación de Microsoft también recomienda con fuerza aplicar filtros antes de iniciar, porque capturar todo el tráfico genera demasiado ruido. Los filtros se pueden especificar por dirección IP, puerto, dirección MAC, protocolo, ID de VLAN y similares, y se pueden registrar hasta 32. Varios filtros son una condición OR: «si coincide con cualquiera, se registra».⁴

Acotar la dirección: no se distinguen origen y destino

El filtro de pktmon no distingue origen y destino. -i 192.168.10.20 significa «paquetes en los que esta dirección es origen o destino». El acotado por dirección se hace después de convertir, con el filtro de visualización de Wireshark.⁴

Decidir el alcance del registro: ¿solo cabeceras o el paquete entero?

El tamaño de paquete predeterminado es 128 bytes. Si basta el análisis de cabeceras, eso alcanza; si se va a leer hasta los datos de aplicación, se registra el conjunto con --pkt-size 0.⁶

Decidir la capacidad: búfer anular y visualización en tiempo real

El registro está de forma predeterminada en modo circular (búfer anular), con un tamaño predeterminado de 512 MB. Además de cambiar el tope con --file-size, --log-mode real-time muestra en pantalla en tiempo real y no crea archivo de registro. Si primero se confirma con la visualización en tiempo real que «se ve la comunicación buscada» y después se monta la captura de producción, se evitan los fallos en vacío.⁶

flowchart TB
    accTitle: Cómo actúan los filtros de pktmon
    accDescr: Los varios filtros registrados actúan con una condición OR de registrar si coincide cualquiera, y la dirección especificada no distingue origen y destino, así que el acotado de dirección se hace después de convertir con el filtro de visualización de Wireshark
    f1["Filtro 1"] --> orc["Si coincide cualquiera, se registra"]
    f2["Filtro 2"] --> orc
    f3["Filtro 3 (hasta 32)"] --> orc
    orc --> rec["Se registra en el log de captura (condición OR)"]
    rec -.-> nodir["No se distinguen origen y destino"]
    nodir -.-> ws["La dirección se acota después de convertir, en Wireshark"]

Figura 4: Varios filtros actúan con condición OR, y si es origen o destino se acota después de convertir, en Wireshark.

3.1. El punto fuerte propio de pktmon — Saber dónde se descartó

El valor propio de pktmon, distinto de Wireshark, es capturar el paquete en varios puntos de la pila de red, no en un solo punto de la NIC, y poder informar el lugar y el motivo del descarte. Como se sabe hasta qué componente llegó el paquete y dónde desapareció, se puede llegar a la causa sin prueba y error a partir de motivos de descarte como «desajuste de MTU» o «filtro VLAN».⁵

flowchart TB
    accTitle: pktmon captura en varios puntos de la pila
    accDescr: pktmon captura el paquete en varios puntos de la pila de red, no en un solo punto de la NIC, así que puede informar con motivo hasta qué componente llegó y dónde se descartó
    pin["Paquete"] --> p1["Captura en el punto 1"]
    p1 --> p2["Captura en el punto 2"]
    p2 --> p3["Descarte en el punto 3"]
    p3 -.-> rz["Informar el lugar de descarte y el motivo"]
    rz -.-> ex["Ejemplo: desajuste de MTU o filtro VLAN"]

Figura 5: Al capturar en varios puntos de la pila, se sabe con motivo hasta dónde llegó y dónde se descartó.

Primero los contadores; si hace falta, el log de texto

• Con pktmon list se pueden ver la lista y los ID de los componentes de red que se vigilan (NIC, pila de protocolos, controladores de filtro, etc.).
• Con pktmon counters --drop-reason se puede listar el contador de paso/descarte por componente y el motivo de descarte más reciente. Resulta útil como primer aislamiento antes de analizar el log.¹¹
• Si se convierte a texto con pktmon etl2txt, los paquetes descartados salen con drop y dropReason (motivo de descarte).⁴

La sospecha de «se está descartando en algún punto del SO antes de llegar a la aplicación» no se cierra solo mirando Wireshark. Por ejemplo, en el aislamiento de un caso en el que el firewall lo tira por una regla de entrada incompleta («El Firewall de Windows y las aplicaciones de negocio»), esta función sirve.

Antes de pasarlo a Wireshark, acote el punto de captura

pktmon registra el mismo paquete en varios puntos de la pila. Si se convierte tal cual a pcapng, el mismo paquete puede verse duplicado. En pcapng no se hereda la información de «en qué componente se capturó».

Si el objetivo es leerlo en Wireshark, se acota el punto con --component-id de pktmon etl2pcap al convertir. También existe el método de poner solo los descartes en otro archivo con --drop-only.¹

flowchart TB
    accTitle: Por qué el mismo paquete se ve duplicado al convertir a pcapng
    accDescr: pktmon registra el mismo paquete en varios puntos de la pila y pcapng no hereda la información de en qué componente se capturó, así que puede verse duplicado; lo habitual es acotar el punto con component-id o poner solo los descartes en otro archivo con drop-only al convertir
    same["Registrar el mismo paquete en varios puntos"] --> conv["Convertir tal cual a pcapng"]
    conv --> lost["No se hereda la información del punto de captura"]
    lost --> dup["El mismo paquete se ve duplicado"]
    dup --> c1["Acotar el punto con --component-id"]
    dup --> c2["Otro archivo con --drop-only"]

Figura 6: Como la información del punto de captura no se hereda en pcapng, lo habitual es acotar el punto y después convertir.

4. netsh trace en la práctica — Escenarios, ETL y captura a lo largo de un reinicio

netsh trace es el mecanismo de captura de seguimiento que lleva Windows desde antes que pktmon. Su rasgo es poder activar de una vez, en la unidad de «escenario», el conjunto de proveedores ETW relacionados con ese problema.⁸

:: Lista de escenarios disponibles y comprobación de los proveedores que incluye un escenario
netsh trace show scenarios
netsh trace show scenario netconnection

:: Inicio de la captura. Con captura de paquetes, búfer circular de 1 GB
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: Reproducir el suceso y detener (la fusión tarda un poco)
netsh trace stop

Condiciones de captura que decidir en netsh trace

Si también se quieren paquetes, añada capture=yes

Si se añade capture=yes se activa la captura de paquetes y se puede acotar el destino con un filtro de captura como ipv4.address=192.168.10.20. La lista de filtros se comprueba con netsh trace show capturefilterHelp.⁸

Junto con el ETL también queda información de entorno en .cab

Al detener se genera, además del archivo ETL, un archivo .cab. El .cab incluye información del sistema como la configuración de adaptadores y la compilación del SO, y puede servir también para recoger información de entorno.⁸

Antes de iniciar, compruebe si hay una sesión existente

Solo se puede ejecutar una sesión de seguimiento a la vez. Antes de empezar otra captura, compruebe con netsh trace show status que no quede una sesión en marcha.⁸

Para un suceso justo después de un reinicio, use persistent=yes

Si se añade persistent=yes, la sesión se mantiene a lo largo de un reinicio. La captura de sucesos en los que no da tiempo a iniciar a mano —«falla la comunicación solo un instante después del reinicio», «falla la conexión del servicio al arrancar»— es el terreno propio de netsh trace.⁷

flowchart TB
    accTitle: Captura por escenario de netsh trace
    accDescr: Al iniciar indicando un escenario se activa de una vez el conjunto de proveedores ETW; si se añade capture=yes también se capturan paquetes; al detener se generan el archivo ETL y el archivo .cab
    sc["Iniciar indicando un escenario"] --> pv["Activar el conjunto de proveedores"]
    sc -->|capture=yes| pc["Capturar también paquetes"]
    pv --> re["Reproducir el suceso"]
    pc --> re
    re --> sp["Detener con stop"]
    sp --> etl["Archivo ETL"]
    sp --> cab[".cab (información del sistema)"]

Figura 7: Al iniciar con un escenario se activa de una vez el conjunto de proveedores, y al detener se generan ETL y .cab.

4.1. Poner el ETL en una forma que Wireshark pueda leer — etl2pcapng

El ETL de netsh trace no se abre tal cual en Wireshark. Con etl2pcapng, la herramienta de código abierto que Microsoft publica en GitHub, se pueden convertir a pcapng los paquetes de un ETL capturado con netsh trace start capture=yes.²

etl2pcapng.exe C:\temp\nettrace.etl C:\temp\nettrace.pcapng

etl2pcapng escribe, al convertir, el identificador de proceso implicado en el paquete como comentario del paquete. Como en Wireshark se puede confirmar «de qué proceso es la comunicación», sirve para aislar en un entorno donde varias aplicaciones comunican en el mismo servidor.²

Los paquetes y los eventos internos de Windows se leen de forma distinta

Además, los eventos ETW (eventos internos de Windows que registran los proveedores del escenario) no se convierten a pcapng. Si se quieren leer también los eventos, se convierten a texto o similar con netsh trace convert input=C:\temp\nettrace.etl, o se abren con Windows Performance Analyzer y similares.⁷³

flowchart TB
    accTitle: La lectura del ETL de netsh trace se divide en dos
    accDescr: Los paquetes del ETL se convierten a pcapng con etl2pcapng y se leen en Wireshark; los eventos ETW no se convierten a pcapng, así que se leen con netsh trace convert o Windows Performance Analyzer
    etl["ETL de netsh trace"] --> pk["Paquetes"]
    etl --> ev["Eventos ETW"]
    pk -->|etl2pcapng| pc["Convertir a pcapng"]
    pc --> ws["Leer en Wireshark"]
    pc -.-> pid["El identificador de proceso queda en el comentario"]
    ev -.-> no["No se convierte a pcapng"]
    no --> alt["Leer con convert o WPA"]

Figura 8: De un ETL, los paquetes se leen convertidos a pcapng y los eventos ETW se leen por otro medio.

5. Introducción a la lectura en Wireshark — Filtros de visualización y análisis TCP

El análisis avanza en el orden acotar el destino → confirmar la forma TCP → si hace falta, ver toda la conversación. Primero se abre el pcapng y se recorta el ruido con un filtro de visualización.¹²¹³

Acotar lo que se lee con un filtro de visualización

tcp.analysis.* son marcas de análisis que Wireshark asigna de forma automática al seguir los números de secuencia TCP. Como recogen de forma mecánica retransmisiones, ACK duplicados, desorden, ZeroWindow y similares, el hábito al empezar a leer es escribir primero tcp.analysis.flags y listar «los puntos que parecen un problema».¹³

Dividir el tiempo de espera en cuatro puntos de comprobación

Cuando tcp.analysis.flags da un primer indicio, se confirma en este orden. En particular, una retransmisión es la observación de que «no ha vuelto un ACK», y es importante no decidir, con un solo lado, si se perdió el de ida o el de vuelta.

1. ¿Se estableció la conexión?: SYN, SYN/ACK, ACK

¿Se completó el protocolo de enlace de tres vías? ¿Están las tres piezas SYN→SYN/ACK→ACK? Si se repite SYN y no hay respuesta, no está llegando al otro lado o se descarta en silencio por el camino (el patrón típico de un firewall).

2. ¿Se cortó de forma forzada?: el momento del RST y el origen

¿De qué lado salió el RST? Si el RST es inmediato al SYN, nadie está escuchando en el puerto de destino; si es un RST tras establecer, alguno de los dos cortó la conexión a la fuerza. La IP de origen del RST es la prueba directa de «quién cortó».

3. ¿Vuelve el ACK?: continuación de retransmisiones

¿Siguen las retransmisiones? Que se repita la retransmisión del mismo segmento es la señal de que al emisor no le está volviendo la confirmación (ACK). Si se perdió el dato de ida o el ACK de vuelta no se puede determinar con la captura de un solo lado (por eso funciona «capturar en ambos lados» del capítulo siguiente). La profundización en retransmisión y tiempo de espera se trata en «Causa y aislamiento de que la comunicación de una cámara industrial se detenga por retransmisión TCP».

4. ¿El receptor está atascado?: ZeroWindow

¿Sale ZeroWindow? Es la señal de que la aplicación receptora no está leyendo datos del socket y el búfer de recepción está lleno. Es un fundamento para sospechar no de la red, sino del diseño de la aplicación receptora («El malentendido de que se puede hacer Receive por cada unidad de Send en TCP»).

flowchart TB
    accTitle: Orden de las formas que buscar en una investigación de tiempo de espera
    accDescr: Confirmar en este orden el establecimiento del protocolo de enlace de tres vías, la presencia de RST y su origen, la continuación de retransmisiones y ZeroWindow, para dar con la causa
    hs{"¿Volvió respuesta al SYN?"} -->|No| ng["Sospecha de descarte sin llegar (típico de FW)"]
    hs -->|Sí| rs{"¿Hay un RST?"}
    rs -->|Sí| who["El origen del RST es quien cortó"]
    rs -->|No| rt{"¿Siguen las retransmisiones?"}
    rt -->|Sí| ack["Señal de que no vuelve el ACK"]
    rt -->|No| zw{"¿Hay ZeroWindow?"}
    zw -->|Sí| app["Señal de que la aplicación receptora no está leyendo"]

Figura 9: Si se busca la forma en el orden protocolo de enlace, RST, retransmisión y ZeroWindow, se acota el siguiente lugar que investigar.

Cuando hay mucha comunicación, leer tras una vista de conjunto con estadísticas

Antes de leer paquete a paquete, también es eficaz buscar la conversación y la franja horaria de destino con estadísticas.

flowchart TB
    accTitle: Vista de conjunto con estadísticas y después acotar la conversación
    accDescr: Listar en Conversations qué comunicación habló cuándo y cuánto para identificar la conversación de destino, captar en el gráfico de E/S la franja que quedó en silencio, filtrar solo esa conversación y leerla de seguido en el flujo TCP
    ov["Vista de conjunto con estadísticas"] --> cv["Lista de conversaciones en Conversations"]
    ov --> io["Ver el caudal en el gráfico de E/S"]
    cv --> flt["Filtrar solo la conversación de destino"]
    io -.-> mute["Se ve la hora en que quedó en silencio"]
    flt --> fs["Leer de seguido en el flujo TCP"]

Figura 10: Antes de leer paquete a paquete, se hace una vista de conjunto con estadísticas, se acota la conversación de destino y después se lee de seguido.

6. La trampa del tráfico de bucle invertido — Lo dirigido a localhost no pasa por la NIC

Intentar investigar la comunicación entre aplicaciones de la misma PC —por ejemplo, la conexión de una aplicación de negocio a un servicio intermedio en localhost:8080— y atascarse con «en Wireshark no sale nada» es una trampa clásica.

La causa está clara. El tráfico dirigido a localhost (127.0.0.1) no pasa por la NIC física; se devuelve por la ruta de bucle invertido interna del SO. En una captura habitual dirigida al adaptador físico no aparece desde el principio.⁹

flowchart TB
    accTitle: Por qué el tráfico dirigido a localhost no aparece en la captura
    accDescr: El tráfico dirigido a localhost no pasa por la NIC física y se devuelve por la ruta de bucle invertido interna del SO, así que no aparece en una captura habitual dirigida al adaptador físico
    app["Aplicación"] --> stack["Pila de red"]
    stack -->|Hacia el exterior| nic["NIC física"]
    nic --> seen["Aparece en una captura habitual"]
    stack -->|Hacia localhost| lo["Devolución interna del SO"]
    lo -.-> miss["No aparece en una captura habitual"]
    lo -.-> alt["Capturar con bucle invertido de Npcap o con pktmon"]

Figura 11: Lo dirigido a localhost se devuelve antes de la NIC, así que no aparece desde el principio en una captura del adaptador físico.

Ajustar el método de captura a la ruta de bucle invertido

Hay dos remedios.

• Si se captura con Wireshark: elija como destino de captura el «Adapter for loopback traffic capture» que ofrece Npcap. El instalador de Wireshark para Windows (3.0 o posterior) incluye Npcap, así que en un entorno donde ya está Wireshark se puede usar sin trabajo adicional.⁹
• Si se captura con la herramienta de serie: pktmon captura en varios puntos internos de la pila de red, no en el exterior de la NIC⁵, así que también sirve para observar el tráfico de bucle invertido. Para mayor certeza, antes de montar la espera de reproducción de producción, confirme en esa entorno con la visualización en tiempo real pktmon start -c -m real-time que se ve de verdad el tráfico de bucle invertido de destino.

También en la especificación de dirección hay dos confusiones

localhost no apunta necesariamente a 127.0.0.1

«localhost» a veces se resuelve a ::1 de IPv6. El patrón es que la aplicación se conecta a ::1 de IPv6 y quien investiga mira solo 127.0.0.1 (IPv4) y concluye por error que «no hay comunicación». El filtro de visualización se pone en ambos, como ip.addr == 127.0.0.1 || ipv6.addr == ::1, o se indica el destino de conexión de la aplicación por dirección.⁹

Aunque se indique la IP real propia, no tiene por qué pasar por la NIC física

El tráfico dirigido a la IP real de uno mismo tampoco sale al cable. Al conectar desde 192.168.10.5 de la misma PC hacia 192.168.10.5, aunque el destino sea la IP real se devuelve dentro del SO. Recuerde que «como indico la IP real, debería pasar por la NIC» no es necesariamente cierto.

flowchart TB
    accTitle: La confusión de que localhost se resuelve a IPv6
    accDescr: El localhost de la aplicación a veces se resuelve a ::1 de IPv6 y se conecta, y si quien investiga mira solo 127.0.0.1 concluye por error que no hay comunicación, así que se confirma poniendo filtro en ambas direcciones o indicando el destino por dirección
    app["La aplicación se conecta a localhost"] --> v6["En realidad se resuelve a ::1 (IPv6)"]
    look["Quien investiga mira solo 127.0.0.1"] --> none["En la pantalla no sale nada"]
    v6 --> none
    none --> fix1["Poner filtro en ambas direcciones"]
    none --> fix2["Indicar el destino por dirección"]

Figura 12: Atención a la confusión de que localhost se resuelve a ::1 y, mirando solo 127.0.0.1, se concluye por error que «no hay comunicación».

7. Dónde capturar — ¿Un lado, ambos lados, sincronización de reloj?

Con un solo lado se obtiene el hecho visto desde ese punto de captura. El lugar de captura se elige según si primero se quiere ver el panorama o si se quiere confirmar hasta en qué sentido, ida o vuelta, desapareció la comunicación.

Aunque en el lado cliente sigan las retransmisiones, con un solo lado no se pueden distinguir estas dos.

• El paquete enviado desapareció antes de llegar al servidor.
• El paquete llegó al servidor, pero la respuesta desapareció en el camino de vuelta.

Si se captura en ambos lados y se correlaciona, se fija quién se calló, como «el cliente envió y al servidor no llegó». En las situaciones en las que se quiere fijar la frontera de responsabilidad (aplicación, SO, equipo de red, destino), se organiza desde el principio la captura en ambos lados.

flowchart TB
    accTitle: Lo que se averigua con captura de un lado y de ambos lados
    accDescr: Con la captura de un solo lado no se distingue si desapareció el paquete de ida o la respuesta de vuelta; si se captura en ambos lados y se correlaciona, se fija quién se calló
    one["Capturar solo un lado"] --> fact["Solo el hecho visto desde la propia posición"]
    fact --> und["No se distingue si desapareció la ida o la vuelta"]
    both["Capturar en ambos lados a la vez"] --> mt["Correlacionar"]
    mt --> fix["Se fija quién se calló"]
    mt -.-> pre["La premisa es la sincronización de reloj de ambas máquinas"]

Figura 13: Con un lado solo se sabe el hecho visto; la frontera de responsabilidad se fija de verdad al correlacionar ambos lados.

7.1. La premisa de la correlación es la sincronización de reloj

Para correlacionar las capturas de ambos lados, los relojes de ambas máquinas tienen que estar alineados. Antes de empezar a capturar, se comprueba y se registra el desfase de reloj.

:: Comprobar el estado de sincronización de reloj (destino de sincronización y última hora de sincronización)
w32tm /query /status

:: Medir de verdad la diferencia de reloj con el servidor de destino (5 muestras)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchart es el comando que muestra el desfase de reloj entre uno y el otro equipo, y es el fundamento para corregir en la correlación con «el reloj del servidor iba +0,8 s».¹⁴ En un entorno con un desfase grande, al final el atajo es corregir primero la sincronización de reloj y después capturar.

flowchart TB
    accTitle: Procedimiento para comprobar la diferencia de reloj antes de correlacionar
    accDescr: Comprobar con w32tm el estado de sincronización del propio reloj, medir de verdad la diferencia con el servidor de destino con stripchart y registrarla, usarla como fundamento de corrección al correlacionar, y, si el desfase es grande, corregir primero la sincronización y después capturar
    st["Comprobar el estado de sincronización con query"] --> mc["Medir de verdad la diferencia con stripchart"]
    mc --> rc["Registrar el desfase"]
    rc --> use["Fundamento de corrección al correlacionar"]
    mc -.-> big["Si el desfase es grande, corregir primero la sincronización"]

Figura 14: Antes de capturar se mide de verdad la diferencia de reloj y se registra, y se usa como fundamento de corrección al correlacionar.

7.2. Para «no se sabe cuándo ocurrirá», un búfer anular

En un suceso cuya condición de reproducción se desconoce, lo básico es dejarlo capturando en un búfer anular y detenerlo cuando ocurra.

• pktmon: el modo predeterminado es circular. Se indica el tope (MB) con --file-size y se sobrescribe desde los paquetes más antiguos.⁶
• netsh trace: se indica como maxSize=1024 filemode=circular.⁷
• Wireshark: en [Captura]→[Opciones]→[Salida] se puede configurar «varios archivos + búfer anular». Al cambiar por tamaño de archivo o por tiempo y conservar solo los N más recientes, se puede dejar girando mucho tiempo con un tope de uso de disco.¹⁵

Decidir no solo la capacidad, sino también cómo detener después de que ocurra

En cualquiera de los casos, comparta con el responsable del terreno la operación de cuando ocurra el suceso, «anotar la hora de aparición y después» detener la captura. El búfer anular borra el pasado cuanto más se espera, así que si el procedimiento desde la aparición hasta la parada es largo, se sobrescribe el tramo que importaba.

flowchart TB
    accTitle: Operación de espera con búfer anular
    accDescr: Un suceso cuya condición de reproducción se desconoce se deja capturando en un búfer anular; cuando ocurre se anota la hora de aparición y se detiene de inmediato; si la parada se retrasa, se sobrescribe desde los paquetes antiguos y desaparece el tramo que importaba
    st["Iniciar la captura con búfer anular"] --> wt["Esperar dejando capturar"]
    wt --> ev["Ocurre el suceso"]
    ev --> memo["Anotar la hora de aparición"]
    memo --> sp["Detener de inmediato"]
    wt -.-> ow["Se sobrescribe desde los paquetes antiguos"]
    ow -.-> late["Si la parada se retrasa, desaparece el tramo que importaba"]

Figura 15: El búfer anular borra el pasado cuanto más se espera, así que tras anotar la hora de aparición se detiene de inmediato.

8. El problema de que TLS oculte el contenido — Lo que se sabe aunque no se vea

Antes de descifrar, confirmar el esqueleto de la comunicación

Gran parte de la comunicación de negocio actual es TLS (HTTPS). Se tiende a pensar «si está cifrada, capturar no sirve», pero la mayor parte de lo que se quiere saber en una investigación de tiempo de espera se puede saber aunque siga cifrada.

• Si se estableció la conexión TCP (protocolo de enlace de tres vías)
• Hasta dónde avanzó el protocolo de enlace TLS: si volvió ServerHello al ClientHello, si se cortó a mitad del protocolo de enlace con RST o una alerta
• El nombre de host de destino que va en ClientHello (SNI) y la versión TLS negociada
• Tras establecer, quién dejó de enviar. La posición del silencio, retransmisiones, RST, o un cierre normal (FIN)

Es decir, para aislar «no conecta», «se corta a mitad» o «no vuelve respuesta», casi no hace falta descifrar el contenido. Lo que se pierde con el cifrado es “de qué se habló”; “quién se calló y cuándo” queda.

flowchart TB
    accTitle: Lo que se ve y lo que no se ve en una captura TLS
    accDescr: Lo que el cifrado oculta es solo el contenido de los datos de aplicación; el establecimiento de la conexión TCP, el éxito o fracaso del protocolo de enlace TLS, SNI y versión TLS, RST y quién se calló se pueden saber aunque siga cifrado
    tls["Captura de comunicación TLS"] --> vis["Lo que se ve"]
    tls --> hid["Lo que no se ve"]
    vis --> v1["Establecimiento de la conexión TCP"]
    vis --> v2["Éxito o fracaso de TLS y SNI"]
    vis --> v3["RST y quién se calló"]
    hid --> h1["El contenido de los datos de la aplicación"]

Figura 16: Lo que se pierde con el cifrado es solo el contenido; el esqueleto de la comunicación se puede leer con TLS tal cual.

Solo si hace falta el contenido, comprobar si se puede descifrar

Aun así, si hace falta el contenido, Wireshark tiene un mecanismo para descifrar TLS con la clave de sesión volcada mediante la variable de entorno SSLKEYLOGFILE. Sin embargo, lo admiten solo algunas implementaciones, como los navegadores Firefox, Chrome y Edge de la familia Chromium o las bibliotecas de la familia OpenSSL, y el SChannel de serie de Windows (aplicaciones que usan WinHTTP o WinINET) no admite este mecanismo.¹⁰ Por la naturaleza de que la clave de sesión se vuelca a un archivo —quien tenga ese archivo puede descifrar toda la comunicación—, no es un medio para el entorno de producción, sino para reproducción y depuración en el de desarrollo.

flowchart TB
    accTitle: Mecanismo y límites del descifrado con SSLKEYLOGFILE
    accDescr: Con la clave de sesión volcada con SSLKEYLOGFILE se puede descifrar TLS en Wireshark, pero lo admiten solo algunas implementaciones como Firefox o la familia Chrome y SChannel no es compatible; quien tenga el archivo de clave puede descifrar la comunicación, así que es un medio limitado al entorno de desarrollo
    env["Configurar SSLKEYLOGFILE"] --> key["Volcar la clave de sesión a un archivo"]
    key --> ws["Descifrar y leer en Wireshark"]
    key -.-> risk["Quien tenga la clave puede descifrarlo todo"]
    risk -.-> dev["Situarlo como limitado al entorno de desarrollo"]
    env -.-> sup["Solo lo admiten algunas implementaciones TLS"]
    sup -.-> sch["SChannel no es compatible"]

Figura 17: Se puede descifrar volcando la clave de sesión, pero las implementaciones compatibles son limitadas y, por la naturaleza de la clave, es un medio limitado al entorno de desarrollo.

Además, en la comunicación a través de un proxy interno, el destino que aparece en la captura es el servidor proxy y TLS circula dentro del túnel CONNECT. El problema previo de hacia qué proxy se dirige la aplicación se ordena en el artículo hermano publicado el mismo día, «Proxy interno de la empresa y aplicaciones de Windows — Cómo se resuelve el proxy en WinINET, WinHTTP y .NET».

9. Correlación con el log de la aplicación — Alinear en el mismo eje temporal

Que la captura por sí sola dé una conclusión es, en realidad, poco frecuente. El factor decisivo en la práctica es alinear una línea del log de la aplicación y un ida y vuelta de paquetes sobre el mismo eje temporal.

Sustituir una línea del log por un hecho observado en los paquetes

Primero, a partir de la hora de la excepción, se busca el tramo en que empezó la comunicación.

Paso 1: Buscar la hora de inicio a partir de la hora de la excepción y el valor de tiempo de espera

Se identifica la hora del suceso en el log de la aplicación (ejemplo: excepción de tiempo de espera a las 10:23:41). Si el valor de tiempo de espera es 30 segundos, el inicio debería ser hacia las 10:23:11.

Paso 2: Poner Wireshark en visualización de fecha y hora, y acotar el tramo correspondiente

Se cambia la visualización de hora de Wireshark a [Ver]→[Formato de visualización de hora]→[Fecha y hora], y se acota el tramo correspondiente con un filtro de visualización (también se puede acotar por hora, como frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00").

Paso 3: Confirmar el protocolo de enlace, RST, retransmisión y ZeroWindow

En ese tramo se confirma el orden del capítulo 5 (protocolo de enlace → RST → retransmisión → ZeroWindow). Si se llega a correlacionar hasta «30 segundos antes de la hora de tiempo de espera del log se envió un SYN y después solo retransmisiones de SYN», el “tiempo de espera” del log se sustituye por el hecho observado de que «en este punto de captura no volvió ninguna respuesta» (si el SYN no llegó al otro lado o el SYN/ACK de respuesta se perdió en el camino de vuelta no se puede fijar solo con este punto de captura. Si se quiere fijar, se correlaciona con la captura del lado servidor).

Paso 4: Corregir la diferencia de reloj y la zona horaria

Se corrige siempre el desfase entre la hora de la captura y la del log (la diferencia de reloj medida en el apartado 7.1, la notación de zona horaria del log). Un error de correlación de unos segundos hace culpable a otra comunicación.

flowchart TB
    accTitle: Procedimiento para correlacionar el log de la aplicación y los paquetes
    accDescr: Identificar la hora del suceso en el log de la aplicación, calcular hacia atrás la hora de inicio a partir del valor de tiempo de espera, acotar el tramo correspondiente en Wireshark, confirmar las formas en el orden del capítulo 5 y corregir el desfase de reloj para alinearlas en el mismo eje temporal
    lg["1. Identificar la hora del suceso en el log"] --> rev["Calcular hacia atrás el inicio a partir del valor de tiempo de espera"]
    rev --> flt["2. Acotar el tramo correspondiente con un filtro de visualización"]
    flt --> chk["3. Confirmar las formas en el orden del capítulo 5"]
    chk --> adj["4. Corregir el desfase de reloj"]
    adj --> done["La frase del log se convierte en un hecho observado"]

Figura 18: Se acota el tramo a partir de la hora del log, se confirman las formas y se corrige la diferencia de reloj para alinearlas en el mismo eje.

Antes de entregarlo a un tercero, extraer solo la conversación necesaria

Cuando se entrega el resultado de la investigación a un tercero (proveedor, operador de línea, responsable de red del cliente), recortar el ruido con un filtro y después entregarlo es tanto cortesía como medida de seguridad. Si en Wireshark se acota solo la conversación de destino con un filtro de visualización y en [Archivo]→[Exportar paquetes especificados] se guarda «solo los paquetes mostrados», se obtiene un pcapng pequeño con solo el alcance necesario.

Decidir desde antes de capturar la conservación y la eliminación de la información confidencial

El archivo de captura contiene el propio contenido de la comunicación. Puede incluir credenciales de protocolos en texto claro, cookies HTTP y claves de API, el contenido de correo o de informes, e información personal. Decida estos tres puntos junto con el procedimiento de captura.

• Captura al mínimo necesario: acotar el destino con el filtro previo (capítulos 3 y 4) y reducir también el período. No hacer «por si acaso, todo» en el entorno del cliente
• Acotado antes de entregar: exportar solo la conversación de destino y no incluir comunicación de terceros sin relación. Si queda una parte confidencial, acordar con el destinatario el enmascarado u otro medio
• Conservación y eliminación: decidir el lugar, el plazo y la eliminación del archivo capturado, y borrarlo al terminar la investigación

flowchart TB
    accTitle: Tres decisiones antes de entregar un archivo de captura
    accDescr: Como la captura contiene el propio contenido de la comunicación, se acota al mínimo necesario con el filtro previo y el período, antes de entregar se extrae solo la conversación de destino sin incluir comunicación sin relación, y se decide el lugar y el plazo de conservación para borrar al terminar la investigación; estos tres puntos se deciden junto con el procedimiento de captura
    cap["La captura contiene el contenido de la comunicación"] --> p1["Capturar al mínimo necesario"]
    cap --> p2["Antes de entregar, extraer solo el destino"]
    cap --> p3["Decidir el plazo de conservación y borrar"]
    p2 -.-> exp["Acotar con el filtro de visualización y exportar"]

Figura 19: Decidir junto con el procedimiento de captura los tres puntos: captura al mínimo, acotado antes de entregar, conservación y eliminación.

10. Resumen

• Un nivel por debajo del «tiempo de espera agotado» del log de la aplicación está el hecho de los paquetes que realmente circularon por el cable. Si no hay respuesta al SYN, si se cortó con RST, si siguieron las retransmisiones o si hay ZeroWindow, cambia el siguiente lugar que investigar.
• Aunque no se pueda instalar Wireshark, se puede capturar con pktmon y netsh trace, de serie en Windows. La forma básica es capturar con la herramienta de serie y leer con Wireshark en el propio equipo.
• pktmon son cuatro pasos: registro de filtro → pktmon start --capture → pktmon stop → pktmon etl2pcap. De forma predeterminada se recorta a 128 bytes, así que si se va a leer el contenido no olvide --pkt-size 0. Saber el punto de descarte y el motivo es un punto fuerte solo de pktmon.
• netsh trace captura agrupando proveedores ETW por escenario y, con persistent=yes, atraviesa un reinicio. El ETL se lee convertido a pcapng con etl2pcapng.
• En Wireshark se empieza a leer por tcp.analysis.flags y se busca la forma en el orden protocolo de enlace, RST, retransmisión y ZeroWindow. Es más rápido acotar tras una vista de conjunto con Conversations y el gráfico de E/S.
• Lo dirigido a localhost no pasa por la NIC, así que no se captura de forma habitual. Se usa el adaptador de bucle invertido de Npcap o la captura dentro de la pila de pktmon.
• Si se captura en ambos lados y se correlaciona, se fija «quién se calló». La premisa es la sincronización de reloj (w32tm). Un suceso cuya condición de reproducción se desconoce se espera con un búfer anular.
• Aunque sea TLS se ve el esqueleto de la comunicación. Sitúe el descifrado (SSLKEYLOGFILE) como un medio limitado al entorno de desarrollo, y trate el propio archivo de captura como confidencial, incorporando a la operación la captura al mínimo, el acotado y la eliminación.

La captura de paquetes tiende a verse como «herramienta de un especialista de red», pero en realidad es una herramienta de investigación del lado de la aplicación, que cobra sentido al correlacionarla con el log de la aplicación. La próxima vez que la investigación se detenga en la sola palabra “tiempo de espera agotado”, vaya a mirar un nivel más abajo.

Artículos relacionados

• Causa y aislamiento de que la comunicación de una cámara industrial se detenga por retransmisión TCP
• El malentendido de que se puede hacer Receive por cada unidad de Send en TCP — Diseño de recepción para tratarlo como un flujo de bytes
• Imaginar con claridad el modelo de referencia OSI — Diseccionar una solicitud HTTP en 7 capas
• Guía práctica de Process Monitor (ProcMon) — Identificar en 10 minutos «no se lee la configuración» y «ACCESS DENIED»
• El Firewall de Windows y las aplicaciones de negocio — Registrar las reglas de entrada desde el instalador
• Proxy interno de la empresa y aplicaciones de Windows — Cómo se resuelve el proxy en WinINET, WinHTTP y .NET

Ámbitos de consulta relacionados

En KomuraSoft LLC tratamos la investigación de fallos con origen en la comunicación, como «la comunicación de la aplicación de negocio falla a veces y no se sabe la causa» o «se quiere aislar un error de conexión que solo ocurre en el entorno del cliente». Respondemos en un solo hilo desde el diseño de la captura de paquetes (dónde, qué y cuánto capturar) hasta el análisis en Wireshark, la correlación con el log de la aplicación y la corrección en el lado de la aplicación.

• Desarrollo de aplicaciones Windows
• Investigación de fallos y análisis de causas
• Consulta técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Cómo puedo capturar paquetes en un servidor del cliente donde no se puede instalar Wireshark?

Con las herramientas de serie de Windows, pktmon o netsh trace, se puede capturar sin instalar software adicional. Con pktmon, registre un filtro en una terminal con privilegios de administrador, inicie la captura con pktmon start --capture y deténgala con pktmon stop. El archivo ETL obtenido se puede convertir a formato pcapng con pktmon etl2pcap, de modo que el análisis se hace con el Wireshark de su propio equipo, tras llevarse el archivo. Este reparto —capturar con la herramienta de serie y leer con Wireshark— es la forma básica en entornos con restricciones de instalación.

¿Debería usar pktmon o netsh trace?

Si el sistema operativo admite pktmon (Windows 10 / Windows Server 2019 o posterior), se recomienda empezar por pktmon. Sus comandos son sencillos, permite ver hasta qué componente de la pila de red descartó el paquete (el motivo de descarte) y la conversión a pcapng se completa por sí sola. netsh trace resulta ventajoso cuando se captura en un sistema operativo antiguo que no incluye pktmon, cuando se quieren reunir también los eventos ETW de los componentes de Windows en forma de escenario, o cuando se necesita capturar a lo largo de un reinicio con persistent=yes. La documentación de solución de problemas de Microsoft también recomienda este mismo orden: primero pktmon y, si no basta, netsh trace.

¿Por qué el tráfico dirigido a localhost (127.0.0.1) no aparece en Wireshark?

Porque el tráfico dirigido a localhost no pasa por la NIC física, sino que se devuelve por la ruta de bucle invertido interna del sistema operativo. No aparece desde el principio en una captura habitual dirigida al adaptador físico. En Wireshark puede capturar el tráfico de bucle invertido seleccionando el «Adapter for loopback traffic capture» que ofrece Npcap. Como pktmon captura dentro de la pila de red, también sirve para observar el tráfico de bucle invertido. Además, es habitual confundirse cuando «localhost» se resuelve a ::1 de IPv6 y no aparece nada en la pantalla que se está mirando pensando en 127.0.0.1, así que verifique especificando la dirección de forma explícita.

¿Se puede ver el contenido de una comunicación HTTPS (TLS) en la captura de paquetes?

El contenido de los datos de la aplicación está cifrado y no se puede ver. Sin embargo, el «esqueleto de la comunicación» —el establecimiento y cierre de la conexión TCP, el éxito o fracaso del protocolo de enlace TLS, el corte por RST, quién dejó de responder— se puede conocer aunque esté cifrado, por lo que la mayor parte de la investigación de tiempos de espera puede avanzar con TLS tal cual. Si además necesita el contenido, existe el descifrado mediante SSLKEYLOGFILE, pero solo lo admiten algunas implementaciones de TLS, como Firefox o la familia Chrome; el SChannel de serie de Windows no es compatible. Como es un mecanismo que vuelca información de clave secreta, considérelo limitado, en todo caso, al entorno de desarrollo.

¿Es seguro enviar el archivo de captura obtenido a un servicio de soporte externo?

Enviarlo tal cual es peligroso. La captura contiene el propio contenido de la comunicación y puede incluir credenciales de protocolos en texto claro, cookies, claves de API e información personal. Primero, en la fase de captura, acótela al mínimo necesario con filtros y un período limitado, y antes de entregarla, extraiga solo la comunicación de destino con el filtro de visualización de Wireshark y expórtela. Sobre lo que aún quede, debería decidir con el destinatario cómo tratar las partes confidenciales (enmascararlas, entregarlas por otro medio) antes de enviarlo. También se recomienda decidir de antemano el plazo de conservación y la eliminación de los archivos capturados.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.