Capture de paquets sous Windows en pratique — choisir entre pktmon, netsh trace et Wireshark

« La communication serveur de l’application métier échoue quelques fois par mois. Le journal applicatif ne dit que “timeout”. Il n’y a pas d’erreur correspondante dans le journal côté serveur à ce moment-là. On ne sait pas comment reproduire » — dans les consultations d’enquête de bugs, cette forme revient sans cesse.

Un journal applicatif ne conserve que ce que l’application « a décidé d’écrire ». On voit que le résultat était un timeout, mais si la demande de connexion (SYN) n’a eu aucune réponse, si la connexion s’est établie puis le serveur s’est tu, si elle a été coupée par un RST, ou si le paquet a même atteint la destination, tout cela vit un cran sous le journal — dans les paquets qui sont réellement passés sur le fil. Si Process Monitor est le moyen de descendre d’un cran sur les accès fichiers et registre, la capture de paquets est le moyen de descendre d’un cran sur la conversation.

flowchart TB
    accTitle: Les paquets un cran sous le journal applicatif
    accDescr: Un journal applicatif ne conserve que ce que l'application a décidé d'écrire ; absence de réponse au SYN, silence après connexion, coupure par RST ou arrivée du paquet ne vivent que dans les paquets réellement passés sur le fil
    log["Journal applicatif"] --> dec["Seul ce que l'app a décidé d'écrire reste"]
    dec --> to["Le résultat est un timeout d'un mot"]
    to -->|descendre d'un cran| pkt["Paquets réellement passés sur le fil"]
    pkt --> q1["Pas de réponse au SYN ?"]
    pkt --> q2["Silence après connexion ?"]
    pkt --> q3["Coupé par RST ?"]
    pkt --> q4["A-t-il atteint la destination ?"]

Figure 1 : Le journal ne garde que le résultat ; le détail d’un timeout n’existe que dans les paquets un cran plus bas.

L’endroit typique où l’on bloque est la contrainte « on ne peut pas installer Wireshark sur le serveur du client ». Les sites où le contrôle des changements ou une politique de sécurité n’approuvent pas de logiciel supplémentaire pour une enquête ne sont pas rares. Windows, pourtant, livre déjà deux outils de capture de paquets : pktmon et netsh trace. Capturer avec les outils intégrés de l’OS, ramener le fichier sur son propre PC et le lire dans Wireshark — avec ce partage, on voit encore les paquets sur un site qui interdit les installations.

Cet article s’adresse aux informaticiens de PME et aux développeurs d’applications Windows. Il organise le choix entre pktmon, netsh trace et Wireshark, et la procédure pratique de chacun. Les pièges du trafic de bouclage, le choix de capturer côté client ou serveur, comment vivre avec le TLS qui cache la charge utile, et la corrélation de la capture avec le journal applicatif sont traités à partir de sources primaires à jour en août 2026.

1. La conclusion d’abord

• « Capturer avec l’outil intégré, lire avec Wireshark » est le partage de base sur site. Même si l’on ne peut pas installer de logiciel sur le serveur client, pktmon et netsh trace sont intégrés à Windows. Convertissez le journal capturé en pcapng et analysez-le dans Wireshark sur votre machine.¹²
• pktmon est l’outil de capture de paquets intégré à Windows 10 / Windows Server 2019 et ultérieurs. On l’utilise en quatre étapes — enregistrer un filtre, démarrer, arrêter, convertir — et sa force distinctive est de voir quel composant de la pile réseau a écarté le paquet (la raison du drop).³⁴
• netsh trace est l’outil intégré plus ancien ; il peut activer un ensemble de fournisseurs ETW comme « scénario ». Outre les paquets, il conserve des événements internes aux composants Windows, et avec persistent=yes la capture peut survivre à un redémarrage.⁵⁶
• Les deux outils écrivent de l’ETL, que Wireshark ne peut pas ouvrir tel quel. Convertissez en pcapng avec pktmon etl2pcap pour pktmon, et avec l’outil open source de Microsoft etl2pcapng pour netsh trace.¹²
• Microsoft lui-même pointe « pktmon d’abord, puis netsh trace si ce n’est pas assez, et Wireshark pour l’analyse de protocole ». Le partage de cet article suit cette recommandation officielle.⁷
• Par défaut, pktmon n’enregistre que les 128 premiers octets de chaque paquet. Si vous comptez lire la charge utile dans Wireshark, n’oubliez pas --pkt-size 0 (enregistrer le paquet entier) au démarrage.⁸
• Le trafic vers localhost n’apparaît pas dans une capture normale. Il ne passe jamais par une NIC. Utilisez l’adaptateur de bouclage Npcap dans Wireshark, ou la capture dans la pile de pktmon avec les outils intégrés.⁹
• Même lorsque le TLS cache la charge utile, on apprend encore beaucoup. Établissement de la connexion, succès de la poignée de main TLS, RST, et quel côté s’est tu restent visibles même chiffrés. Le déchiffrement via SSLKEYLOGFILE est une technique réservée à l’environnement de développement.¹⁰
• Une capture contient la communication elle-même. Partez du principe qu’elle peut inclure des identifiants et des données personnelles, et intégrez à la procédure une capture minimale et un filtrage avant transmission.

2. Les trois outils de capture et comment choisir

D’abord, un tableau unique des rôles des trois outils.

En une phrase, pktmon et netsh trace sont les outils de « capture », et Wireshark est l’outil de « lecture ». Wireshark peut aussi capturer, mais on ne peut pas s’en servir là où on ne peut pas l’installer. Inversement, on peut convertir l’ETL des outils intégrés en texte et le lire, mais le fixer sans filtre d’affichage ni analyse TCP est une misère. « Capturer sur site avec l’outil intégré, convertir en pcapng, et lire dans Wireshark sur sa machine » est le chemin le plus court sur un site contraint.

