Wireshark-Howto: ritrasmissioni TCP, handshake a tre vie e identificazione dei punti critici delle prestazioni

Questo Wireshark-Howto inizia con prerequisiti chiari e una checklist pragmatica, in modo che possiate delimitare rapidamente e con attendibilità TCP-Retransmits, problemi del Three-Way-Handshake e punti critici di performance nella vostra rete. La parola chiave di riferimento Wireshark-Howto è intenzionalmente all’inizio: l’obiettivo sono istruzioni pratiche per amministratori, system engineer, operatori e fornitori di servizi IT. Spiego termini tecnici come RTT (Round-Trip-Time: tempo di andata e ritorno) o Zero Window (il destinatario segnala di non poter attualmente bufferizzare dati) con brevi definizioni e mostro perché un riscontro è tipicamente di origine di rete o host.

Strategia di capture: dove registrare e perché conta

Il valore della vostra analisi dipende primariamente dal punto di capture. Un capture nel posto sbagliato fornisce pattern di retransmit fuorvianti o nasconde routing asimmetrico. Pianificate le acquisizioni in modo da poter seguire la direzione del flusso di messaggi.

Punti di acquisizione a confronto

• Vicino al client: Copre lo stack del client, firewall locali, client VPN e ritrasmissioni WLAN.
• Vicino al server: Mostra se il server riceve SYN, come risponde e se limiti locali (Backlog, ulimits) entrano in gioco.
• Vicino a firewall/load‑balancer: Importante in presenza di NAT, Conntrack o TLS‑Inspection; spesso si vede solo una direzione, perciò è utile un capture aggiuntivo.
• SPAN vs. TAP: Le porte SPAN sono facilmente accessibili ma possono perdere pacchetti ad alto carico; i TAP forniscono dati più completi, ma richiedono hardware e pianificazione.

Rischi operativi e conformità

• Protezione dei dati: I capture contengono spesso dati utente e devono essere, in base alle normative sulla privacy, minimizzati, anonimizzati o cancellati rapidamente.
• Performance: L’acquisizione su host di produzione può aumentare il carico CPU/IO. Usare ring buffer o storage remoto per i file pcap.
• TLS: La cifratura nasconde il contenuto della payload, non il timing, i flag o lo stato della finestra – questi metadati sono sufficienti per analisi della meccanica TCP.

Esempi pratici di capture

Usate filtri mirati e ring buffer per ottenere PCAP affidabili. Qui due esempi testati in pratica per Linux e Windows.

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

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

Eseguire i casi di test prima e dopo le modifiche sempre con gli stessi parametri, in modo che le misurazioni siano confrontabili.

Visualizzazioni Wireshark importanti per TCP

Wireshark offre diverse funzionalità particolarmente utili: display‑filter (per visualizzazioni mirate), Conversations (flows), Follow TCP Stream (ordina il flow) e Time‑Sequence‑Graph (visualizza sequenze, ACK e ritrasmissioni). Queste viste aiutano a riconoscere schemi e a determinare la direzione del problema.

Comprendere gli effetti di offloading

Termini come TSO (TCP Segmentation Offload), GRO (Generic Receive Offload) e LRO (Large Receive Offload) indicano che la scheda di rete svolge parti del lavoro TCP. I capture sull’host possono quindi mostrare segmenti sovradimensionati o la mancanza di piccoli segmenti. In caso di risultati contraddittori, verificate il capture su un TAP o disattivate temporaneamente l’offloading.

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

Three‑Way‑Handshake analysieren

Il Three‑Way‑Handshake (SYN, SYN‑ACK, ACK) conferma che una connessione TCP può essere stabilita. Se questo passaggio fallisce, normalmente non si verifica alcun trasferimento dati. Prestate attenzione alle opzioni TCP in SYN/SYN‑ACK: MSS (Maximum Segment Size), Window Scale (scala della finestra) e SACK (Selective Acknowledgement) forniscono indicazioni su problemi di MTU, finestra e ritrasmissione.

Prüfsequenz beim Handshake

1. Filtrare il flow: 5‑Tuple (Client IP, Server IP, Client Port, Server Port, protocollo).
2. Si vede un SYN dal client? Torna un SYN‑ACK dal server?
3. Manca l’ACK finale? Verificate i capture su entrambe le parti per confermare il percorso di ritorno.

Cause tipiche di handshake falliti sono ACL dei firewall, routing asimmetrico (box stateful che scarta le risposte), SYN‑Proxy/SYN‑Cookies o limiti lato server come backlog pieni.

TCP‑Retransmits richtig einordnen

Le retransmission sono la reazione di TCP a una sospetta perdita di pacchetti. Distinzioni importanti:

• Fast Retransmission: avviene dopo Duplicate ACKs e indica perdita reale di pacchetti.
• RTO Retransmission: si verifica dopo un timeout e impatta fortemente il throughput.
• Spurious Retransmission: sembra esistere, ma può essere causata da reordering o da artefatti del capture.

