Wireshark — Howto : retransmissions TCP, Three-Way-Handshake et identification des points de performance

Cet Howto Wireshark commence par des prérequis clairs et une checklist pragmatique, afin que vous puissiez circonscrire rapidement et de façon robuste les retransmissions TCP, les problèmes du Three‑Way‑Handshake et les points de performance dans votre réseau. Le mot‑clé principal Wireshark-Howto est volontairement placé au début : l’objectif est de fournir des instructions pratiques pour les administrateurs, system engineers, opérateurs et prestataires IT. J’explique des termes techniques tels que RTT (Round-Trip-Time : temps aller‑retour) ou Zero Window (le récepteur signale qu’il ne peut actuellement pas tamponner de données) brièvement et montre pourquoi une constatation est typiquement d’origine réseau ou hôte.

Capture-Strategie: Wo mitscheiden und warum es zählt

La pertinence de votre analyse dépend principalement du lieu de capture. Une capture effectuée au mauvais endroit fournit des schémas de retransmission trompeurs ou masque un routage asymétrique. Planifiez les captures de manière à pouvoir reconstituer le sens du flux de messages.

Capture-Orte im Vergleich

• Client‑nah : Couvre la pile client, les pare‑feux locaux, les clients VPN et les retransmissions WLAN.
• Server‑nah : Montre si le serveur reçoit des SYNs, comment il répond et si des limites locales (backlog, ulimits) s’appliquent.
• Firewall/Load‑Balancer‑nah : Important en cas de NAT, Conntrack ou TLS‑Inspection ; fréquemment vous ne voyez qu’une direction, d’où l’intérêt d’une capture supplémentaire.
• SPAN vs. TAP : Les ports SPAN sont facilement accessibles mais peuvent droper en cas de forte charge ; les TAP fournissent des données plus complètes, mais exigent du matériel et de la planification.

Betriebsrisiken und Compliance

• Datenschutz : Les captures contiennent souvent des données utilisateur et doivent être minimisées, anonymisées ou supprimées rapidement conformément aux exigences de protection des données.
• Performance : La capture sur des hôtes en production peut augmenter la charge CPU/IO. Utilisez des ringbuffer ou un stockage distant pour les fichiers pcap.
• TLS : Le chiffrement masque le contenu des payloads, pas le timing, les flags ou l’état de la fenêtre – ces métadonnées suffisent pour les analyses de la mécanique TCP.

Pragmatische Capture‑Beispiele

Utilisez des filtres ciblés et des ringbuffer pour produire des PCAPs fiables. Voici deux exemples éprouvés en pratique pour Linux et 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

Exécutez toujours les cas de test avant et après les modifications avec les mêmes paramètres afin que les mesures soient comparables.

Wichtige Wireshark‑Ansichten für TCP

Wireshark propose plusieurs fonctionnalités particulièrement utiles : Display‑Filter (pour une vue ciblée), Conversations (flows), Follow TCP Stream (ordonne le flux) et Time‑Sequence‑Graph (visualise les séquences, les ACKs et les retransmissions). Ces vues aident à repérer des motifs et à déterminer la direction du problème.

Offloading‑Effekte verstehen

Des termes tels que TSO (TCP Segmentation Offload), GRO (Generic Receive Offload) et LRO (Large Receive Offload) signifient que la carte réseau prend en charge une partie du travail TCP. Les captures sur l’hôte peuvent donc montrer des segments trop grands ou l’absence de petits segments. En cas de résultats contradictoires, vérifiez la capture sur un TAP ou désactivez temporairement l’offloading.

# Désactiver l'offloading (temporairement) - Linux
sudo ethtool -K eth0 tso off gso off gro off

Analyser le Three‑Way‑Handshake

Le Three‑Way‑Handshake (SYN, SYN‑ACK, ACK) confirme qu’une connexion TCP peut être établie. Si cette étape échoue, il n’y a en général pas de transfert de données. Portez attention aux options TCP dans les SYN/SYN‑ACK : MSS (Maximum Segment Size), Window Scale (mise à l’échelle de la fenêtre) et SACK (Selective Acknowledgement) fournissent des indications sur des problèmes de MTU, de fenêtre ou de retransmission.

Séquence de vérification lors du handshake

1. Filtrer le flux : 5‑tuple (IP client, IP serveur, port client, port serveur, protocole).
2. SYN visible depuis le client ? Un SYN‑ACK revient‑il du serveur ?
3. L’ACK final manque‑t‑il ? Vérifiez la capture sur les deux côtés pour valider le chemin de retour.

Les causes typiques d’échecs du handshake sont des ACLs de pare‑feu, un routage asymétrique (une box stateful rejette les réponses), des SYN‑proxy/SYN‑cookies ou des limites serveur comme des backlogs pleins.

Interpréter correctement les retransmissions TCP

Les retransmissions sont la réaction de TCP à une perte de paquet présumée. Distinctions importantes :