flowchart TB
    accTitle: Capturer avec l'outil intégré, lire avec Wireshark
    accDescr: Sur site on capture de l'ETL avec pktmon ou netsh trace, on convertit chacun en pcapng avec son outil, puis on analyse dans Wireshark sur sa machine
    pk["pktmon (intégré)"] --> etla["Fichier ETL"]
    ns["netsh trace (intégré)"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["Analyser dans Wireshark sur sa machine"]

Figure 2 : Sur site on capture de l’ETL avec les outils intégrés, on convertit en pcapng, et on le lit dans Wireshark sur sa machine.

Le guide Microsoft d’enquête sur les pertes de paquets a la même forme : capturer et isoler la cause avec pktmon d’abord, puis passer à des traces au niveau composant comme netsh trace start scenario=InternetClient si ce n’est pas assez, et analyser le comportement de protocole dans Wireshark.⁷

Comme préalable pour lire ce qu’un paquet montre réellement, il est aussi utile d’avoir une image des couches empilées — Ethernet, IP, TCP, données applicatives. L’anatomie des couches est illustrée dans « Comprendre vraiment le modèle OSI ».

3. pktmon en pratique — Filtrer, démarrer, arrêter, convertir

Le flux de base de pktmon tient en quatre étapes. Exécutez-les dans un terminal élevé.

:: 1. Enregistrer d'abord un filtre pour restreindre la cible (TCP 8443 sur le serveur 192.168.10.20)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. Démarrer la capture. Enregistrer les paquets entiers, écraser dans un tampon circulaire de 1 Go
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. Reproduire l'incident. En attendant, on peut vérifier le volume et les pertes avec counters
pktmon counters --drop-reason

:: 4. Arrêter, puis convertir en pcapng pour Wireshark
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. Nettoyer le filtre enregistré (les filtres restent jusqu'à suppression explicite).
::    Note : filter remove n'accepte pas de nom ; il supprime « tous » les filtres enregistrés.
::    Sur une machine qui peut encore avoir des filtres d'une autre enquête, vérifier d'abord avec pktmon filter list
pktmon filter remove

flowchart TB
    accTitle: Procédure de base de pktmon
    accDescr: Réduire la cible avec un filtre, démarrer la capture, reproduire l'incident, arrêter, convertir en pcapng avec etl2pcap, puis retirer le filtre enregistré
    fa["1. Réduire la cible avec filter add"] --> st["2. Démarrer avec start --capture"]
    st --> re["3. Reproduire l'incident"]
    re -.-> ct["Vérifier volume et drops avec counters"]
    re --> sp["4. Arrêter"]
    sp --> cv["Convertir en pcapng avec etl2pcap"]
    cv --> rm["5. Nettoyer avec filter remove"]

Figure 3 : pktmon commence par l’enregistrement du filtre, puis capture, arrêt et conversion, et on retire le filtre explicitement à la fin.

Points à retenir :

• Enregistrez les filtres avant de démarrer la capture. La documentation Microsoft recommande aussi fortement d’appliquer un filtre avant de démarrer, car capturer tout le trafic est trop bruyant. Les filtres peuvent spécifier adresse IP, port, adresse MAC, protocole, ID VLAN, etc., et on peut en enregistrer jusqu’à 32. Plusieurs filtres sont un OU : un paquet est enregistré s’il correspond à l’un d’eux.³
• Un filtre pktmon ne distingue pas source et destination. -i 192.168.10.20 signifie « les paquets où cette adresse est la source ou la destination ». Réduisez le sens plus tard avec un filtre d’affichage Wireshark après conversion.³
• La taille de paquet par défaut est 128 octets. Cela suffit pour l’analyse d’en-têtes, mais si vous voulez aussi les données applicatives, enregistrez le paquet entier avec --pkt-size 0.⁸
• Le journal est par défaut en mode circular (tampon circulaire), taille par défaut 512 Mo. On change le plafond avec --file-size, et --log-mode real-time imprime à l’écran en temps réel sans créer de fichier journal. Confirmez d’abord en temps réel que vous voyez réellement le trafic qui vous intéresse, puis réglez la capture de production : vous évitez une prise vide.⁸

flowchart TB
    accTitle: Comment les filtres pktmon s'appliquent
    accDescr: Plusieurs filtres enregistrés enregistrent sur une correspondance OU, l'adresse spécifiée ne distingue pas source et destination, et le sens se réduit ensuite avec un filtre d'affichage Wireshark après conversion
    f1["Filtre 1"] --> orc["Enregistrer si l'un correspond"]
    f2["Filtre 2"] --> orc
    f3["Filtre 3 (jusqu'à 32)"] --> orc
    orc --> rec["Enregistré dans le journal de capture (OU)"]
    rec -.-> nodir["Source et destination non distinguées"]
    nodir -.-> ws["Réduire le sens dans Wireshark après conversion"]

Figure 4 : Plusieurs filtres fonctionnent en OU, et le fait qu’un hôte soit source ou destination se réduit dans Wireshark après conversion.

3.1. Ce que seul pktmon peut faire — voir où un paquet a été écarté

La valeur distinctive de pktmon face à Wireshark est qu’il capture un paquet à plusieurs points à l’intérieur de la pile réseau, pas à une seule NIC, et peut indiquer où et pourquoi il a été écarté (dropped). Parce qu’on voit jusqu’à quel composant un paquet est arrivé et où il a disparu, des raisons de drop comme « écart MTU » ou « filtre VLAN » mènent à la cause sans recherche exhaustive.⁴

flowchart TB
    accTitle: pktmon capture à plusieurs points dans la pile
    accDescr: pktmon capture un paquet à plusieurs points dans la pile réseau plutôt qu'à une seule NIC, il peut donc indiquer avec une raison quel composant le paquet a atteint et où il a été écarté
    pin["Paquet"] --> p1["Capturé au point 1"]
    p1 --> p2["Capturé au point 2"]
    p2 --> p3["Écarté au point 3"]
    p3 -.-> rz["Indique le lieu et la raison du drop"]
    rz -.-> ex["ex. écart MTU ou filtre VLAN"]

Figure 5 : Capturer à plusieurs points dans la pile indique jusqu’où un paquet est allé et où il a été droppé, avec une raison.

• pktmon list montre les composants réseau que l’on peut surveiller (NIC, piles de protocoles, pilotes de filtre, etc.) et leurs ID.
• pktmon counters --drop-reason liste les compteurs de passage/drop par composant et la raison de drop la plus récente. Pratique comme première coupe avant d’analyser le journal.¹¹
• Convertissez en texte avec pktmon etl2txt et les paquets écartés sont émis avec drop et un dropReason.³

Le soupçon que « quelque chose dans l’OS écarte ceci avant qu’il n’atteigne l’application » ne se tranche pas en fixant Wireshark seul. Cette capacité aide, par exemple, à isoler un cas où le pare-feu droppe faute de règle entrante (« Le pare-feu Windows et les applications métier »).

Un bémol. pktmon enregistre le même paquet à plusieurs points de la pile, donc une conversion telle quelle en pcapng peut faire apparaître le même paquet plus d’une fois. pcapng ne porte pas « quel composant a capturé ceci », donc pour une lecture dans Wireshark le geste standard est de convertir avec --component-id pour choisir un point (ou de mettre les drops seuls dans un fichier séparé avec --drop-only).¹

flowchart TB
    accTitle: Pourquoi le même paquet peut apparaître deux fois après conversion pcapng
    accDescr: pktmon enregistre le même paquet à plusieurs points de la pile, pcapng ne conserve pas quel composant l'a capturé donc des doublons peuvent apparaître, et le geste standard est de convertir après avoir réduit le point avec component-id ou mis les drops seuls dans un fichier drop-only
    same["Même paquet enregistré à plusieurs points"] --> conv["Convertir en pcapng tel quel"]
    conv --> lost["L'information de point de capture n'est pas reprise"]
    lost --> dup["Le même paquet apparaît plus d'une fois"]
    dup --> c1["Réduire le point avec --component-id"]
    dup --> c2["Fichier séparé avec --drop-only"]

Figure 6 : L’information de point de capture n’est pas reprise dans pcapng, donc le geste standard est de réduire le point avant de convertir.

4. netsh trace en pratique — Scénarios, ETL et captures qui survivent à un redémarrage

netsh trace est le mécanisme de trace présent dans Windows plus longtemps que pktmon. Sa caractéristique est qu’en tant que « scénario » il peut activer d’un coup tout l’ensemble de fournisseurs ETW liés à ce problème.⁶

:: 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

• Ajoutez capture=yes pour activer la capture de paquets, et réduisez la cible avec un filtre de capture tel que ipv4.address=192.168.10.20. La liste des filtres est dans netsh trace show capturefilterHelp.⁶
• L’arrêt produit un fichier .cab en plus de l’ETL. Le .cab contient des informations système telles que la configuration des adaptateurs et la build de l’OS, il sert donc aussi de collecte d’environnement.⁶
• Une seule session de trace peut s’exécuter à la fois. Avant de démarrer une autre capture, vérifiez avec netsh trace show status qu’aucune session résiduelle ne tourne encore.⁶
• Ajoutez persistent=yes et la session survit à un redémarrage. Capturer « la communication échoue un instant juste après le redémarrage » ou « la connexion du service au démarrage échoue » — des incidents qu’on ne peut pas démarrer à temps à la main — est le terrain unique de netsh trace.⁵

flowchart TB
    accTitle: Capturer un scénario netsh trace
    accDescr: Démarrer avec un scénario active un ensemble de fournisseurs ETW, capture=yes capture aussi les paquets, et l'arrêt produit un fichier ETL et un fichier .cab
    sc["Démarrer avec un scénario"] --> pv["Activer l'ensemble de fournisseurs"]
    sc -->|capture=yes| pc["Les paquets sont aussi capturés"]
    pv --> re["Reproduire l'incident"]
    pc --> re
    re --> sp["Arrêter"]
    sp --> etl["Fichier ETL"]
    sp --> cab[".cab (informations système)"]

Figure 7 : Démarrer avec un scénario active un ensemble de fournisseurs, et l’arrêt produit ETL et .cab.

4.1. Rendre l’ETL lisible dans Wireshark — etl2pcapng

L’ETL de netsh trace ne s’ouvre pas tel quel dans Wireshark. etl2pcapng, l’outil open source que Microsoft publie sur GitHub, convertit en pcapng les paquets d’un ETL capturé avec netsh trace start capture=yes.²

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

À la conversion, etl2pcapng écrit l’identifiant de processus lié à chaque paquet comme commentaire de paquet. Pouvoir voir « de quel processus est ce trafic » dans Wireshark aide lorsque plusieurs applications sur le même serveur communiquent.²

Le côté événements ETW (événements internes Windows enregistrés par les fournisseurs du scénario) n’est pas converti en pcapng. Si vous voulez aussi les événements, convertissez en texte ou équivalent avec netsh trace convert input=C:\temp\nettrace.etl, ou ouvrez l’ETL dans Windows Performance Analyzer.⁵⁷

flowchart TB
    accTitle: Lire l'ETL netsh trace se scinde en deux chemins
    accDescr: Les paquets dans l'ETL se convertissent en pcapng avec etl2pcapng et se lisent dans Wireshark ; les événements ETW ne sont pas convertis en pcapng, on les lit avec netsh trace convert ou Windows Performance Analyzer
    etl["ETL netsh trace"] --> pk["Paquets"]
    etl --> ev["Événements ETW"]
    pk -->|etl2pcapng| pc["Convertir en pcapng"]
    pc --> ws["Lire dans Wireshark"]
    pc -.-> pid["L'ID de processus reste en commentaire"]
    ev -.-> no["Non converti en pcapng"]
    no --> alt["Lire avec convert ou WPA"]

Figure 8 : De l’ETL, les paquets se convertissent en pcapng pour être lus ; les événements ETW se lisent autrement.

5. Premier regard pour lire dans Wireshark — Filtres d’affichage et analyse TCP

Une fois le pcapng ouvert, coupez d’abord le bruit avec un filtre d’affichage. Les plus courants sont dans le tableau.¹²¹³

tcp.analysis.* sont des drapeaux d’analyse que Wireshark attribue en suivant les numéros de séquence TCP. Retransmissions, ACK dupliqués, hors séquence, ZeroWindow et similaires sont relevés mécaniquement, donc la façon standard de commencer à lire est de taper d’abord tcp.analysis.flags et de lister les endroits « qui ont l’air d’un problème ».¹³

Dans une enquête de timeout, cherchez les formes suivantes dans l’ordre.

1. La poignée de main à trois voies s’est-elle achevée ? Les trois paquets SYN → SYN/ACK → ACK sont-ils tous là ? Si le SYN se répète sans réponse, il n’a jamais atteint le pair, ou il a été écarté silencieusement au milieu (le schéma typique du pare-feu).
2. Quel côté a envoyé le RST ? Un RST immédiat au SYN signifie que personne n’écoute sur le port de destination ; un RST après établissement signifie qu’un côté a forcé la coupure. L’IP source du RST est la preuve directe de « qui a coupé ».
3. Les retransmissions continuent-elles ? La retransmission répétée du même segment est le signe que l’accusé de réception (ACK) ne revient pas à l’émetteur. Si les données sortantes ont été perdues ou si l’ACK de retour l’a été ne se tranche pas depuis une capture unilatérale (c’est pourquoi « capturer des deux côtés » au chapitre suivant compte). Retransmissions et timeouts sont approfondis dans « Pourquoi les retransmissions TCP bloquent la communication d’une caméra industrielle ».
4. Y a-t-il un ZeroWindow ? C’est le signe que l’application réceptrice ne lit pas depuis le socket et que le tampon de réception est plein. C’est un motif de soupçonner la conception de l’application réceptrice (« Le malentendu selon lequel TCP renvoie les données dans les mêmes unités que Send ») plutôt que le réseau.

flowchart TB
    accTitle: Ordre des formes à chercher dans une enquête de timeout
    accDescr: Confirmer l'achèvement de la poignée de main à trois voies, la présence et la source d'un RST, les retransmissions qui continuent, puis ZeroWindow, pour poser une première marque sur la cause
    hs{"Le SYN a-t-il eu une réponse ?"} -->|non| ng["N'est jamais arrivé（Pare-feu typique）"]
    hs -->|oui| rs{"Y a-t-il un RST ?"}
    rs -->|oui| who["La source du RST a coupé"]
    rs -->|non| rt{"Les retransmissions continuent ?"}
    rt -->|oui| ack["L'ACK ne revient pas"]
    rt -->|non| zw{"ZeroWindow présent ?"}
    zw -->|oui| app["Le récepteur ne lit pas"]

Figure 9 : Chercher poignée de main, RST, retransmission, puis ZeroWindow dans cet ordre réduit l’endroit où regarder ensuite.

Avant de lire les paquets un par un, il aide aussi de prendre le tableau d’ensemble avec les fonctions de statistiques. [Statistics] → [Conversations] est une liste de « quelle paire d’IP / de ports a parlé, de quand à quand, combien », pour identifier la conversation qui vous intéresse puis filtrer uniquement celle-là. [Statistics] → [I/O Graph] est un graphe de volume dans le temps ; des formes comme « à partir de cet instant, un sens s’est tu » sautent aux yeux. Clic droit sur la conversation TCP d’intérêt et [Follow] → [TCP Stream] permet de lire l’échange de cette connexion en clair.

flowchart TB
    accTitle: Prendre le tableau avec les statistiques, puis réduire à une conversation
    accDescr: Lister quelles conversations ont parlé quand et combien dans Conversations, saisir l'intervalle de silence sur l'I/O Graph, filtrer la conversation d'intérêt, et la lire comme flux TCP
    ov["Prendre le tableau d'ensemble avec les statistiques"] --> cv["Liste des conversations dans Conversations"]
    ov --> io["Voir le volume sur l'I/O Graph"]
    cv --> flt["Filtrer la conversation d'intérêt"]
    io -.-> mute["L'intervalle de silence devient visible"]
    flt --> fs["Lire comme flux TCP"]

Figure 10 : Avant de lire paquet par paquet, prenez le tableau avec les statistiques, réduisez à la conversation d’intérêt, puis lisez-la d’un trait.

6. Le piège du bouclage — le trafic vers localhost ne passe jamais par une NIC

Essayer d’enquêter sur une communication entre applications sur le même PC — par exemple une application métier qui se connecte à un service intermédiaire sur localhost:8080 — et rester bloqué sur « rien n’apparaît dans Wireshark » est un piège classique.

La cause est claire. Le trafic vers localhost (127.0.0.1) ne passe jamais par une NIC physique ; il est renvoyé sur le chemin de bouclage interne de l’OS. Une capture normale ciblant un adaptateur physique ne le voit donc jamais.⁹

flowchart TB
    accTitle: Pourquoi le trafic vers localhost n'apparaît pas dans une capture
    accDescr: Le trafic vers localhost ne passe jamais par une NIC physique et est renvoyé sur le chemin de bouclage interne de l'OS, il n'apparaît donc jamais dans une capture normale ciblant un adaptateur physique
    app["Application"] --> stack["Pile réseau"]
    stack -->|externe| nic["NIC physique"]
    nic --> seen["Vu dans une capture normale"]
    stack -->|localhost| lo["Renvoyé dans l'OS"]
    lo -.-> miss["Absent d'une capture normale"]
    lo -.-> alt["Bouclage Npcap ou pktmon"]

Figure 11 : Le trafic vers localhost est renvoyé avant la NIC, une capture d’adaptateur physique ne le voit jamais.

Il y a deux façons de s’y prendre.

• Lors d’une capture dans Wireshark : Choisissez l’« Adapter for loopback traffic capture » de Npcap comme cible de capture. L’installateur Windows de Wireshark (3.0 et ultérieurs) embarque Npcap, donc si Wireshark est déjà installé vous l’utilisez sans travail supplémentaire.⁹
• Lors d’une capture avec les outils intégrés : pktmon capture à plusieurs points à l’intérieur de la pile réseau plutôt qu’à l’extérieur de la NIC⁴, il peut donc aussi observer le trafic de bouclage. Pour être sûr, avant de poser une attente de reproduction en production, confirmez sur cette machine avec l’affichage temps réel pktmon start -c -m real-time que le trafic de bouclage qui vous intéresse est réellement visible.

Surveillez aussi deux confusions.

• « localhost » peut se résoudre en IPv6 ::1. L’application se connecte à IPv6 ::1, mais l’enquêteur ne regarde que 127.0.0.1 (IPv4) et conclut à tort « il n’y a pas de trafic ». Étirez le filtre d’affichage sur les deux, comme dans ip.addr == 127.0.0.1 || ipv6.addr == ::1, ou rendez le réglage de destination de l’application une adresse explicite.⁹
• Le trafic vers votre propre IP réelle ne part pas non plus sur le fil. Quand le même PC se connecte de 192.168.10.5 à 192.168.10.5, la destination est une IP réelle mais l’OS le renvoie encore en interne. Souvenez-vous que « j’ai spécifié une IP réelle, donc ça passe par la NIC » n’est pas garanti.

flowchart TB
    accTitle: La confusion quand localhost se résout en IPv6
    accDescr: Le localhost d'une application peut se résoudre en IPv6 ::1, et si l'enquêteur ne regarde que 127.0.0.1 il conclut à tort qu'il n'y a pas de trafic, donc étirez le filtre d'affichage sur les deux adresses ou confirmez la destination comme adresse explicite
    app["L'app se connecte à localhost"] --> v6["Se résout en fait en ::1 (IPv6)"]
    look["L'enquêteur ne regarde que 127.0.0.1"] --> none["Rien n'apparaît à l'écran"]
    v6 --> none
    none --> fix1["Étirer le filtre sur les deux adresses"]
    none --> fix2["Rendre la destination une adresse explicite"]

Figure 12 : Attention à la confusion où localhost se résout en ::1 et ne regarder que 127.0.0.1 mène à « il n’y a pas de trafic ».

7. Où capturer — un côté, les deux côtés, et la synchro d’horloge

La valeur d’une capture se décide par « où vous avez capturé ». La règle empirique est la suivante.

Une capture unilatérale ne vous dit que « les faits vus de ma position ». Des retransmissions qui continuent côté client ne distinguent pas si le paquet envoyé a disparu sur le chemin, ou s’il est arrivé au serveur et que la réponse a disparu. Capturer des deux côtés et les aligner permet de trancher « le client l’a envoyé / le serveur ne l’a jamais reçu » — quel côté s’est tu. Quand il faut trancher la frontière de responsabilité (l’application, l’OS, un équipement réseau, ou l’autre extrémité), cela vaut la peine de préparer une capture des deux côtés dès le départ.

flowchart TB
    accTitle: Ce que disent les captures unilatérale et bilatérale
    accDescr: Une capture unilatérale ne distingue pas si le paquet sortant a disparu ou si la réponse de retour a disparu ; capturer des deux côtés et les aligner tranche quel côté s'est tu
    one["Capturer d'un côté"] --> fact["Faits de votre côté"]
    fact --> und["Sortant ou retour ?"]
    both["Capturer des deux côtés"] --> mt["Les aligner"]
    mt --> fix["Quel côté s'est tu"]
    mt -.-> pre["Il faut une synchro d'horloge"]

Figure 13 : Un seul côté ne montre que les faits que vous avez vus ; aligner les deux côtés est ce qui tranche d’abord la frontière de responsabilité.

7.1. La prémisse de la corrélation est la synchro d’horloge

Pour aligner des captures des deux côtés, les horloges des deux machines doivent s’accorder. Avant de démarrer la capture, vérifiez et notez le décalage d’horloge.

:: 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 est la commande qui montre le décalage de temps entre vous et l’ordinateur pair, et elle devient le fondement d’une correction telle que « l’horloge du serveur était à +0,8 seconde » lorsque vous alignez les captures.¹⁴ Dans un environnement à grand décalage, corriger d’abord la synchro d’heure puis capturer est le chemin le plus court au final.

flowchart TB
    accTitle: Procédure pour vérifier le décalage d'horloge avant corrélation
    accDescr: Confirmer son propre état de synchro avec w32tm, mesurer et noter le décalage contre le serveur pair avec stripchart, utiliser ce décalage comme fondement de correction à l'alignement, et si le décalage est grand corriger d'abord la synchro puis capturer
    st["Vérifier l'état de synchro avec query"] --> mc["Mesurer le décalage avec stripchart"]
    mc --> rc["Noter le décalage"]
    rc --> use["Fondement de correction à la corrélation"]
    mc -.-> big["Si le décalage est grand, corriger d'abord la synchro"]

Figure 14 : Mesurez et notez le décalage d’horloge avant de capturer, et utilisez-le comme fondement de correction lorsque vous alignez les captures.

7.2. Pour « on ne sait pas quand cela arrivera » — un tampon circulaire

Pour un incident dont les conditions de reproduction sont inconnues, le geste de base est de laisser un tampon circulaire tourner et de l’arrêter quand l’incident survient.

• pktmon : Par défaut, c’est le mode circular. Fixez le plafond (Mo) avec --file-size ; les paquets plus anciens sont écrasés.⁸
• netsh trace : Spécifiez-le comme maxSize=1024 filemode=circular.⁵
• Wireshark : Sous [Capture] → [Options] → [Output] on peut configurer « plusieurs fichiers + tampon circulaire ». Il tourne par taille de fichier ou par temps et ne garde que les N fichiers les plus récents, donc on peut tourner longtemps avec un plafond d’usage disque.¹⁵

Dans tous les cas, partagez avec la personne sur site la règle : quand l’incident arrive, « noter l’heure d’abord, puis » arrêter la capture. Un tampon circulaire efface le passé plus on attend, donc si le chemin de l’occurrence à l’arrêt est long, l’intervalle qui vous intéresse est écrasé.

flowchart TB
    accTitle: Attendre avec une capture en tampon circulaire
    accDescr: Pour un incident dont les conditions de reproduction sont inconnues, laisser un tampon circulaire tourner, et quand l'incident survient noter l'heure et arrêter vite ; un arrêt tardif écrase les paquets plus anciens et l'intervalle d'intérêt disparaît
    st["Démarrer une capture en tampon circulaire"] --> wt["Le laisser tourner et attendre"]
    wt --> ev["L'incident survient"]
    ev --> memo["Noter l'heure"]
    memo --> sp["Arrêter vite"]
    wt -.-> ow["Les paquets plus anciens sont écrasés"]
    ow -.-> late["Un arrêt tardif efface l'intervalle d'intérêt"]

Figure 15 : Un tampon circulaire efface le passé plus on attend, donc une fois l’heure notée, arrêtez vite.

8. Le problème que le TLS cache la charge utile — ce que l’on voit encore

La plupart du trafic métier aujourd’hui est du TLS (HTTPS). On a tendance à penser « si c’est chiffré, capturer ne sert à rien », mais la plupart de ce que l’on veut dans une enquête de timeout reste visible avec le chiffrement laissé en place.

• Si la connexion TCP s’est établie (poignée de main à trois voies)
• Jusqu’où la poignée de main TLS est allée — si ServerHello est revenu à ClientHello, si elle a été coupée par un RST ou une alerte pendant la poignée de main
• Le nom d’hôte de destination sur ClientHello (SNI), et la version TLS négociée
• Une fois la connexion en place, quel côté a cessé d’envoyer. Le lieu du silence, les retransmissions, un RST, ou une fermeture propre (FIN)

Autrement dit, isoler « impossible de se connecter », « coupe au milieu » et « aucune réponse ne revient » n’a presque jamais besoin du déchiffrement de la charge utile. Ce que le chiffrement perd, c’est « ce qu’ils ont dit » ; « qui s’est tu, et quand » reste.

flowchart TB
    accTitle: Ce qu'une capture TLS peut et ne peut pas montrer
    accDescr: Le chiffrement ne cache que la charge utile des données applicatives ; établissement de connexion TCP, succès ou échec de la poignée de main TLS, SNI et version TLS, RST, et quel côté s'est tu restent visibles avec le chiffrement laissé en place
    tls["Capture de trafic TLS"] --> vis["Visible"]
    tls --> hid["Non visible"]
    vis --> v1["Établissement de connexion TCP"]
    vis --> v2["Résultat TLS et SNI"]
    vis --> v3["RST / qui s'est tu"]
    hid --> h1["Charge utile des données applicatives"]

Figure 16 : Le chiffrement ne perd que la charge utile ; le squelette de la conversation se lit encore avec le TLS laissé en place.

Quand il faut encore la charge utile, Wireshark peut déchiffrer le TLS à l’aide des clés de session écrites via la variable d’environnement SSLKEYLOGFILE. La prise en charge se limite à certaines implémentations comme Firefox, Chrome, Edge basé sur Chromium et les bibliothèques de la famille OpenSSL ; le SChannel intégré à Windows (applications qui utilisent WinHTTP ou WinINET) ne prend pas en charge ce mécanisme.¹⁰ Parce que « la clé de session est écrite dans un fichier » signifie que quiconque a ce fichier peut déchiffrer toute la conversation, ce n’est pas une technique de production ; traitez-la comme une reproduction et un débogage en environnement de développement.

flowchart TB
    accTitle: Fonctionnement et limites du déchiffrement SSLKEYLOGFILE
    accDescr: Les clés de session écrites via SSLKEYLOGFILE permettent à Wireshark de déchiffrer le TLS, mais seules certaines implémentations comme Firefox et la famille Chrome le prennent en charge et SChannel non ; quiconque a le fichier de clés peut déchiffrer la conversation, donc traitez-le comme une technique réservée à l'environnement de développement
    env["Définir SSLKEYLOGFILE"] --> key["Écrire les clés de session"]
    key --> ws["Lire dans Wireshark"]
    key -.-> risk["Le détenteur de la clé peut déchiffrer"]
    risk -.-> dev["Développement seulement"]
    env -.-> sup["Certaines piles TLS seulement"]
    sup -.-> sch["SChannel : pas de prise en charge"]

Figure 17 : Écrire les clés de session peut déchiffrer, mais les implémentations prises en charge sont limitées, et la nature de la clé en fait une technique réservée à l’environnement de développement.

Lorsque le trafic passe par un proxy interne, la destination qui apparaît dans la capture est le serveur proxy, et le TLS circule dans un tunnel CONNECT. La question préalable de vers quel proxy l’application se dirige même est organisée dans l’article compagnon du même jour « Les proxys d’entreprise et les applications Windows — démêler la résolution de proxy dans WinINET, WinHTTP et .NET ».

9. Corréler avec le journal applicatif — mettre le temps sur le même axe

Une capture à elle seule produit rarement la conclusion. Le geste décisif en pratique est de mettre une ligne du journal applicatif et un aller-retour de paquets sur le même axe temporel.

La procédure ressemble à ceci.

1. Identifiez l’heure de l’incident depuis le journal applicatif (par exemple, une exception de timeout à 10:23:41). Si la valeur de timeout est de 30 secondes, le début devrait être autour de 10:23:11.
2. Passez l’affichage de l’heure de Wireshark sur [View] → [Time Display Format] → [Date and Time of Day], et réduisez l’intervalle avec un filtre d’affichage (on peut aussi filtrer par l’heure, comme dans frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00").
3. Dans cet intervalle, confirmez l’ordre du chapitre 5 (poignée de main → RST → retransmission → ZeroWindow). Si vous pouvez aligner jusqu’à « 30 secondes avant l’heure de timeout du journal, un SYN a été envoyé, et ensuite seulement des retransmissions de SYN », le « timeout » du journal est remplacé par l’observation « à ce point de capture, aucune réponse n’est jamais revenue » (si le SYN n’a jamais atteint le pair, ou si le SYN/ACK de retour a été perdu sur le chemin du retour, ne se tranche pas depuis ce seul point de capture. S’il faut le trancher, capturez sur le serveur et alignez-les).
4. Corrigez toujours le décalage entre l’heure de capture et l’heure du journal (le décalage d’horloge mesuré à la section 7.1, et la notation de fuseau du journal). Quelques secondes d’erreur de corrélation cloueront la mauvaise conversation comme coupable.

flowchart TB
    accTitle: Procédure pour aligner le journal applicatif et les paquets
    accDescr: Identifier l'heure de l'incident depuis le journal applicatif, remonter l'heure de début depuis la valeur de timeout, réduire l'intervalle dans Wireshark avec un filtre d'affichage, confirmer les formes dans l'ordre, corriger le décalage d'horloge, et les mettre sur le même axe temporel
    lg["1. Identifier l'heure de l'incident depuis le journal"] --> rev["Remonter le début depuis la valeur de timeout"]
    rev --> flt["2. Réduire l'intervalle avec un filtre d'affichage"]
    flt --> chk["3. Confirmer les formes dans l'ordre du chapitre 5"]
    chk --> adj["4. Corriger le décalage d'horloge"]
    adj --> done["Le mot du journal devient une observation"]

Figure 18 : Réduisez l’intervalle depuis l’heure du journal, confirmez la forme, corrigez le décalage d’horloge, et mettez-les sur le même axe.

Lorsque vous remettez des résultats d’enquête à un tiers (un éditeur, un opérateur, le personnel réseau du client), couper le bruit avec un filtre avant de le transmettre est à la fois une politesse et une mesure de sécurité. Dans Wireshark, réduisez à la conversation d’intérêt avec un filtre d’affichage et enregistrez « les paquets affichés seulement » avec [File] → [Export Specified Packets], et vous obtenez un petit pcapng de juste la plage dont vous avez besoin.

Enfin, une précaution de traitement. Un fichier de capture contient la communication elle-même. Il peut inclure des identifiants de protocoles en clair, des cookies HTTP et des clés d’API, le contenu de courriers ou de rapports, et des données personnelles. Décidez des trois points suivants comme un ensemble avec la procédure de capture.

• Capture minimale nécessaire : Réduisez la cible avec les filtres pré-capture (chapitres 3 et 4) et gardez la fenêtre temporelle aussi courte que possible. Ne faites pas « on capture tout » sur un environnement client
• Réduire avant de transmettre : Exportez uniquement la conversation d’intérêt ; n’incluez pas de trafic tiers sans rapport. S’il reste des parties sensibles, convenez avec le destinataire d’un masquage ou d’un autre moyen
• Conservation et suppression : Décidez où les fichiers de capture sont conservés, pendant combien de temps, et quand ils sont supprimés, et supprimez-les quand l’enquête est terminée

flowchart TB
    accTitle: Trois décisions à prendre avant de transmettre un fichier de capture
    accDescr: Une capture contient la communication elle-même, donc décidez comme un ensemble avec la procédure de capture que vous réduirez au minimum avec les filtres pré-capture et une fenêtre temporelle, extrairez uniquement la conversation d'intérêt avant transmission pour ne pas inclure de trafic sans rapport, et déciderez du lieu et de la durée de conservation puis supprimerez après l'enquête
    cap["Capture = le trafic"] --> p1["Capturer le minimum"]
    cap --> p2["Extraire d'abord la cible"]
    cap --> p3["Fixer la conservation, supprimer"]
    p2 -.-> exp["Filtrer et exporter"]

Figure 19 : Décidez capture minimale, réduction avant transmission, et conservation et suppression comme un ensemble avec la procédure de capture.

10. Synthèse

• Un cran sous le « timeout » du journal applicatif se trouve le fait des paquets réellement passés sur le fil. Que le SYN n’ait pas eu de réponse, qu’un RST ait coupé, que les retransmissions aient continué, ou qu’un ZeroWindow soit apparu change l’endroit où regarder ensuite.
• Même sur un site où l’on ne peut pas installer Wireshark, on peut capturer avec pktmon et netsh trace intégrés à Windows. Capturer avec l’outil intégré, lire avec Wireshark sur sa machine — ce partage est la forme de base.
• pktmon tient en quatre étapes : enregistrer un filtre → pktmon start --capture → pktmon stop → pktmon etl2pcap. Par défaut c’est tronqué à 128 octets, donc si vous voulez la charge utile n’oubliez pas --pkt-size 0. Voir le lieu et la raison du drop est une force que seul pktmon a.
• netsh trace capture un ensemble de fournisseurs ETW comme scénario, et avec persistent=yes il peut survivre à un redémarrage. Convertissez l’ETL en pcapng avec etl2pcapng pour le lire.
• Dans Wireshark, partez de tcp.analysis.flags et cherchez poignée de main, RST, retransmission et ZeroWindow dans cet ordre. C’est plus rapide si vous prenez d’abord le tableau avec Conversations et l’I/O Graph, puis réduisez.
• Le trafic vers localhost ne passe jamais par une NIC, on ne peut pas le capturer de la façon ordinaire. Utilisez l’adaptateur de bouclage Npcap ou la capture dans la pile de pktmon.
• Capturer des deux côtés et les aligner tranche « quel côté s’est tu ». La prémisse est la synchro d’horloge (w32tm). Pour un incident dont les conditions de reproduction sont inconnues, attendez avec un tampon circulaire.
• Même sous TLS, le squelette de la conversation est visible. Traitez le déchiffrement (SSLKEYLOGFILE) comme une technique réservée à l’environnement de développement, et traitez le fichier de capture lui-même comme confidentiel : intégrez capture minimale, réduction et suppression à l’exploitation.

On pense souvent la capture de paquets comme « l’outil d’un spécialiste réseau », mais en pratique c’est un outil d’enquête côté application qui ne commence à signifier quelque chose que lorsqu’on l’aligne avec le journal applicatif. La prochaine fois qu’une enquête s’arrête au seul mot « timeout », allez regarder un cran plus bas.

Articles connexes

• Pourquoi les retransmissions TCP bloquent la communication d’une caméra industrielle, et comment isoler la cause
• Le malentendu selon lequel TCP renvoie les données dans les mêmes unités que Send — concevoir la réception comme un flux d’octets
• Comprendre vraiment le modèle OSI — disséquer une requête HTTP en ses sept couches
• Guide pratique de Process Monitor (ProcMon) — identifier en 10 minutes un « paramètre non pris en compte » ou un ACCESS DENIED
• Le pare-feu Windows et les applications métier — enregistrer les règles entrantes depuis l’installateur
• Les proxys d’entreprise et les applications Windows — démêler la résolution de proxy dans WinINET, WinHTTP et .NET

Domaines de conseil associés

KomuraSoft LLC prend en charge les enquêtes de bugs d’origine communication telles que « la communication de l’application métier échoue de temps en temps et on ne trouve pas la cause » et « nous voulons isoler une erreur de connexion qui n’arrive que sur l’environnement client ». Nous prenons la conception de la capture (où, quoi, et combien capturer), l’analyse Wireshark, la corrélation avec le journal applicatif, et la correction côté application comme un seul travail continu.

• Développement d’applications Windows
• Investigation de bugs et analyse des causes
• Conseil technique et revue de conception
• Nous contacter

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Comment capturer des paquets sur un serveur client où l'on ne peut pas installer Wireshark ?

Utilisez les outils fournis avec Windows, pktmon ou netsh trace : aucune installation supplémentaire n'est nécessaire. Avec pktmon, enregistrez un filtre dans un terminal élevé, démarrez la capture avec pktmon start --capture, puis arrêtez-la avec pktmon stop. Le fichier ETL obtenu se convertit en pcapng avec pktmon etl2pcap, de sorte que l'analyse se fait dans Wireshark sur votre propre machine. « Capturer avec l'outil intégré, lire avec Wireshark » est le partage de tâches de base sur les sites qui restreignent les installations.

Faut-il utiliser pktmon ou netsh trace ?

Si le système a pktmon (Windows 10 / Windows Server 2019 et ultérieurs), commencez par pktmon. Les commandes sont simples, on voit quel composant de la pile réseau a écarté le paquet (la raison du drop), et la conversion pcapng est autonome. netsh trace est le meilleur choix pour capturer sur un ancien OS sans pktmon, pour collecter les événements ETW des composants Windows sous forme de scénario, ou pour qu'une capture survive à un redémarrage avec persistent=yes. La documentation de dépannage de Microsoft pointe aussi cet ordre : pktmon d'abord, puis netsh trace si ce n'est pas suffisant.

Pourquoi le trafic vers localhost (127.0.0.1) n'apparaît-il pas dans Wireshark ?

Le trafic vers localhost ne passe jamais par une NIC physique : il est renvoyé sur le chemin de bouclage interne de l'OS. Une capture normale ciblant un adaptateur physique ne le voit donc jamais. Dans Wireshark, choisissez l'« Adapter for loopback traffic capture » de Npcap pour capturer le trafic de bouclage. pktmon capture à l'intérieur de la pile réseau, il peut donc aussi observer le bouclage. Autre confusion fréquente : « localhost » se résout en IPv6 ::1, et un écran calé sur 127.0.0.1 ne montre rien — confirmez en spécifiant l'adresse explicitement.

Peut-on voir le contenu d'un trafic HTTPS (TLS) dans une capture de paquets ?

La charge utile des données applicatives est chiffrée et n'est pas visible. Le « squelette » de la conversation — connexion et coupure TCP, succès de la poignée de main TLS, coupure par RST, quel côté a cessé de répondre — reste visible même chiffré, donc la plupart des enquêtes de timeout avancent avec le TLS laissé chiffré. S'il faut la charge utile, le déchiffrement via SSLKEYLOGFILE existe, mais seules certaines implémentations TLS comme Firefox et la famille Chrome le prennent en charge ; le SChannel intégré à Windows n'est pas pris en charge. Le mécanisme écrit du matériel de clé secrète : traitez-le comme une option réservée à l'environnement de développement.

Est-il sûr d'envoyer un fichier de capture à un support externe ?

L'envoyer tel quel est dangereux. Une capture contient la communication elle-même et peut inclure des identifiants de protocoles en clair, des cookies, des clés d'API et des données personnelles. D'abord, au moment de la capture, réduisez le filtre et la fenêtre temporelle au minimum nécessaire, puis avant de le transmettre, extrayez uniquement la conversation cible avec un filtre d'affichage Wireshark et exportez-la. Pour ce qui reste, convenez avec le destinataire du traitement des parties sensibles (masquage, ou livraison par un autre moyen) avant l'envoi. Décidez à l'avance de la durée de conservation des fichiers de capture et du moment de leur suppression.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.