Nützliche Display‑Filter

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

Consigli per l’interpretazione: Duplicate ACK senza retransmission indicano reordering (es. ECMP). Retransmission senza Duplicate ACK possono essere lacune nel capture o veri RTO.

Performance‑Spots: typische Ursachen und Messmuster

Se l’handshake ha successo, rimangono diversi stati di attesa che limitano il throughput dei dati. Le cause più frequenti e le loro signature sono:

Hohe RTT und Jitter

RTT elevate o jitter molto variabile indicano accodamento (buffer pieni), sovraccarico del link, retransmission a livello Wi‑Fi o ispezione da parte del firewall. Nel Time‑Sequence‑Graph si osservano intervalli prolungati tra segmenti di dati e ACK.

Zero Window: Host‑ oder Applikationsproblem?

Zero Window significa che il ricevente imposta la sua receive‑window a 0 perché il buffer dell’applicazione è pieno. Spesso si tratta di un problema applicativo o di I/O (elaborazione lenta, garbage collection o scritture bloccanti). Solo se le latenze di rete sono così elevate da ritardare gli ACK, il problema è primariamente di rete.

MTU / MSS‑Probleme

Problemi di Path‑MTU (es. a causa di tunnel come GRE, VPN o PPPoE) portano a frammentazione o alla perdita di segmenti più grandi se il flag DF è impostato e i messaggi ICMP sono bloccati. Verificate la MSS nel SYN e utilizzate ping con DF per la validazione.

# MTU testen (Linux): DF-Flag setzen, Payload anpassen
ping -M do -s 1472 10.20.30.40
# Bei Fehlschlag: iterativ verkleinern

Verifiche specifiche per firewall e NAT

Firewall‑Devices (stateful) e NAT/Conntrack sono cause comuni di apparente perdita di pacchetti o di flussi asimmetrici. Di seguito alcuni controlli pratici e comandi.

Controllare limiti e timeout di Conntrack

Conntrack (Connection Tracking) è un meccanismo nelle firewall che gestisce i flussi TCP in una tabella. Se la tabella è piena o i timeout sono troppo brevi, le sessioni vengono scartate.

# Conntrack-Statistiken (Linux nftables/conntrack-tools)
sudo conntrack -S
# Anzahl der Einträge prüfen
sudo conntrack -L | wc -l

Riducete timeout eccessivamente aggressivi per connessioni stabilite e verificate l’esaurimento delle porte sulle macchine NAT (esaurimento delle porte sorgente con un alto numero di connessioni per IP).

Rilevare routing asimmetrico

Se le richieste seguono un percorso e le risposte un altro (es. a causa di ECMP, cambi di percorso o multi‑ISP), un firewall stateful può scartare le risposte perché non esiste lo state. Due capture (inside/outside) risolvono rapidamente il dubbio.

Metriche, soglie e monitoraggio

Per un troubleshooting sostenibile dovreste definire e monitorare metriche. Metriche rilevanti:

• Ritrasmissioni al secondo e come percentuale dei pacchetti inviati
• ACK duplicati per flow
• RTT media e 95° percentile
• Eventi Zero‑Window per minuto
• Utilizzo della tabella conntrack

Indicativamente: ritrasmissioni isolate sono normali; tassi di ritrasmissione persistenti >1–2% del traffico indicano un problema serio. Le soglie dipendono dal tipo di applicazione (le applicazioni interattive sono sensibili alla latenza, i trasferimenti bulk più tolleranti).

Procedure pratiche di troubleshooting

1. Isolare il flow: Conversations → Top Talkers → impostare un filtro 5‑tuple.
2. Verificare l’handshake: confrontare SYN/SYN‑ACK/ACK su entrambe le estremità.
3. Quantificare le ritrasmissioni: usare il filtro tcp.analysis.*, determinare quantità e direzione.
4. Verifiche sulle middlebox: controllare conntrack, NAT, log del firewall e lo stato di salute del load balancer.
5. Controlli host: CPU, I/O, buffer dei socket, netstat/tcpstat

# Beispiel: TCP-Socket-Statistiken (Linux)
ss -tan state established sport = :443
# Kernel TCP Counters (Rx/Tx/Retransmits)
cat /proc/net/snmp | egrep 'Tcp|TcpExt' -n
# Switchport-Fehler prüfen (Beispiel vendorabhängig)

Modifiche, test e rollback

Le modifiche a firewall, MTU o NAT hanno effetto ma possono avere effetti collaterali. Seguite queste regole:

• Limitare lo scope: applicare le modifiche prima a una subnet, a un VIP o a un segmento di test.
• Prima/Dopo: stessi casi di test, stesso punto di capture, salvare i PCAP.
• Preparare il rollback: esportare la configurazione prima della modifica, definire una finestra temporale e le metriche per il criterio di rollback.

Insidie tipiche e come evitarle

