Cattura dei pacchetti su Windows in pratica — scegliere tra pktmon, netsh trace e Wireshark

«La comunicazione server dell’applicazione di business fallisce alcune volte al mese. Il log dell’app dice solo “timeout”. Nel log lato server a quell’ora non c’è un errore corrispondente. Non sappiamo come riprodurlo» — nelle consulenze di indagine sui difetti questa forma torna di continuo.

Un log applicativo conserva solo ciò che l’app «ha deciso di scrivere». Vedete che il risultato era un timeout, ma se la richiesta di connessione (SYN) non ha avuto risposta, se la connessione si è stabilita e poi il server è rimasto in silenzio, se è stata tagliata con un RST, o se il pacchetto è arrivato a destinazione, vive uno strato sotto il log — nei pacchetti che sono realmente passati sul filo. Se Process Monitor è il modo di scendere di uno strato su file e registro, la cattura di pacchetti è il modo di scendere di uno strato sulla conversazione.

flowchart TB
    accTitle: I pacchetti uno strato sotto il log dell'app
    accDescr: Un log applicativo conserva solo ciò che l'app ha deciso di scrivere; se il SYN non ha avuto risposta, se c'è stato silenzio dopo il connect, se un RST ha tagliato o se il pacchetto è arrivato vive solo nei pacchetti realmente passati sul filo
    log["Log dell'app"] --> dec["Resta solo ciò che l'app ha deciso di scrivere"]
    dec --> to["Il risultato è un timeout di una parola"]
    to -->|scendere di uno strato| pkt["Pacchetti realmente passati sul filo"]
    pkt --> q1["Nessuna risposta al SYN?"]
    pkt --> q2["Silenzio dopo il connect?"]
    pkt --> q3["Tagliato con RST?"]
    pkt --> q4["È arrivato a destinazione?"]

Figura 1: Il log conserva solo il risultato; il dettaglio di un timeout vive solo nei pacchetti uno strato più in basso.

Il punto tipico in cui ci si blocca è il vincolo «non possiamo installare Wireshark sul server del cliente». I siti in cui il controllo delle modifiche o una policy di sicurezza non approvano software extra per un’indagine non sono rari. Windows, però, fornisce già due strumenti di cattura pacchetti: pktmon e netsh trace. Catturare con gli strumenti in dotazione del sistema, portare il file sul proprio PC e leggerlo in Wireshark — con questa divisione si vedono i pacchetti anche su un sito che vieta le installazioni.

Questo articolo è rivolto al personale IT di PMI e agli sviluppatori di app Windows. Organizza come scegliere tra pktmon, netsh trace e Wireshark e la procedura pratica di ciascuno. Trappole del traffico di loopback, se catturare sul client o sul server, come convivere con il TLS che nasconde il payload e la correlazione della cattura con il log dell’app sono trattati da fonti primarie aggiornate ad agosto 2026.

1. Prima la conclusione

• «Catturare con lo strumento in dotazione, leggere con Wireshark» è la divisione di base sul campo. Anche se non potete installare software sul server del cliente, pktmon e netsh trace sono in Windows. Convertite il log catturato in pcapng e analizzatelo in Wireshark sulla vostra macchina.¹²
• pktmon è lo strumento di cattura pacchetti in Windows 10 / Windows Server 2019 e successivi. Si usa in quattro passi — registrare un filtro, avviare, fermare, convertire — e il suo punto di forza è vedere quale componente dello stack di rete ha scartato il pacchetto (il motivo del drop).³⁴
• netsh trace è lo strumento in dotazione più vecchio; può attivare un insieme di provider ETW come «scenario». Oltre ai pacchetti tiene eventi interni ai componenti Windows, e con persistent=yes la cattura può sopravvivere a un riavvio.⁵⁶
• Entrambi gli strumenti scrivono ETL, che Wireshark non apre così com’è. Convertite in pcapng con pktmon etl2pcap per pktmon e con etl2pcapng, open source di Microsoft, per netsh trace.¹²
• Microsoft stesso indica «prima pktmon, poi netsh trace se non basta, e Wireshark per l’analisi di protocollo». La divisione di questo articolo segue quella raccomandazione ufficiale.⁷
• Di default pktmon registra solo i primi 128 byte di ogni pacchetto. Se intendete leggere il payload in Wireshark, non dimenticate --pkt-size 0 (registrare l’intero pacchetto) all’avvio.⁸
• Il traffico verso localhost non compare in una cattura normale. Non passa da una NIC. Usate l’adattatore di loopback Npcap in Wireshark, o la cattura nello stack di pktmon con gli strumenti in dotazione.⁹
• Anche quando TLS nasconde il payload si impara molto. Stabilimento della connessione, se l’handshake TLS è riuscito, RST e quale lato è rimasto in silenzio restano visibili anche cifrati. La decifrazione via SSLKEYLOGFILE è una tecnica solo per l’ambiente di sviluppo.¹⁰
• Una cattura contiene la comunicazione stessa. Partite dal fatto che può includere credenziali e dati personali, e inserite nella procedura la cattura minima necessaria e il restringimento prima della consegna.

2. I tre strumenti di cattura e come scegliere

Prima, una tabella unica dei ruoli dei tre strumenti.

In una frase, pktmon e netsh trace sono gli strumenti per «catturare», Wireshark è lo strumento per «leggere». Wireshark può anche catturare, ma non lo usate dove non potete installarlo. Al contrario, potete convertire l’ETL degli strumenti in dotazione in testo e leggerlo, ma fissarlo senza filtro di visualizzazione né analisi TCP è una pena. «Catturare sul posto con lo strumento in dotazione, convertire in pcapng e leggere in Wireshark sulla propria macchina» è il percorso più corto su un sito vincolato.