• Fast Retransmission : survient après des Duplicate ACKs et indique une perte de paquet réelle.
• RTO Retransmission : intervient après un timeout et affecte fortement le débit.
• Spurious Retransmission : peut sembler exister, mais provient parfois de réordonnancement ou d’artéfacts de capture.

Filtres d’affichage utiles

• 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

Conseils d’interprétation : des Duplicate ACKs sans retransmissions indiquent un réordonnancement (p. ex. ECMP). Des retransmissions sans Duplicate ACKs peuvent résulter de lacunes de capture ou de véritables RTO.

Points de performance : causes typiques et motifs de mesure

Si le handshake réussit, il subsiste divers états d’attente qui limitent le débit. Les causes les plus fréquentes et leurs signatures sont :

RTT élevée et jitter

Une RTT élevée (Round‑Trip‑Time) ou un jitter fortement variable indiquent du queueing (tampons pleins), une saturation du lien, des retransmissions WLAN ou une inspection par pare‑feu. Dans le Time‑Sequence‑Graph vous observerez des intervalles prolongés entre les segments de données et les ACK.

Zero Window : problème côté hôte ou application ?

Zero Window signifie que le récepteur met sa fenêtre de réception à 0 parce que le tampon de l’application est plein. Il s’agit souvent d’un problème applicatif ou d’E/S (traitement lent, garbage collection ou écritures bloquantes). Ce n’est un problème réseau que si les latences sont si importantes que les ACK sont retardés.

Problèmes MTU / MSS

Des problèmes de MTU du chemin (par ex. dus à des tunnels comme GRE, VPN ou PPPoE) entraînent de la fragmentation ou le rejet de segments plus grands lorsque le flag DF est activé et que les messages ICMP sont bloqués. Vérifiez le MSS dans le SYN et utilisez des DF‑pings pour valider.

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

Vérifications spécifiques au pare-feu et au NAT

Les équipements pare-feu (stateful) et le NAT/Conntrack sont des causes fréquentes de pertes apparentes de paquets ou de flux asymétriques. Voici quelques vérifications et commandes pratiques.

Conntrack‑Limits und Timeouts prüfen

Conntrack (Connection Tracking) est un mécanisme dans les pare-feu qui gère les flux TCP dans une table. Si la table est pleine ou si les timeouts sont trop courts, les sessions sont abandonnées.

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

Réduisez les timeouts inutilement agressifs pour les connexions établies et vérifiez l’épuisement des ports sur les machines NAT (épuisement des ports source en cas de grand nombre de connexions par IP).

Détecter le routage asymétrique

Si les requêtes empruntent un chemin et les réponses un autre (p. ex. en raison d’ECMP, d’un changement de chemin ou d’un Multi‑ISP), un pare-feu stateful rejette les réponses car aucun état n’existe. Deux captures (inside/outside) éliminent rapidement l’incertitude.

Métriques, seuils et monitoring

Pour un dépannage durable, définissez et surveillez des indicateurs. Principales métriques :

• Retransmits par seconde et en pourcentage des paquets envoyés
• ACKs dupliqués par flux
• RTT moyen et 95‑e percentile
• Événements Zero‑Window par minute
• Utilisation de la table Conntrack

À titre indicatif : des retransmissions isolées sont normales ; des taux de retransmission constants >1–2% du trafic indiquent un problème sérieux. Les seuils dépendent du type d’application (les applications interactives sont sensibles à la latence, les transferts en masse sont plus tolérants).

Procédures pratiques de dépannage

1. Isoler le flux : Conversations → Top Talkers → appliquer un filtre 5‑tuple.
2. Vérifier le handshake : comparer SYN/SYN‑ACK/ACK aux deux extrémités.
3. Quantifier les retransmissions : utiliser le filtre tcp.analysis.*, déterminer le nombre et la direction.
4. Vérifications des middleboxes : vérifier Conntrack, NAT, les logs du pare-feu et la santé des load balancers.
5. Vérifications côté hôte : CPU, IO, buffers de 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)

Modifications, tests et rollback

Les modifications sur les pare-feux, la MTU ou le NAT sont effectives mais peuvent avoir des effets secondaires. Suivez ces règles :

• Limiter le périmètre : appliquez les modifications d’abord à un sous-réseau, un VIP ou un segment de test.
• Avant/Après : mêmes cas de test, même emplacement de capture, sauvegarder les PCAPs.
• Préparer le rollback : exporter la configuration avant la modification, définir une fenêtre temporelle et des métriques pour le critère de retour arrière.

Pièges typiques et comment les éviter

• Artefacts de capture : les drops sur port SPAN, l’offloading ou la timestampisation faussent l’interprétation. Si possible, utiliser un TAP ou désactiver l’offloading.
• Données incomplètes : capturer une seule extrémité conduit souvent à des attributions erronées. Deux extrémités sont la règle.
• Filtres incorrects : des filtres trop larges inondent, des filtres trop restrictifs masquent les motifs. Commencez large, puis restreignez.
• Protection des données : Conserver les captures aussi peu longtemps que nécessaire ; anonymiser les flux de données sensibles.