• Artefatti di capture: SPAN‑Port Drop, Offloading oder Zeitstempelungen possono falsare l’interpretazione. Se possibile usare un TAP o disabilitare l’offloading.
• Dati incompleti: catturare solo un lato spesso porta a errori di attribuzione. La regola è catturare entrambi i lati.
• Filtri errati: filtri troppo ampi sovraccaricano, troppo stretti nascondono modelli. Iniziate ampi, poi restringete.
• Protezione dei dati: Conservare le catture non più a lungo del necessario; anonimizzare i flussi di dati sensibili.

Conclusione

Questo Wireshark-Howto fornisce una metodologia di lavoro strutturata: iniziate dal punto di capture corretto, verificate il Three‑Way‑Handshake per la validazione di base, quantificate i Retransmits e classificateli in base alle loro firme (Fast Retransmit vs. RTO). Zero Window indica spesso problemi dell’host o dell’applicazione, mentre Duplicate ACKs e Fast Retransmits suggeriscono errori di rete o di link. Soprattutto in caso di problemi con firewall e NAT sono decisive capture sincronizzate su entrambe le parti e controlli di Conntrack. Pianificate le modifiche con rollback e misurate prima/dopo – questo riduce i rischi operativi e accelera la risoluzione.

Utilizzate questa guida come base per i runbook del vostro team: percorsi di verifica chiaramente definiti, test riproducibili e un coordinamento stretto tra i team di rete, firewall e sistemi accelerano l’identificazione dei guasti e aumentano l’affidabilità del vostro ambiente di produzione.

Wireshark-Howto: Capture‑Automation, Zeit‑Synchronisation und SIEM‑Integration

In aggiunta al howto pratico conviene integrare il lavoro di capture nei processi operativi esistenti. Questo capitolo descrive aspetti di architettura e operation che sono decisivi in scenari di incidenti prolungati, per requisiti di compliance o per controlli di performance ricorrenti. La parola chiave Wireshark-Howto aiuta a collocare la guida nella vostra documentazione.

Architettura: zentrale versus temporäre Capture‑Punkte

• Collector permanenti: Un’interfaccia di aggregazione dedicata (TAP o Mirror + host di capture dedicato) fornisce PCAP per giorni o settimane, consente analisi a lungo termine e indicizzazione automatica. Vantaggio: base di confronto consistente. Svantaggio: spazio di archiviazione, protezione dei dati e controllo degli accessi.
• Capture effimere: Capture a breve termine per incidenti; sono flessibili, ma meno adatte alle analisi di trend. Combinate entrambe le soluzioni: estrazione permanente dei metadati e PCAP completi a breve termine in caso di allarme.

Sincronizzazione temporale e correlazione

I timestamp sono la spina dorsale delle analisi distribuite. Se host e collector di rete non sono sincronizzati, ACK, Retransmits e log dei firewall non possono essere correlati in modo affidabile. Verificate la sorgente temporale su tutti i dispositivi coinvolti:

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

Per analisi di latenza molto fini può essere necessario PTP; per errori TCP tipici è sufficiente una sincronizzazione NTP coerente.

Estrazione automatica delle metriche

I PCAP completi sono voluminosi. Estraete automaticamente metriche (Retransmits, Duplicate ACKs, percentili RTT) con tshark e indicizzate i risultati nel vostro SIEM o in una DB di serie temporali. Esempio: contare i Retransmits per flow in un PCAP.

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

L’output può essere inoltrato tramite un log‑forwarder in Elasticsearch/Prometheus e collegato a regole di alerting (es. Retransmit‑Rate > X% per oltre 5 minuti).

Ambienti containerizzati e namespace

Nelle architetture container le interfacce sono spesso effimere (veths, bridge). Le catture sull’host non mostrano sempre lo stack interno nei namespace. Utilizzate agenti di cattura specifici per namespace o funzionalità CNI di port‑mirroring per ottenere flow completi.

Conservazione sicura, oscuramento e conformità

• Definite periodi di conservazione chiari e job di cancellazione automatizzati per ridurre al minimo i rischi DSGVO/P11D.
• Riducete l’ambito di acquisizione tramite filtri (IP/Port) o modalità solo intestazione pacchetto, se il payload non è necessario.
• Proteggete gli archivi PCAP con crittografia e registrate gli accessi.

Operationalizzazione / Passaggi del runbook

1. Allarme definito → avviare automaticamente uno snapshot (PCAP completo).
2. Estrarre metadati (tshark/Zeek) e aggiornare il dashboard.
3. Analisi iniziale: correlazione tempo/flow, tasso di ritrasmissione, eventi Zero‑Window.
4. Eseguire la modifica con ambito, metriche e piano di rollback (come già descritto).

Queste estensioni operative rendono il vostro Wireshark‑Howto riproducibile e scalabile: estrazione automatizzata, base temporale precisa e conservazione conforme alla normativa riducono il carico operativo e accelerano la risoluzione dei guasti nel team tra responsabili di rete, firewall e sistemi.

Anche per questo ambito sono importanti le ritrasmissioni TCP e l’analisi dell’handshake TCP. L’articolo contestualizza questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.