flowchart TB
    accTitle: Catturare con lo strumento in dotazione, leggere con Wireshark
    accDescr: Sul posto si cattura ETL con pktmon o netsh trace, si converte ciascuno in pcapng con il proprio strumento e si analizza in Wireshark sulla propria macchina
    pk["pktmon (in dotazione)"] --> etla["File ETL"]
    ns["netsh trace (in dotazione)"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["Analizzare in Wireshark sulla propria macchina"]

Figura 2: Sul posto si cattura ETL con gli strumenti in dotazione, si converte in pcapng e si legge in Wireshark sulla propria macchina.

La guida Microsoft sull’indagine della perdita di pacchetti ha la stessa forma: catturare e isolare la causa prima con pktmon, poi passare a tracce a livello di componente come netsh trace start scenario=InternetClient se non basta, e analizzare il comportamento di protocollo in Wireshark.⁷

Come premessa per leggere ciò che un pacchetto mostra davvero, aiuta anche un’immagine degli strati impilati — Ethernet, IP, TCP, dati applicativi. L’anatomia degli strati è illustrata in «Capire davvero il modello OSI».

3. pktmon in pratica — Filtro, avvio, stop, conversione

Il flusso di base di pktmon è in quattro passi. Eseguiteli in un terminale con privilegi elevati.

:: 1. Registrare prima un filtro per restringere il bersaglio (TCP 8443 sul server 192.168.10.20)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. Avviare la cattura. Registrare i pacchetti interi, sovrascrivere in un buffer circolare da 1 GB
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. Riprodurre l'incidente. Nell'attesa si possono controllare volume e scarti con counters
pktmon counters --drop-reason

:: 4. Fermare, poi convertire in pcapng per Wireshark
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. Pulire il filtro registrato (i filtri restano finché non si rimuovono esplicitamente).
::    Nota: filter remove non accetta un nome; elimina «tutti» i filtri registrati.
::    Su una macchina che può ancora avere filtri di un'altra indagine, controllare prima con pktmon filter list
pktmon filter remove

flowchart TB
    accTitle: Procedura di base di pktmon
    accDescr: Restringere il bersaglio con un filtro, avviare la cattura, riprodurre l'incidente, fermare, convertire in pcapng con etl2pcap e infine togliere il filtro registrato
    fa["1. Restringere il bersaglio con filter add"] --> st["2. Avviare la cattura con start --capture"]
    st --> re["3. Riprodurre l'incidente"]
    re -.-> ct["Controllare volume e drop con counters"]
    re --> sp["4. Fermare"]
    sp --> cv["Convertire in pcapng con etl2pcap"]
    cv --> rm["5. Pulire con filter remove"]

Figura 3: pktmon parte dalla registrazione del filtro, poi cattura, stop e conversione, e il filtro si toglie esplicitamente alla fine.

Punti da tenere a mente:

• Registrate i filtri prima di avviare la cattura. Anche la documentazione Microsoft raccomanda con forza di applicare un filtro prima di avviare, perché catturare tutto il traffico è troppo rumoroso. I filtri possono specificare indirizzo IP, porta, indirizzo MAC, protocollo, ID VLAN e così via, e se ne possono registrare fino a 32. Più filtri sono un OR: un pacchetto viene registrato se corrisponde a uno qualsiasi.³
• Un filtro pktmon non distingue origine e destinazione. -i 192.168.10.20 significa «pacchetti in cui questo indirizzo è origine o destinazione». Restringete la direzione dopo con un filtro di visualizzazione Wireshark dopo la conversione.³
• La dimensione predefinita del pacchetto è 128 byte. Basta per l’analisi delle intestazioni, ma se volete anche i dati applicativi registrate l’intero pacchetto con --pkt-size 0.⁸
• Il log è di default in modalità circular (buffer ad anello), dimensione predefinita 512 MB. Potete cambiare il tetto con --file-size, e --log-mode real-time stampa a schermo in tempo reale e non crea un file di log. Confermate prima in tempo reale di vedere davvero il traffico che vi interessa, poi impostate la cattura di produzione, e evitate una ripresa vuota.⁸

flowchart TB
    accTitle: Come agiscono i filtri pktmon
    accDescr: Più filtri registrati registrano su corrispondenza OR, l'indirizzo specificato non distingue origine e destinazione, e la direzione si restringe dopo con un filtro di visualizzazione Wireshark dopo la conversione
    f1["Filtro 1"] --> orc["Registra se uno corrisponde"]
    f2["Filtro 2"] --> orc
    f3["Filtro 3 (fino a 32)"] --> orc
    orc --> rec["Registrato nel log di cattura (OR)"]
    rec -.-> nodir["Origine e destinazione non distinte"]
    nodir -.-> ws["Restringere la direzione in Wireshark dopo la conversione"]

Figura 4: Più filtri funzionano come OR, e se un host è origine o destinazione si restringe in Wireshark dopo la conversione.

3.1. Ciò che solo pktmon può fare — vedere dove un pacchetto è stato scartato

Il valore distintivo di pktmon rispetto a Wireshark è che cattura un pacchetto in più punti dentro lo stack di rete, non su una sola NIC, e può riferire dove e perché è stato scartato (dropped). Poiché vedete quale componente un pacchetto ha raggiunto e dove è scomparso, motivi di drop come «disallineamento MTU» o «filtro VLAN» vi portano alla causa senza una ricerca a forza bruta.⁴

flowchart TB
    accTitle: pktmon cattura in più punti nello stack
    accDescr: pktmon cattura un pacchetto in più punti nello stack di rete anziché su una sola NIC, quindi può riferire con un motivo quale componente il pacchetto ha raggiunto e dove è stato scartato
    pin["Pacchetto"] --> p1["Catturato al punto 1"]
    p1 --> p2["Catturato al punto 2"]
    p2 --> p3["Scartato al punto 3"]
    p3 -.-> rz["Riferisce luogo e motivo del drop"]
    rz -.-> ex["es. disallineamento MTU o filtro VLAN"]

Figura 5: Catturare in più punti nello stack dice fino a dove è arrivato un pacchetto e dove è stato droppato, con un motivo.

• pktmon list mostra i componenti di rete monitorabili (NIC, stack di protocollo, driver di filtro e così via) e i loro ID.
• pktmon counters --drop-reason elenca i contatori di passaggio/drop per componente e il motivo di drop più recente. Comodo come primo taglio prima di analizzare il log.¹¹
• Convertite in testo con pktmon etl2txt e i pacchetti scartati escono con drop e un dropReason.³

Il sospetto che «qualcosa nel sistema sta droppando questo prima che raggiunga l’app» non si chiude fissando solo Wireshark. Questa capacità aiuta, per esempio, a isolare un caso in cui il firewall droppa perché manca una regola in ingresso («Il firewall di Windows e le applicazioni di business»).

Un avvertimento. pktmon registra lo stesso pacchetto in più punti dello stack, quindi convertire così com’è in pcapng può far comparire lo stesso pacchetto più di una volta. pcapng non porta «quale componente ha catturato questo», quindi se leggete in Wireshark la mossa standard è convertire con --component-id per scegliere un punto (o mettere i drop da soli in un file separato con --drop-only).¹

flowchart TB
    accTitle: Perché lo stesso pacchetto può comparire due volte dopo la conversione pcapng
    accDescr: pktmon registra lo stesso pacchetto in più punti dello stack, pcapng non tiene quale componente l'ha catturato quindi possono comparire duplicati, e la mossa standard è convertire dopo aver ristretto il punto con component-id o messo i drop da soli in un file drop-only
    same["Stesso pacchetto registrato in più punti"] --> conv["Convertire in pcapng così com'è"]
    conv --> lost["L'informazione del punto di cattura non viene portata"]
    lost --> dup["Lo stesso pacchetto compare più di una volta"]
    dup --> c1["Restringere il punto con --component-id"]
    dup --> c2["File separato con --drop-only"]

Figura 6: L’informazione del punto di cattura non passa in pcapng, quindi la mossa standard è restringere il punto prima di convertire.

4. netsh trace in pratica — Scenari, ETL e catture che sopravvivono a un riavvio

netsh trace è il meccanismo di traccia presente in Windows da prima di pktmon. La sua caratteristica è che come «scenario» può attivare in una volta l’intero insieme di provider ETW legati a quel problema.⁶

:: List available scenarios and inspect the providers in a scenario
netsh trace show scenarios
netsh trace show scenario netconnection

:: Start the capture. Packet capture included, 1GB circular buffer
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: Reproduce the incident, then stop (the merge takes a little time)
netsh trace stop

• Aggiungete capture=yes per abilitare la cattura di pacchetti e restringete il bersaglio con un filtro di cattura come ipv4.address=192.168.10.20. L’elenco dei filtri è in netsh trace show capturefilterHelp.⁶
• Fermando si ottiene un file .cab oltre all’ETL. Il .cab contiene informazioni di sistema come configurazione degli adattatori e build del sistema, quindi serve anche da raccolta ambiente.⁶
• Può girare una sola sessione di traccia alla volta. Prima di avviare un’altra cattura, controllate con netsh trace show status che non sia rimasta una sessione in esecuzione.⁶
• Aggiungete persistent=yes e la sessione sopravvive a un riavvio. Catturare «la comunicazione fallisce per un attimo subito dopo il riavvio» o «la connessione del servizio all’avvio fallisce» — incidenti che non si riesce ad avviare in tempo a mano — è il terreno unico di netsh trace.⁵

flowchart TB
    accTitle: Catturare uno scenario netsh trace
    accDescr: Avviare con uno scenario abilita un insieme di provider ETW, capture=yes cattura anche i pacchetti, e fermare produce un file ETL e un file .cab
    sc["Avviare con uno scenario"] --> pv["Abilitare l'insieme di provider"]
    sc -->|capture=yes| pc["Vengono catturati anche i pacchetti"]
    pv --> re["Riprodurre l'incidente"]
    pc --> re
    re --> sp["Fermare"]
    sp --> etl["File ETL"]
    sp --> cab[".cab (informazioni di sistema)"]

Figura 7: Avviare con uno scenario abilita un insieme di provider, e fermare produce ETL e un .cab.

4.1. Rendere l’ETL leggibile in Wireshark — etl2pcapng

L’ETL di netsh trace non si apre così com’è in Wireshark. etl2pcapng, lo strumento open source che Microsoft pubblica su GitHub, converte in pcapng i pacchetti di un ETL catturato con netsh trace start capture=yes.²

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

In conversione etl2pcapng scrive l’ID di processo coinvolto con ciascun pacchetto come commento del pacchetto. Potere vedere in Wireshark «di quale processo è questo traffico» aiuta quando più app sullo stesso server comunicano.²

Il lato eventi ETW (eventi interni Windows registrati dai provider dello scenario) non viene convertito in pcapng. Se volete anche gli eventi, convertite in testo o simile con netsh trace convert input=C:\temp\nettrace.etl, oppure aprite l’ETL in Windows Performance Analyzer.⁵⁷

flowchart TB
    accTitle: Leggere l'ETL di netsh trace si divide in due percorsi
    accDescr: I pacchetti nell'ETL si convertono in pcapng con etl2pcapng e si leggono in Wireshark; gli eventi ETW non si convertono in pcapng, quindi si leggono con netsh trace convert o Windows Performance Analyzer
    etl["ETL netsh trace"] --> pk["Pacchetti"]
    etl --> ev["Eventi ETW"]
    pk -->|etl2pcapng| pc["Convertire in pcapng"]
    pc --> ws["Leggere in Wireshark"]
    pc -.-> pid["L'ID di processo resta come commento"]
    ev -.-> no["Non convertito in pcapng"]
    no --> alt["Leggere con convert o WPA"]

Figura 8: Dell’ETL i pacchetti si convertono in pcapng per essere letti; gli eventi ETW si leggono in un altro modo.

5. Un primo sguardo alla lettura in Wireshark — Filtri di visualizzazione e analisi TCP

Aperto il pcapng, prima tagliate il rumore con un filtro di visualizzazione. Quelli comuni sono in tabella.¹²¹³

tcp.analysis.* sono flag di analisi che Wireshark assegna seguendo i numeri di sequenza TCP. Ritrasmissioni, ACK duplicati, fuori ordine, ZeroWindow e simili vengono presi in modo meccanico, quindi il modo standard di iniziare a leggere è digitare prima tcp.analysis.flags e elencare i punti «che sembrano un problema».¹³

In un’indagine di timeout cercate le forme seguenti in ordine.

1. L’handshake a tre vie è completo? Ci sono tutti e tre i pacchetti SYN → SYN/ACK → ACK? Se il SYN si ripete senza risposta, non è mai arrivato al peer, o è stato scartato in silenzio in mezzo (il tipico schema del firewall).
2. Quale lato ha inviato l’RST? Un RST immediato al SYN significa che nessuno ascolta sulla porta di destinazione; un RST dopo la connessione stabilita significa che un lato ha forzato il taglio. L’IP di origine dell’RST è la prova diretta di «chi ha tagliato».
3. Le ritrasmissioni continuano? La ritrasmissione ripetuta dello stesso segmento è il segno che l’acknowledgement (ACK) non sta tornando al mittente. Se i dati in uscita sono andati persi o è andato perso l’ACK di ritorno non si chiude da una cattura unilaterale (per questo nel capitolo successivo conta «catturare su entrambi i lati»). Ritrasmissioni e timeout sono approfonditi in «Perché le ritrasmissioni TCP bloccano la comunicazione con telecamere industriali».
4. C’è ZeroWindow? È il segno che l’app ricevente non sta leggendo dal socket e il buffer di ricezione è pieno. È motivo di sospettare il progetto dell’app ricevente («L’equivoco che TCP permetta di ricevere nelle stesse unità in cui si invia») piuttosto che la rete.

flowchart TB
    accTitle: Ordine delle forme da cercare in un'indagine di timeout
    accDescr: Confermare il completamento dell'handshake a tre vie, presenza e origine dell'RST, ritrasmissioni che continuano, poi ZeroWindow, per mettere un primo segno sulla causa
    hs{"Il SYN ha avuto risposta?"} -->|no| ng["Non è mai arrivato（Firewall tipico）"]
    hs -->|sì| rs{"C'è un RST?"}
    rs -->|sì| who["L'origine dell'RST ha tagliato"]
    rs -->|no| rt{"Le ritrasmissioni continuano?"}
    rt -->|sì| ack["L'ACK non sta tornando"]
    rt -->|no| zw{"C'è ZeroWindow?"}
    zw -->|sì| app["Il ricevitore non sta leggendo"]

Figura 9: Cercare handshake, RST, ritrasmissione, poi ZeroWindow in quest’ordine restringe dove guardare dopo.

Prima di leggere i pacchetti uno per uno, aiuta anche prendere il quadro con le funzioni di statistica. [Statistics] → [Conversations] è un elenco di «quale coppia IP / porta ha parlato, da quando a quando, quanto», così identificate la conversazione che vi interessa e filtrate solo quella. [Statistics] → [I/O Graph] è un grafico di volume nel tempo; forme come «da quest’ora un verso è rimasto in silenzio» saltano all’occhio. Clic destro sulla conversazione TCP di interesse e [Follow] → [TCP Stream] per leggere lo scambio di quella connessione in chiaro.

flowchart TB
    accTitle: Prendere il quadro con le statistiche, poi restringere a una conversazione
    accDescr: Elencare quali conversazioni hanno parlato quando e quanto in Conversations, prendere l'intervallo di silenzio dall'I/O Graph, filtrare la conversazione di interesse e leggerla come flusso TCP
    ov["Prendere il quadro intero con le statistiche"] --> cv["Elenco conversazioni in Conversations"]
    ov --> io["Vedere il volume sull'I/O Graph"]
    cv --> flt["Filtrare la conversazione di interesse"]
    io -.-> mute["L'intervallo di silenzio diventa visibile"]
    flt --> fs["Leggere come flusso TCP"]

Figura 10: Prima di leggere pacchetto per pacchetto, prendete il quadro con le statistiche, restringete alla conversazione di interesse, poi leggetela tutta.

6. La trappola del loopback — il traffico verso localhost non passa mai da una NIC

Cercare di indagare la comunicazione tra app sullo stesso PC — per esempio un’app di business che si collega a un servizio intermedio su localhost:8080 — e bloccarsi su «in Wireshark non compare nulla» è una trappola classica.

La causa è chiara. Il traffico verso localhost (127.0.0.1) non passa mai da una NIC fisica; viene girato sul percorso di loopback interno del sistema. Una cattura normale che punta a un adattatore fisico quindi non lo vede.⁹

flowchart TB
    accTitle: Perché il traffico verso localhost non compare in una cattura
    accDescr: Il traffico verso localhost non passa mai da una NIC fisica e viene girato sul percorso di loopback interno del sistema, quindi non compare in una cattura normale che punta a un adattatore fisico
    app["App"] --> stack["Stack di rete"]
    stack -->|esterno| nic["NIC fisica"]
    nic --> seen["Visto in una cattura normale"]
    stack -->|localhost| lo["Girato nel sistema"]
    lo -.-> miss["Non in una cattura normale"]
    lo -.-> alt["Loopback Npcap o pktmon"]

Figura 11: Il traffico verso localhost viene girato prima della NIC, una cattura sull’adattatore fisico non lo vede.

Ci sono due modi di affrontarlo.

• Quando catturate in Wireshark: Scegliete l’«Adapter for loopback traffic capture» di Npcap come bersaglio di cattura. L’installer Windows di Wireshark (3.0 e successivi) include Npcap, quindi se Wireshark è già installato lo usate senza lavoro extra.⁹
• Quando catturate con gli strumenti in dotazione: pktmon cattura in più punti dentro lo stack di rete anziché fuori dalla NIC⁴, quindi può osservare anche il traffico di loopback. Per essere sicuri, prima di impostare un’attesa di riproduzione in produzione, confermate su quella macchina con la visualizzazione in tempo reale pktmon start -c -m real-time che il traffico di loopback che vi interessa è davvero visibile.

Attenzione anche a due scambi.

• «localhost» può risolversi in IPv6 ::1. L’app si collega a IPv6 ::1, ma l’investigatore guarda solo 127.0.0.1 (IPv4) e conclude a torto «non c’è traffico». Allargate il filtro di visualizzazione a entrambi, come in ip.addr == 127.0.0.1 || ipv6.addr == ::1, oppure rendete l’impostazione di destinazione dell’app un indirizzo esplicito.⁹
• Anche il traffico verso il proprio IP reale non va sul filo. Quando lo stesso PC si collega da 192.168.10.5 a 192.168.10.5, la destinazione è un IP reale ma il sistema lo gira comunque internamente. Ricordate che «ho specificato un IP reale, quindi passa dalla NIC» non è garantito.

flowchart TB
    accTitle: Lo scambio quando localhost si risolve in IPv6
    accDescr: Il localhost di un'app può risolversi in IPv6 ::1, e se l'investigatore guarda solo 127.0.0.1 conclude a torto che non c'è traffico, quindi allargate il filtro di visualizzazione a entrambi gli indirizzi o confermate la destinazione come indirizzo esplicito
    app["L'app si collega a localhost"] --> v6["In realtà si risolve in ::1 (IPv6)"]
    look["L'investigatore guarda solo 127.0.0.1"] --> none["Niente compare sullo schermo"]
    v6 --> none
    none --> fix1["Allargare il filtro a entrambi gli indirizzi"]
    none --> fix2["Rendere la destinazione un indirizzo esplicito"]

Figura 12: Attenzione allo scambio in cui localhost si risolve in ::1 e guardare solo 127.0.0.1 porta a «non c’è traffico».

7. Dove catturare — un lato, entrambi i lati e sincronizzazione degli orologi

Il valore di una cattura lo decide «dove avete catturato». La regola empirica è la seguente.

Una cattura unilaterale dice solo «i fatti visti dalla mia posizione». Ritrasmissioni che continuano sul client non distinguono se il pacchetto inviato è scomparso sul percorso, o è arrivato al server e la risposta è scomparsa. Catturare su entrambi i lati e allinearli chiude «il client l’ha inviato / il server non l’ha mai ricevuto» — quale lato è rimasto in silenzio. Quando dovete chiudere il confine di responsabilità (l’app, il sistema, un dispositivo di rete o l’altra estremità), vale la pena allestire da subito una cattura su entrambi i lati.

flowchart TB
    accTitle: Cosa dicono le catture unilaterale e bilaterale
    accDescr: Una cattura unilaterale non distingue se è scomparso il pacchetto in uscita o la risposta di ritorno; catturare su entrambi i lati e allinearli chiude quale lato è rimasto in silenzio
    one["Catturare su un lato"] --> fact["Fatti dal vostro lato"]
    fact --> und["In uscita o di ritorno?"]
    both["Catturare su entrambi i lati"] --> mt["Allinearli"]
    mt --> fix["Quale lato è rimasto in silenzio"]
    mt -.-> pre["Serve sincronizzazione degli orologi"]

Figura 13: Un solo lato mostra i fatti che avete visto; allineare entrambi i lati è ciò che per primo chiude il confine di responsabilità.

7.1. La premessa della correlazione è la sincronizzazione degli orologi

Per allineare catture da entrambi i lati, gli orologi delle due macchine devono concordare. Prima di avviare la cattura, controllate e annotate lo scostamento di orologio.

:: Check time-sync status (sync source, last sync time)
w32tm /query /status

:: Measure the offset against the peer server (5 samples)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchart è il comando che mostra lo scostamento di tempo tra voi e il computer peer, e diventa il fondamento di una correzione come «l’orologio del server era a +0,8 secondi» quando allineate le catture.¹⁴ In un ambiente con uno scostamento grande, sistemare prima la sincronizzazione del tempo e poi catturare è il percorso più corto alla fine.

flowchart TB
    accTitle: Procedura per controllare lo scostamento di orologio prima della correlazione
    accDescr: Confermare il proprio stato di sincronizzazione con w32tm, misurare e annotare lo scostamento rispetto al server peer con stripchart, usare quello scostamento come fondamento di correzione all'allineamento, e se lo scostamento è grande sistemare prima la sincronizzazione e poi catturare
    st["Controllare lo stato di sync con query"] --> mc["Misurare lo scostamento con stripchart"]
    mc --> rc["Annotare lo scostamento"]
    rc --> use["Fondamento di correzione al momento della correlazione"]
    mc -.-> big["Se lo scostamento è grande, sistemare prima la sync"]

Figura 14: Misurate e annotate lo scostamento di orologio prima di catturare, e usatelo come fondamento di correzione quando allineate le catture.

7.2. Per «non sappiamo quando succederà» — un buffer ad anello

Per un incidente le cui condizioni di riproduzione sono sconosciute, la mossa di base è lasciare un buffer ad anello in esecuzione e fermarlo quando l’incidente avviene.

• pktmon: Il default è la modalità circular. Impostate il tetto (MB) con --file-size; i pacchetti più vecchi vengono sovrascritti.⁸
• netsh trace: Specificatelo come maxSize=1024 filemode=circular.⁵
• Wireshark: In [Capture] → [Options] → [Output] potete configurare «più file + buffer ad anello». Ruota per dimensione file o tempo e tiene solo gli ultimi N file, quindi potete girare a lungo con un tetto di uso disco.¹⁵

In ogni caso, condividete con la persona sul posto la regola che quando l’incidente avviene, «annotate prima l’ora, poi» fermate la cattura. Un buffer ad anello cancella il passato più aspettate, quindi se il percorso dall’occorrenza allo stop è lungo, l’intervallo che vi interessa viene sovrascritto.

flowchart TB
    accTitle: Attendere con una cattura a buffer ad anello
    accDescr: Per un incidente le cui condizioni di riproduzione sono sconosciute, lasciare un buffer ad anello in esecuzione e, quando l'incidente avviene, annotare l'ora e fermare in fretta; uno stop tardivo sovrascrive i pacchetti più vecchi e l'intervallo di interesse scompare
    st["Avviare una cattura a buffer ad anello"] --> wt["Lasciarla girare e attendere"]
    wt --> ev["L'incidente avviene"]
    ev --> memo["Annotare l'ora"]
    memo --> sp["Fermare in fretta"]
    wt -.-> ow["I pacchetti più vecchi vengono sovrascritti"]
    ow -.-> late["Uno stop tardivo cancella l'intervallo di interesse"]

Figura 15: Un buffer ad anello cancella il passato più aspettate, quindi una volta annotata l’ora fermate in fretta.

8. Il problema che TLS nasconde il payload — ciò che si vede ancora

Gran parte del traffico di business oggi è TLS (HTTPS). Si tende a pensare «se è cifrato, catturare non serve», ma gran parte di ciò che volete in un’indagine di timeout resta visibile con la cifratura lasciata al suo posto.

• Se la connessione TCP si è stabilita (handshake a tre vie)
• Fino a dove è arrivato l’handshake TLS — se ServerHello è tornato a ClientHello, se è stato tagliato con un RST o un alert durante l’handshake
• Il nome host di destinazione su ClientHello (SNI) e la versione TLS negoziata
• Dopo la connessione in piedi, quale lato ha smesso di inviare. Il luogo del silenzio, ritrasmissioni, RST, o una chiusura pulita (FIN)

In altre parole, isolare «non si connette», «si interrompe a metà» e «non torna nessuna risposta» quasi mai richiede la decifrazione del payload. Ciò che la cifratura perde è «cosa hanno detto»; «chi è rimasto in silenzio, e quando» resta.

flowchart TB
    accTitle: Cosa una cattura TLS può e non può mostrare
    accDescr: La cifratura nasconde solo il payload dei dati applicativi; stabilimento della connessione TCP, successo o fallimento dell'handshake TLS, SNI e versione TLS, RST, e quale lato è rimasto in silenzio restano visibili con la cifratura lasciata al suo posto
    tls["Cattura di traffico TLS"] --> vis["Visibile"]
    tls --> hid["Non visibile"]
    vis --> v1["Stabilimento connessione TCP"]
    vis --> v2["Esito TLS e SNI"]
    vis --> v3["RST / chi è rimasto in silenzio"]
    hid --> h1["Payload dei dati applicativi"]

Figura 16: La cifratura perde solo il payload; lo scheletro della conversazione si legge ancora con TLS lasciato al suo posto.

Quando serve ancora il payload, Wireshark può decifrare TLS usando le chiavi di sessione scritte tramite la variabile d’ambiente SSLKEYLOGFILE. Il supporto è limitato ad alcune implementazioni come Firefox, Chrome, Edge basato su Chromium e librerie della famiglia OpenSSL; lo SChannel in dotazione di Windows (app che usano WinHTTP o WinINET) non supporta questo meccanismo.¹⁰ Poiché «la chiave di sessione è scritta su un file» significa che chi ha quel file può decifrare l’intera conversazione, non è una tecnica di produzione; trattatela come riproduzione e debug in un ambiente di sviluppo.

flowchart TB
    accTitle: Come funziona la decifrazione SSLKEYLOGFILE e i suoi limiti
    accDescr: Le chiavi di sessione scritte via SSLKEYLOGFILE permettono a Wireshark di decifrare TLS, ma solo alcune implementazioni come Firefox e la famiglia Chrome lo supportano e SChannel no; chi ha il file delle chiavi può decifrare la conversazione, quindi trattatela come tecnica solo per l'ambiente di sviluppo
    env["Impostare SSLKEYLOGFILE"] --> key["Scrivere le chiavi di sessione"]
    key --> ws["Leggere in Wireshark"]
    key -.-> risk["Chi ha la chiave può decifrare"]
    risk -.-> dev["Solo sviluppo"]
    env -.-> sup["Solo alcuni stack TLS"]
    sup -.-> sch["SChannel: nessun supporto"]

Figura 17: Scrivere le chiavi di sessione può decifrare, ma le implementazioni supportate sono limitate, e la natura della chiave ne fa una tecnica solo per l’ambiente di sviluppo.

Quando il traffico passa da un proxy interno, la destinazione che compare nella cattura è il server proxy, e TLS scorre in un tunnel CONNECT. La domanda precedente di verso quale proxy sta andando l’app è organizzata nell’articolo compagno dello stesso giorno «Proxy aziendali e app Windows — mettere in ordine la risoluzione del proxy in WinINET, WinHTTP e .NET».

9. Correlare con il log dell’app — mettere il tempo sullo stesso asse

Una cattura da sola produce raramente la conclusione. La mossa decisiva in pratica è mettere una riga del log dell’app e un andata-e-ritorno di pacchetti sullo stesso asse temporale.

La procedura è questa.

1. Identificate l’ora dell’incidente dal log dell’app (per esempio, un’eccezione di timeout alle 10:23:41). Se il valore di timeout è 30 secondi, l’inizio dovrebbe essere intorno alle 10:23:11.
2. Passate la visualizzazione dell’ora di Wireshark a [View] → [Time Display Format] → [Date and Time of Day], e restringete l’intervallo con un filtro di visualizzazione (potete anche filtrare per ora, come in frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00").
3. In quell’intervallo confermate l’ordine del capitolo 5 (handshake → RST → ritrasmissione → ZeroWindow). Se riuscite ad allineare fino a «30 secondi prima dell’ora di timeout del log è stato inviato un SYN, e dopo solo ritrasmissioni di SYN», il «timeout» del log è sostituito dall’osservazione «a questo punto di cattura non è tornata nessuna risposta» (se il SYN non è mai arrivato al peer, o se il SYN/ACK di ritorno è andato perso sulla via del ritorno, non si chiude da questo solo punto di cattura. Se dovete chiuderlo, catturate sul server e allineatele).
4. Correggete sempre lo scostamento tra ora di cattura e ora del log (lo scostamento di orologio misurato nella sezione 7.1 e la notazione del fuso del log). Qualche secondo di errore di correlazione inchioda la conversazione sbagliata come colpevole.

flowchart TB
    accTitle: Procedura per allineare il log dell'app e i pacchetti
    accDescr: Identificare l'ora dell'incidente dal log dell'app, risalire l'ora di inizio dal valore di timeout, restringere l'intervallo in Wireshark con un filtro di visualizzazione, confermare le forme in ordine, correggere lo scostamento di orologio e metterli sullo stesso asse temporale
    lg["1. Identificare l'ora dell'incidente dal log"] --> rev["Risalire l'inizio dal valore di timeout"]
    rev --> flt["2. Restringere l'intervallo con un filtro di visualizzazione"]
    flt --> chk["3. Confermare le forme nell'ordine del capitolo 5"]
    chk --> adj["4. Correggere lo scostamento di orologio"]
    adj --> done["La parola del log diventa un'osservazione"]

Figura 18: Restringete l’intervallo dall’ora del log, confermate la forma, correggete lo scostamento di orologio e metteteli sullo stesso asse.

Quando consegnate i risultati dell’indagine a terzi (un fornitore, un operatore, il personale di rete del cliente), tagliare il rumore con un filtro prima di consegnare è cortesia e misura di sicurezza. In Wireshark restringete alla conversazione di interesse con un filtro di visualizzazione e salvate «solo i pacchetti visualizzati» con [File] → [Export Specified Packets], e ottenete un pcapng piccolo solo dell’intervallo che vi serve.

Infine, una cautela di trattamento. Un file di cattura contiene la comunicazione stessa. Può includere credenziali di protocolli in chiaro, cookie HTTP e chiavi API, il contenuto di posta o report e dati personali. Decidete i tre punti seguenti come insieme con la procedura di cattura.

• Cattura minima necessaria: Restringete il bersaglio con i filtri pre-cattura (capitoli 3 e 4) e tenete la finestra temporale il più breve possibile. Non fate «catturiamo tutto» su un ambiente cliente
• Restringere prima di consegnare: Esportate solo la conversazione di interesse; non includete traffico di terzi non correlato. Se restano parti sensibili, accordatevi con il destinatario su mascheramento o un’altra via
• Conservazione ed eliminazione: Decidete dove i file di cattura restano, per quanto e quando vengono eliminati, ed eliminate quando l’indagine è finita

flowchart TB
    accTitle: Tre decisioni da prendere prima di consegnare un file di cattura
    accDescr: Una cattura contiene la comunicazione stessa, quindi decidete come insieme con la procedura di cattura di restringere al minimo con filtri pre-cattura e una finestra temporale, estrarre solo la conversazione di interesse prima della consegna così il traffico non correlato non è incluso, e decidere luogo e durata di conservazione ed eliminare dopo l'indagine
    cap["Cattura = il traffico"] --> p1["Catturare il minimo"]
    cap --> p2["Estrarre prima il bersaglio"]
    cap --> p3["Impostare la conservazione, eliminare"]
    p2 -.-> exp["Filtrare ed esportare"]

Figura 19: Decidete cattura minima, restringimento prima della consegna, e conservazione ed eliminazione come insieme con la procedura di cattura.

10. Sintesi

• Uno strato sotto il «timeout» del log dell’app c’è il fatto dei pacchetti realmente passati sul filo. Se il SYN non ha avuto risposta, un RST ha tagliato, le ritrasmissioni sono continuate o è comparso ZeroWindow cambia dove guardate dopo.
• Anche su un sito dove non potete installare Wireshark potete catturare con pktmon e netsh trace in Windows. Catturare con lo strumento in dotazione, leggere con Wireshark sulla propria macchina — quella divisione è la forma di base.
• pktmon è in quattro passi: registrare un filtro → pktmon start --capture → pktmon stop → pktmon etl2pcap. Di default è troncato a 128 byte, quindi se volete il payload non dimenticate --pkt-size 0. Vedere luogo e motivo del drop è un punto di forza che ha solo pktmon.
• netsh trace cattura un insieme di provider ETW come scenario, e con persistent=yes può sopravvivere a un riavvio. Convertite l’ETL in pcapng con etl2pcapng per leggerlo.
• In Wireshark partite da tcp.analysis.flags e cercate handshake, RST, ritrasmissione e ZeroWindow in quest’ordine. È più veloce se prima prendete il quadro con Conversations e l’I/O Graph, poi restringete.
• Il traffico verso localhost non passa mai da una NIC, non lo catturate nel modo ordinario. Usate l’adattatore di loopback Npcap o la cattura nello stack di pktmon.
• Catturare su entrambi i lati e allinearli chiude «quale lato è rimasto in silenzio». La premessa è la sincronizzazione degli orologi (w32tm). Per un incidente le cui condizioni di riproduzione sono sconosciute, attendete con un buffer ad anello.
• Anche sotto TLS lo scheletro della conversazione è visibile. Trattate la decifrazione (SSLKEYLOGFILE) come tecnica solo per l’ambiente di sviluppo, e il file di cattura stesso come riservato: inserite cattura minima, restringimento ed eliminazione nell’esercizio.

La cattura di pacchetti è spesso pensata come «strumento dello specialista di rete», ma in pratica è uno strumento di indagine lato app che inizia a significare qualcosa solo quando lo allineate con il log dell’app. La prossima volta che un’indagine si ferma alla sola parola «timeout», andate a guardare uno strato più in basso.

Articoli correlati

• Perché le ritrasmissioni TCP bloccano la comunicazione con telecamere industriali, e come isolarle
• L’equivoco che TCP permetta di ricevere nelle stesse unità in cui si invia — progettare la ricezione come flusso di byte
• Capire davvero il modello OSI — sezionare una singola richiesta HTTP nei suoi sette livelli
• Guida pratica a Process Monitor (ProcMon) — Individuare in 10 minuti “la configurazione non viene letta” e “ACCESS DENIED”
• Il firewall di Windows e le applicazioni di business — registrare le regole in ingresso dall’installer
• Proxy aziendali e app Windows — mettere in ordine la risoluzione del proxy in WinINET, WinHTTP e .NET

Aree di consulenza correlate

KomuraSoft LLC gestisce indagini su difetti di origine comunicativa come «la comunicazione dell’app di business fallisce di tanto in tanto e non troviamo la causa» e «vogliamo isolare un errore di connessione che avviene solo sull’ambiente del cliente». Prendiamo la progettazione della cattura (dove, cosa e quanto catturare), l’analisi Wireshark, la correlazione con il log dell’app e la correzione lato app come un unico lavoro continuo.

• Sviluppo di app Windows
• Indagine sui difetti e analisi delle cause
• Consulenza tecnica e revisione della progettazione
• Contattaci

Riferimenti

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Come catturo i pacchetti su un server del cliente dove non posso installare Wireshark?

Usate gli strumenti già in Windows, pktmon o netsh trace, e catturate senza installare altro software. Con pktmon, registrate un filtro in un terminale con privilegi elevati, avviate la cattura con pktmon start --capture e fermate con pktmon stop. Il file ETL ottenuto si converte in pcapng con pktmon etl2pcap, così l'analisi torna su Wireshark sulla vostra macchina. «Catturare con lo strumento in dotazione, leggere con Wireshark» è la divisione di base sui siti che limitano le installazioni.

Devo usare pktmon o netsh trace?

Se il sistema ha pktmon (Windows 10 / Windows Server 2019 e successivi), partite da pktmon. I comandi sono semplici, vedete quale componente dello stack di rete ha scartato il pacchetto (il motivo del drop) e la conversione pcapng è autonoma. netsh trace è la scelta migliore quando catturate su un OS più vecchio senza pktmon, quando volete raccogliere eventi ETW dei componenti Windows come scenario, o quando volete che la cattura sopravviva a un riavvio con persistent=yes. Anche il materiale di diagnostica di Microsoft indica quest'ordine: prima pktmon, poi netsh trace se non basta.

Perché il traffico verso localhost (127.0.0.1) non compare in Wireshark?

Il traffico verso localhost non passa mai da una NIC fisica: viene girato sul percorso di loopback interno del sistema. Una cattura normale che punta a un adattatore fisico quindi non lo vede. In Wireshark scegliete l'«Adapter for loopback traffic capture» di Npcap e potete catturare il traffico di loopback. pktmon cattura dentro lo stack di rete, quindi può osservare anche il loopback. Un altro scambio frequente è che «localhost» si risolve in IPv6 ::1, così uno schermo fisso su 127.0.0.1 non mostra nulla — confermate specificando l'indirizzo in modo esplicito.

Posso vedere il contenuto del traffico HTTPS (TLS) in una cattura di pacchetti?

Il payload dei dati applicativi è cifrato e non è visibile. Lo «scheletro» della conversazione — connessione e disconnessione TCP, se l'handshake TLS è riuscito, un taglio con RST, quale lato ha smesso di rispondere — resta visibile anche cifrato, quindi gran parte delle indagini di timeout procede con TLS lasciato cifrato. Se serve il payload esiste la decifrazione via SSLKEYLOGFILE, ma è supportata solo da alcune implementazioni TLS come Firefox e la famiglia Chrome; lo SChannel in dotazione di Windows non è supportato. Il meccanismo scrive materiale di chiave segreta, trattatelo come opzione solo per l'ambiente di sviluppo.

È sicuro inviare un file di cattura a un supporto esterno?

Inviarlo così com'è è pericoloso. Una cattura contiene la comunicazione stessa e può includere credenziali di protocolli in chiaro, cookie, chiavi API e dati personali. Prima, al momento della cattura, restringete filtro e finestra temporale al minimo necessario, e prima di consegnarlo estraete solo la conversazione obiettivo con un filtro di visualizzazione Wireshark ed esportatela. Per ciò che resta, accordatevi con il destinatario su come trattare le parti sensibili (mascherarle o consegnarle per un'altra via) prima di inviare. Decidete in anticipo quanto a lungo i file di cattura restano e quando vengono eliminati.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.