Conclusion

Ce Wireshark-Howto propose une méthode de travail structurée : commencez par le bon point de capture, vérifiez le Three‑Way‑Handshake pour une validation de base, quantifiez les retransmissions et classez-les selon leurs signatures (Fast Retransmit vs. RTO). Zero Window indique souvent des problèmes côté hôte ou application, alors que les Duplicate ACKs et les Fast Retransmits suggèrent des erreurs réseau ou de lien. En particulier pour les problèmes liés aux pare‑feu et au NAT, des captures synchronisées des deux côtés et des vérifications de conntrack sont déterminantes. Planifiez les modifications avec rollback et mesurez avant/après – cela réduit les risques opérationnels et accélère la résolution.

Utilisez ce guide comme base pour des runbooks au sein de votre équipe : des parcours de vérification clairement définis, des tests reproductibles et une coordination étroite entre les équipes réseau, pare‑feu et système accélèrent le diagnostic et augmentent la fiabilité de votre environnement de production.

Wireshark-Howto : automatisation des captures, synchronisation temporelle et intégration SIEM

En complément du guide pratique, il est utile d’intégrer le travail de capture dans les processus opérationnels existants. Ce chapitre décrit des aspects d’architecture et d’exploitation qui sont décisifs lors de scénarios d’incident prolongés, pour des exigences de conformité ou pour des contrôles de performance récurrents. Le mot‑clé focal Wireshark-Howto aide à positionner la procédure dans votre documentation.

Architecture : points de capture centralisés versus temporaires

• Collecteurs permanents : une interface d’agrégation dédiée (TAP ou mirror + hôte de capture dédié) permet de conserver des PCAPs pendant plusieurs jours ou semaines, facilite les analyses à long terme et l’indexation automatique. Avantage : base de comparaison cohérente. Inconvénient : stockage, protection des données et contrôle d’accès.
• Captures éphémères : captures de courte durée lors d’incidents ; elles sont flexibles mais moins adaptées aux analyses de tendance. Combinez les deux approches : extraction permanente de métadonnées, PCAPs complets à court terme en cas d’alerte.

Synchronisation temporelle et corrélation

Les horodatages sont l’épine dorsale des analyses distribuées. Si les hôtes et les collecteurs réseau ne sont pas synchronisés, il est impossible de corréler de manière fiable les ACKs, les retransmissions et les journaux de pare‑feu. Vérifiez la source temporelle sur tous les équipements impliqués :

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

Pour des analyses de latence très fines, le PTP peut être nécessaire ; pour les erreurs TCP typiques, une synchronisation NTP cohérente suffit.

Extraction automatique des métriques

Les PCAPs complets sont volumineux. Extrayez automatiquement des indicateurs (retransmissions, Duplicate ACKs, percentiles RTT) avec tshark et indexez les résultats dans votre SIEM ou une base temporelle. Exemple : compter les retransmissions par flux dans 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

La sortie peut être acheminée via un log‑forwarder vers Elasticsearch/Prometheus et liée à des règles d’alerte (par ex. taux de retransmission > X% sur 5 minutes).

Environnements conteneurisés et espaces de noms

Dans les environnements à base de conteneurs, les interfaces sont souvent éphémères (veths, bridge). Les captures effectuées sur l’hôte ne reflètent pas toujours la pile interne des namespaces. Utilisez des agents de capture spécifiques au namespace ou des fonctionnalités CNI de miroir de port pour obtenir des flux complets.

Conservation sécurisée, masquage et conformité

• Définissez des durées de conservation claires et des tâches automatisées de suppression pour minimiser les risques liés au RGPD/P11D.
• Réduisez l’étendue des captures via des filtres (IP/port) ou un mode « header‑only » des paquets lorsque la charge utile n’est pas nécessaire.
• Stockez les archives PCAP chiffrées et journalisez les accès.

Operationalisation / Runbook‑Schritte

1. Alerte définie → déclencher automatiquement un snapshot (PCAP complet).
2. Extraire les métadonnées (tshark/Zeek) et mettre à jour le tableau de bord.
3. Analyse initiale : corrélation temps/flux, taux de retransmission, événements Zero‑Window.
4. Effectuer la modification avec périmètre, métriques et plan de rollback (comme décrit précédemment).

Ces extensions opérationnelles rendent votre procédure Wireshark reproductible et évolutive : extraction automatisée, base temporelle précise et conservation conforme réduisent les efforts d’exploitation et accélèrent le dépannage au sein de l’équipe entre responsables réseau, pare‑feu et systèmes.

Pour ce sujet, les retransmissions TCP et l’analyse du handshake TCP sont également importantes. Cet article situe ces aspects de façon compréhensible et indique ce qui compte au quotidien.