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

« La communication de l’application métier échoue quelques fois par mois. Le journal ne dit rien d’autre que « timeout ». Il n’y a pas d’erreur côté serveur non plus, et nous ne savons pas comment reproduire. » C’est une situation qui revient souvent dans les enquêtes de panne de communication.

Ce que vous voulez savoir à ce moment, c’est si la connexion a échoué, ou si la réponse s’est arrêtée après que la connexion a été établie. Le même timeout mène à un endroit différent à enquêter ensuite.

Un journal applicatif ne conserve que ce que l’application « a décidé d’écrire ». Du seul résultat « timeout », vous ne pouvez pas dire si le SYN n’a pas eu de réponse, si le serveur s’est tu sur une connexion établie, ou si la connexion a été coupée par un RST.

La capture de paquets examine ce qui se trouve un cran plus bas : les paquets qui sont réellement passés sur le fil. Là où Process Monitor regarde un cran plus bas l’accès aux fichiers et au registre, la capture de paquets regarde un cran plus bas la communication. Lorsque vous devez confirmer si un paquet a même atteint sa destination, la capture des deux côtés traitée au chapitre 7 devient importante.

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, et si le SYN n'a pas eu de réponse, si le pair s'est tu après l'établissement, si un RST a coupé la connexion, ou si le paquet est même arrivé n'est enregistré que dans les paquets réellement passés sur le fil
    log["Journal applicatif"] --> dec["Ne conserve que ce que l'application a décidé d'écrire"]
    dec --> to["Le résultat est le seul mot timeout"]
    to -->|regarder un cran plus bas| 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 un RST ?"]
    pkt --> q4["A-t-il atteint la destination ?"]

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

Même lorsque « nous ne pouvons pas installer Wireshark sur le serveur du client », il n’y a pas lieu d’abandonner la capture. Même si le contrôle des changements ou une politique de sécurité empêche d’ajouter un logiciel, Windows a deux outils de capture intégrés : pktmon et netsh trace.

Le partage de base est capturer avec les outils intégrés sur site, lire dans Wireshark sur votre propre machine. Traiter la capture et l’analyse comme des tâches séparées permet à l’enquête d’avancer même sur les sites à restrictions d’installation.

Cet article s’adresse au personnel informatique des PME et aux développeurs d’applications Windows. Il organise comment choisir entre pktmon, netsh trace et Wireshark, et la procédure pratique de chacun. Le piège du trafic de bouclage, le choix de capturer côté client ou côté serveur, comment traiter le TLS qui cache le contenu, et la corrélation de la capture avec le journal applicatif sont tous traités d’après des sources primaires à la date d’août 2026.

Partez de votre problème

Si c’est votre première lecture, suivez le flux choisir un outil au chapitre 2, capturer aux chapitres 3 et 4, et lire au chapitre 5. Les chapitres 6 à 8 couvrent les conditions de capture et les limites de ce que l’on peut observer, et le chapitre 9 est la procédure pour aboutir à une conclusion avec le journal applicatif.

1. D’abord la conclusion

La capture et l’analyse peuvent être laissées à des outils différents

Sur site, capturez avec pktmon ou netsh trace, convertissez en pcapng, et analysez dans Wireshark sur votre propre machine. Les deux outils écrivent de l’ETL, que Wireshark ne peut pas ouvrir tel quel. Pour pktmon, utilisez pktmon etl2pcap ; pour netsh trace, utilisez etl2pcapng, l’outil open source de Microsoft.¹²

L’ordre pour choisir les outils est pktmon d’abord, netsh trace si cela ne suffit pas, et Wireshark pour l’analyse de protocole. Le guide d’enquête Microsoft recommande le même flux.³

Avant de capturer, décidez ce qu’il faut garder et où observer

pktmon est livré avec Windows 10 / Windows Server 2019 et ultérieur et s’utilise en quatre étapes : enregistrer un filtre, démarrer, arrêter, convertir. Sa force distinctive est de vous indiquer où dans la pile un paquet a été abandonné, avec la raison d’abandon. Toutefois, par défaut seuls les 128 premiers octets de chaque paquet sont conservés. Pour lire le contenu, spécifiez --pkt-size 0 au démarrage.⁴⁵⁶

netsh trace est l’outil intégré plus ancien. Un scénario regroupe un ensemble de fournisseurs ETW, donc il peut capturer des paquets avec des événements de l’intérieur de Windows. Pour une capture qui traverse un redémarrage, utilisez persistent=yes.⁷⁸

Le trafic vers localhost ne passe pas par une NIC physique, donc il n’apparaît pas dans une capture d’un adaptateur physique. Utilisez l’adaptateur de bouclage Npcap ou la capture dans la pile de pktmon.⁹

Séparer ce que l’on peut lire de la façon de traiter le fichier

Même lorsque TLS cache le contenu, vous pouvez encore examiner l’établissement de connexion, si la poignée de main TLS a réussi, les RST, et quel côté s’est tu. Le déchiffrement via SSLKEYLOGFILE est une technique pour les environnements de développement seulement.¹⁰

En revanche, un fichier de capture contient la communication elle-même. Supposez qu’il peut inclure des informations d’identification et des informations personnelles, gardez la cible et la fenêtre temporelle au minimum, et faites du resserrement avant qu’il ne quitte l’entreprise une partie de la procédure de capture.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (21 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Les trois outils de capture et comment choisir entre eux

Les critères sont « ce que l’on peut installer sur site » et « ce que l’on veut garder en plus des paquets ». Comparez d’abord les rôles des trois outils.

Le plus simple est de penser pktmon et netsh trace « capturent », Wireshark « lit ». Wireshark peut aussi capturer, mais cela n’est pas disponible sur les sites où il ne peut pas être installé.

Vous pouvez aussi convertir l’ETL des outils intégrés en texte et le lire. Toutefois, convertir en pcapng et analyser dans Wireshark fait avancer l’enquête mieux que de lire à l’œil sans filtres d’affichage ni analyse TCP.

flowchart TB
    accTitle: Capturer avec les outils intégrés, lire avec Wireshark
    accDescr: Montre le partage dans lequel pktmon ou netsh trace capture de l'ETL sur site, le convertisseur de chaque outil le transforme en pcapng, et Wireshark sur votre propre machine l'analyse
    pk["pktmon (intégré)"] --> etla["Fichier ETL"]
    ns["netsh trace (intégré)"] --> etlb["ETL plus .cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["Analyser dans Wireshark sur votre propre machine"]

Figure 2 : Sur site, capturez de l’ETL avec les outils intégrés, convertissez en pcapng, et lisez-le dans Wireshark sur votre propre machine.

Le guide Microsoft d’enquête sur la perte de paquets suit la même structure : d’abord capturer avec pktmon et isoler la cause, puis si cela ne suffit pas passer au traçage au niveau composant tel que netsh trace start scenario=InternetClient, et analyser le comportement de protocole dans Wireshark.³

Comme préalable pour lire ce qu’un paquet montre, la compréhension va plus vite si vous pouvez vous représenter l’empilement d’Ethernet, IP, TCP et des données applicatives. L’anatomie de ces couches est illustrée dans « Comprendre vraiment le modèle OSI ».

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

La capture de base tient en quatre étapes : enregistrer un filtre, démarrer, arrêter, convertir. Nettoyez les filtres lorsque vous avez fini. Exécutez ce qui suit dans un terminal élevé.

Avant de démarrer, vérifiez les filtres existants et comment vous nettoierez ensuite. Le pktmon filter remove final ne supprime pas un filtre par nom ; il supprime tous les filtres enregistrés. Dans un environnement partagé avec une autre enquête, vérifiez d’abord avec pktmon filter list.

:: 1. Enregistrer d'abord un filtre pour resserrer la cible (TCP 8443 sur le serveur cible 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'événement. En attendant, les compteurs montrent le volume de trafic et les abandons
pktmon counters --drop-reason

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

:: 5. Nettoyer les filtres enregistrés (les filtres persistent jusqu'à suppression explicite).
::    Attention : filter remove ne peut pas prendre un nom et supprime TOUS les filtres enregistrés.
::    Dans un environnement où des filtres d'une autre enquête restent, vérifiez d'abord avec pktmon filter list
pktmon filter remove

flowchart TB
    accTitle: La procédure pktmon de base
    accDescr: Resserrer la cible avec un enregistrement de filtre, démarrer la capture, reproduire l'événement, arrêter, convertir en pcapng avec etl2pcap, et enfin supprimer les filtres enregistrés
    fa["1. Resserrer la cible avec filter add"] --> st["2. Démarrer la capture avec start --capture"]
    st --> re["3. Reproduire l'événement"]
    re -.-> ct["Vérifier le trafic et les abandons avec counters"]
    re --> sp["4. Arrêter avec stop"]
    sp --> cv["Convertir en pcapng avec etl2pcap"]
    cv --> rm["5. Nettoyer avec filter remove"]

Figure 3 : pktmon commence par l’enregistrement de filtre, et après capture, arrêt et conversion, les filtres sont supprimés explicitement.

Décider les quatre points suivants avant d’exécuter les commandes réduit le besoin de recapturer.

Ce qu’il faut vérifier avant de capturer

Resserrer la cible : plusieurs filtres sont des conditions OU

Les filtres sont enregistrés avant le démarrage de la capture. La documentation Microsoft recommande aussi fortement d’appliquer les filtres avant de démarrer, car capturer tout le trafic est beaucoup trop bruyant. Les filtres peuvent spécifier l’adresse IP, le port, l’adresse MAC, le protocole, l’ID VLAN, etc., et jusqu’à 32 peuvent être enregistrés. Plusieurs filtres sont une condition OU : « enregistrer si l’un quelconque correspond ».⁴

Resserrer la direction : source et destination ne sont pas distinguées

Les filtres pktmon ne distinguent pas la source de la destination. -i 192.168.10.20 signifie « paquets où cette adresse est la source ou la destination ». Resserrer la direction après conversion avec un filtre d’affichage Wireshark.⁴

Décider la plage d’enregistrement : en-têtes seulement, ou paquets entiers

La taille de paquet par défaut est 128 octets. Cela suffit pour analyser les en-têtes, mais pour lire aussi les données applicatives, enregistrez les paquets entiers avec --pkt-size 0.⁶

Décider la capacité : tampon circulaire et affichage en temps réel

Le journal est par défaut en mode circular (tampon circulaire) avec une taille par défaut de 512 Mo. --file-size change la limite, et --log-mode real-time affiche les paquets à l’écran en temps réel sans créer de fichier journal. Confirmer d’abord en affichage temps réel que « le trafic que je vise est visible » avant de mettre en place la vraie capture évite une exécution inutile.⁶

flowchart TB
    accTitle: Comment les filtres pktmon prennent effet
    accDescr: Montre que plusieurs filtres enregistrés fonctionnent comme une condition OU qui enregistre lorsqu'un quelconque correspond, qu'une adresse spécifiée ne distingue pas source et destination, et que la direction est donc resserrée après conversion avec un filtre d'affichage Wireshark
    f1["Filtre 1"] --> orc["Enregistrer si l'un quelconque correspond"]
    f2["Filtre 2"] --> orc
    f3["Filtre 3 (jusqu'à 32)"] --> orc
    orc --> rec["Enregistré dans le journal de capture (condition OU)"]
    rec -.-> nodir["Source et destination ne sont pas distinguées"]
    nodir -.-> ws["Resserrer la direction dans Wireshark après conversion"]

Figure 4 : Plusieurs filtres fonctionnent comme une condition OU, et la direction, source ou destination, est resserrée dans Wireshark après conversion.

3.1. La force unique de pktmon — savoir où le paquet a été abandonné

Ce qui distingue pktmon de Wireshark, c’est qu’il capture les paquets en plusieurs points à l’intérieur de la pile réseau, pas au seul point de la NIC, et indique où et pourquoi un paquet a été abandonné (dropped). Parce que vous voyez quel composant le paquet a atteint et où il a disparu, des raisons d’abandon telles que « MTU mismatch » ou « VLAN filter » vous mènent à la cause sans essai-erreur.⁵

flowchart TB
    accTitle: pktmon capture en plusieurs points à l'intérieur de la pile
    accDescr: Montre que parce que pktmon capture les paquets en plusieurs points à l'intérieur de la pile réseau plutôt qu'au seul point de la NIC, il peut indiquer avec une raison quel composant un paquet a atteint et où il a été abandonné
    pin["Paquet"] --> p1["Capturé au point 1"]
    p1 --> p2["Capturé au point 2"]
    p2 --> p3["Abandonné au point 3"]
    p3 -.-> rz["Indique le lieu d'abandon et la raison d'abandon"]
    rz -.-> ex["Par exemple MTU mismatch ou VLAN filter"]

Figure 5 : Parce qu’il capture en plusieurs points à l’intérieur de la pile, vous apprenez jusqu’où le paquet est allé et où il a été abandonné, avec une raison.

Vérifier d’abord les compteurs, puis le journal texte si besoin

• pktmon list montre la liste et les ID des composants réseau qui peuvent être surveillés (NIC, pile de protocoles, pilotes de filtre, etc.).
• pktmon counters --drop-reason liste les compteurs de passage/abandon par composant et la raison d’abandon la plus récente. C’est un premier tri commode avant d’analyser le journal.¹¹
• Convertir en texte avec pktmon etl2txt sort les paquets abandonnés étiquetés drop et un dropReason.⁴

Le soupçon « peut-être que l’OS l’abandonne quelque part avant qu’il n’atteigne l’application » n’est pas tranché en fixant Wireshark. Par exemple, cette fonction est efficace pour isoler le cas où le pare-feu abandonne le trafic à cause d’une règle entrante défectueuse (« Le pare-feu Windows et les applications métier »).

Resserrer le point de capture avant de passer à Wireshark

pktmon enregistre le même paquet en plusieurs points à l’intérieur de la pile. Si vous convertissez en pcapng tel quel, le même paquet peut apparaître en double, parce que pcapng ne reprend pas l’information sur quel composant l’a capturé.

Si le but est de lire dans Wireshark, resserrez le point avec --component-id sur pktmon etl2pcap lors de la conversion. Une autre option est de ne mettre que les abandons dans un fichier séparé avec --drop-only.¹

flowchart TB
    accTitle: Pourquoi le même paquet apparaît en double après conversion pcapng
    accDescr: Montre que pktmon enregistre le même paquet en plusieurs points à l'intérieur de la pile et que pcapng ne reprend pas quel composant l'a capturé, donc les paquets peuvent apparaître en double, et que la pratique standard est de resserrer le point avec component-id ou de ne mettre que les abandons dans un fichier séparé avec drop-only lors de la conversion
    same["Le même paquet enregistré en 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 en double"]
    dup --> c1["Resserrer le point avec --component-id"]
    dup --> c2["Fichier séparé avec --drop-only"]

Figure 6 : Parce que l’information de point de capture n’est pas reprise dans pcapng, la pratique standard est de resserrer le point avant de convertir.

4. netsh trace en pratique — scénarios, ETL et capture à travers un redémarrage

netsh trace est un mécanisme de collecte de traces présent dans Windows plus longtemps que pktmon. Sa particularité est qu’une unité appelée « scénario » active, d’un coup, l’ensemble des fournisseurs ETW liés à ce problème.⁸

:: Lister les scénarios disponibles et vérifier les fournisseurs qu'un scénario contient
netsh trace show scenarios
netsh trace show scenario netconnection

:: Démarrer la capture. Inclut la capture de paquets, tampon circulaire de 1 Go
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: Reproduire l'événement, puis arrêter (la fusion prend un peu de temps)
netsh trace stop

Conditions de capture à décider pour netsh trace

Ajouter capture=yes pour garder aussi les paquets

Ajouter capture=yes active la capture de paquets, et un filtre de capture tel que ipv4.address=192.168.10.20 resserre la cible. netsh trace show capturefilterHelp liste les filtres disponibles.⁸

Les informations d’environnement .cab sont conservées à côté de l’ETL

L’arrêt génère un fichier .cab en plus du fichier ETL. Le .cab contient des informations système telles que la configuration des adaptateurs et la build de l’OS, donc il sert aussi de collecte d’informations d’environnement.⁸

Vérifier s’il existe une session avant de démarrer

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 n’est encore en cours.⁸

Utiliser persistent=yes pour les événements juste après un redémarrage

Ajouter persistent=yes maintient la session à travers un redémarrage. Pour les événements que vous ne pouvez pas commencer à capturer manuellement à temps, tels que « la communication échoue seulement un instant juste après un redémarrage » ou « la connexion du service échoue au démarrage », netsh trace est la seule option.⁷

flowchart TB
    accTitle: Capture par scénario avec netsh trace
    accDescr: Montre le flux dans lequel démarrer avec un scénario active un ensemble groupé de fournisseurs ETW, ajouter capture=yes capture aussi les paquets, et arrêter génère un fichier ETL et un fichier .cab
    sc["Démarrer avec un scénario"] --> pv["Activer les fournisseurs groupés"]
    sc -->|capture=yes| pc["Capturer aussi les paquets"]
    pv --> re["Reproduire l'événement"]
    pc --> re
    re --> sp["Arrêter avec stop"]
    sp --> etl["Fichier ETL"]
    sp --> cab[".cab (informations système)"]

Figure 7 : Démarrer avec un scénario active d’un coup les fournisseurs groupés, et arrêter génère l’ETL et le .cab.

4.1. Rendre l’ETL lisible dans Wireshark — etl2pcapng

L’ETL de netsh trace ne peut pas s’ouvrir dans Wireshark tel quel. etl2pcapng, un 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

Pendant la conversion, etl2pcapng écrit l’identifiant de processus impliqué avec chaque paquet comme commentaire de paquet. Parce que vous pouvez vérifier « à quel processus appartient ce trafic » dans Wireshark, cela aide à isoler les problèmes dans des environnements où plusieurs applications sur le même serveur communiquent.²

Les paquets et les événements internes Windows se lisent différemment

Notez que le côté événements ETW (les événements internes Windows enregistrés par les fournisseurs du scénario) n’est pas converti en pcapng. Pour lire aussi les événements, convertissez avec netsh trace convert input=C:\temp\nettrace.etl en texte ou un autre format, ou ouvrez le fichier dans Windows Performance Analyzer ou un outil similaire.⁷³

flowchart TB
    accTitle: Lire un ETL netsh trace se fait de deux façons
    accDescr: Montre que les paquets de l'ETL sont convertis en pcapng avec etl2pcapng et lus dans Wireshark, tandis que les événements ETW ne sont pas convertis en pcapng et se lisent 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["Identifiant de processus conservé comme commentaire"]
    ev -.-> no["Non converti en pcapng"]
    no --> alt["Lire avec convert ou WPA"]

Figure 8 : Les paquets de l’ETL sont convertis en pcapng et lus ; les événements ETW se lisent par d’autres moyens.

5. Introduction à la lecture dans Wireshark — filtres d’affichage et analyse TCP

L’analyse avance dans cet ordre : resserrer la cible, vérifier la forme de la conversation TCP, puis regarder la conversation entière si besoin. Ouvrez d’abord le pcapng et coupez le bruit avec un filtre d’affichage.¹²¹³

Resserrer ce que vous lisez avec un filtre d’affichage

tcp.analysis.* sont des drapeaux d’analyse que Wireshark pose automatiquement en suivant les numéros de séquence TCP. Retransmissions, ACK en double, segments hors ordre, ZeroWindow, etc. sont repérés mécaniquement, donc taper d’abord tcp.analysis.flags pour lister les « endroits suspects » est la façon standard de commencer à lire.¹³

Découper un timeout en quatre points de contrôle

Une fois que tcp.analysis.flags vous a indiqué quelque part, vérifiez dans l’ordre suivant. En particulier, une retransmission est l’observation « aucun ACK n’est revenu », donc il importe de ne pas décider d’un seul côté si la direction sortante ou le retour a été perdu.

1. La connexion a-t-elle été établie : SYN, SYN/ACK, ACK

La poignée de main en trois temps s’est-elle achevée ? Les trois SYN, SYN/ACK et ACK sont-ils présents ? Si des SYN se répètent sans réponse, le paquet n’a pas atteint le pair ou a été abandonné silencieusement en chemin (le schéma typique du pare-feu).

2. A-t-elle été coupée de force : quand le RST est venu et qui l’a envoyé

Quel côté a envoyé le RST ? Un RST immédiat en réponse à un SYN signifie que rien n’écoute sur le port de destination ; un RST après établissement signifie qu’un côté a coupé la connexion de force. L’IP source du RST est une preuve directe de « quel côté a coupé ».

3. Les ACK reviennent-ils : retransmissions qui continuent

Les retransmissions continuent-elles ? La retransmission répétée du même segment est le signe que l’émetteur ne reçoit pas d’accusés de réception (ACK). Si les données sortantes ont été perdues ou si l’ACK de retour a été perdu ne peut pas se trancher d’une capture d’un seul côté (c’est exactement pourquoi « capturer des deux côtés » au chapitre suivant compte). Retransmissions et timeouts sont examinés en profondeur dans « Pourquoi les retransmissions TCP bloquent la communication d’une caméra industrielle, et comment isoler la cause ».

4. Le récepteur est-il saturé : ZeroWindow

ZeroWindow apparaît-il ? C’est le signe que l’application réceptrice ne lit pas les données 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 plutôt que le réseau (« Le malentendu selon lequel TCP renvoie les données dans les mêmes unités que Send »).

flowchart TB
    accTitle: L'ordre des formes à chercher dans une enquête de timeout
    accDescr: Le flux de vérification, dans l'ordre, si la poignée de main en trois temps s'est achevée, si un RST est présent et qui l'a envoyé, si les retransmissions continuent, et si ZeroWindow apparaît, pour resserrer la cause
    hs{"Le SYN a-t-il eu une réponse ?"} -->|Non| ng["Soupçonner qu'il n'est jamais arrivé et a été abandonné (pare-feu typique)"]
    hs -->|Oui| rs{"Un RST est-il présent ?"}
    rs -->|Oui| who["L'émetteur du RST est le côté qui a coupé"]
    rs -->|Non| rt{"Les retransmissions continuent-elles ?"}
    rt -->|Oui| ack["Signe que les ACK ne reviennent pas"]
    rt -->|Non| zw{"ZeroWindow apparaît-il ?"}
    zw -->|Oui| app["Signe que l'application réceptrice ne lit pas"]

Figure 9 : Chercher des formes dans l’ordre poignée de main, RST, retransmission, ZeroWindow resserre où enquêter ensuite.

Quand il y a beaucoup de trafic, d’abord une vue d’ensemble depuis les statistiques

Avant de lire paquet par paquet, il est aussi efficace de trouver la conversation et la plage horaire que vous voulez via les statistiques.

flowchart TB
    accTitle: Obtenir une vue d'ensemble depuis les statistiques, puis resserrer vers la conversation
    accDescr: Montre le flux de lister dans Conversations quel trafic a parlé quand et combien pour identifier la conversation voulue, d'utiliser le I/O Graph pour trouver la plage horaire qui s'est tue, de filtrer vers seulement la conversation cible, et de la lire de bout en bout dans un flux TCP
    ov["Vue d'ensemble depuis les statistiques"] --> cv["Lister les conversations dans Conversations"]
    ov --> io["Voir le volume de trafic dans le I/O Graph"]
    cv --> flt["Filtrer vers seulement la conversation voulue"]
    io -.-> mute["Montre l'heure où cela s'est tu"]
    flt --> fs["Lire de bout en bout dans le flux TCP"]

Figure 10 : Avant de lire paquet par paquet, obtenez une vue d’ensemble depuis les statistiques, resserrez vers la conversation voulue, puis lisez-la de bout en bout.

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

Essayer d’enquêter sur la communication entre applications sur le même PC — par exemple une connexion d’une application métier vers un service intermédiaire à localhost:8080 — et buter 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 pas par une NIC physique ; il est renvoyé sur le chemin de bouclage à l’intérieur de l’OS. Une capture normale qui cible un adaptateur physique ne le voit jamais.⁹

flowchart TB
    accTitle: Pourquoi le trafic vers localhost n'apparaît pas dans une capture
    accDescr: Montre que le trafic vers localhost ne passe pas par une NIC physique et est renvoyé sur le chemin de bouclage à l'intérieur de l'OS, donc il n'apparaît pas dans une capture normale qui cible un adaptateur physique
    app["Application"] --> stack["Pile réseau"]
    stack -->|vers des hôtes externes| nic["NIC physique"]
    nic --> seen["Apparaît dans une capture normale"]
    stack -->|vers localhost| lo["Renvoyé à l'intérieur de l'OS"]
    lo -.-> miss["N'apparaît pas dans une capture normale"]
    lo -.-> alt["Capturer avec le bouclage Npcap ou pktmon"]

Figure 11 : Le trafic vers localhost est renvoyé avant la NIC, donc il n’apparaît jamais dans une capture d’un adaptateur physique.

Faire correspondre la méthode de capture au chemin de bouclage

Il y a deux remèdes.

• Lorsque vous capturez avec Wireshark : sélectionnez l’« Adapter for loopback traffic capture » fourni par Npcap comme cible de capture. L’installateur Windows de Wireshark (3.0 et ultérieur) inclut Npcap, donc tout environnement qui a Wireshark peut l’utiliser sans travail supplémentaire.⁹
• Lorsque vous capturez avec les outils intégrés : pktmon capture en plusieurs points à l’intérieur de la pile réseau plutôt qu’à l’extérieur de la NIC,⁵ donc il peut aussi observer le trafic de bouclage. Pour en être sûr, avant de mettre en place l’attente de la vraie reproduction, confirmez dans cet environnement avec l’affichage temps réel de pktmon start -c -m real-time que le trafic de bouclage que vous visez est réellement visible.

Deux mélanges existent aussi dans la façon de spécifier l’adresse

localhost ne signifie pas forcément 127.0.0.1

« localhost » est parfois résolu en IPv6 ::1. Le schéma est que l’application se connecte à IPv6 ::1 tandis que l’enquêteur ne regarde que 127.0.0.1 (IPv4) et conclut à tort « il n’y a pas de trafic ». Soit posez le filtre d’affichage pour les deux, comme dans ip.addr == 127.0.0.1 || ipv6.addr == ::1, soit indiquez la cible de connexion de l’application explicitement comme une adresse.⁹

Spécifier sa propre IP réelle ne passe pas forcément par la NIC physique

Le trafic vers votre propre adresse IP réelle ne sort pas non plus sur le fil. Lorsque le même PC se connecte de 192.168.10.5 vers 192.168.10.5, le trafic est renvoyé à l’intérieur de l’OS même si la destination est l’IP réelle. Souvenez-vous que « cela utilise l’IP réelle, donc cela doit passer par la NIC » n’est pas forcément vrai.

flowchart TB
    accTitle: Le mélange de localhost qui se résout en IPv6
    accDescr: Montre que le localhost d'une application est parfois résolu en IPv6 ::1 et connecté là, et qu'un enquêteur qui ne regarde que 127.0.0.1 conclut à tort qu'il n'y a pas de trafic, donc posez le filtre d'affichage pour les deux ou indiquez la cible explicitement comme une adresse
    app["L'application se connecte à localhost"] --> v6["En réalité résolu 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["Poser le filtre pour les deux adresses"]
    none --> fix2["Indiquer la cible explicitement comme une adresse"]

Figure 12 : Méfiez-vous du mélange où localhost se résout en ::1 et, en ne regardant que 127.0.0.1, vous concluez à tort qu’il n’y a pas de trafic.

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

Ce qu’un côté vous donne, ce sont les faits tels que vus depuis ce point de capture. Choisissez le lieu de capture selon que vous voulez d’abord le tableau d’ensemble ou déterminer si le trafic a disparu sur le chemin sortant ou sur le retour.

Même lorsque les retransmissions continuent côté client, un seul côté ne peut pas distinguer les deux cas suivants.

• Le paquet que vous avez envoyé a disparu avant d’atteindre le serveur.
• Le paquet a atteint le serveur, mais la réponse a disparu sur le chemin du retour.

Capturer des deux côtés et les corréler tranche quel côté s’est tu, comme dans « le client l’a envoyé, le serveur ne l’a jamais reçu ». Lorsque vous devez trancher la délimitation de responsabilité (l’application, l’OS, l’équipement réseau, le pair), organisez une capture des deux côtés dès le départ.

flowchart TB
    accTitle: Ce que disent la capture d'un côté et des deux côtés
    accDescr: Montre qu'une capture d'un seul côté ne peut pas distinguer si le paquet sortant a disparu ou si la réponse de retour a disparu, tandis que capturer des deux côtés et les corréler tranche quel côté s'est tu
    one["Capturer d'un seul côté"] --> fact["Seulement les faits tels que vus depuis votre position"]
    fact --> und["Impossible de dire si le sortant ou le retour a été perdu"]
    both["Capturer des deux côtés à la fois"] --> mt["Corréler"]
    mt --> fix["Tranche quel côté s'est tu"]
    mt -.-> pre["Le préalable est la synchronisation d'horloge des deux machines"]

Figure 13 : Un côté ne montre que les faits qu’il a vus ; seule la corrélation des deux côtés tranche la délimitation de responsabilité.

7.1. La corrélation exige des horloges synchronisées

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

:: Vérifier l'état de synchronisation de l'heure (source et dernière synchronisation)
w32tm /query /status

:: Mesurer le décalage d'horloge par rapport au serveur pair (5 échantillons)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchart affiche le décalage d’heure entre votre machine et l’ordinateur pair, et vous donne la base d’une correction telle que « l’horloge côté serveur était décalée de +0,8 seconde » lors de la corrélation.¹⁴ Dans un environnement avec un grand décalage, corriger d’abord la synchronisation d’heure puis capturer est le raccourci au bout du compte.

flowchart TB
    accTitle: Vérifier le décalage d'horloge avant de corréler
    accDescr: Montre le flux de vérifier l'état de synchronisation de sa propre heure avec w32tm, de mesurer et d'enregistrer le décalage d'horloge par rapport au serveur pair avec stripchart, et d'utiliser ce décalage comme base de correction lors de la corrélation, et que dans un environnement avec un grand décalage vous corrigez d'abord la synchronisation puis capturez
    st["Vérifier l'état de synchronisation avec query"] --> mc["Mesurer le décalage d'horloge avec stripchart"]
    mc --> rc["Enregistrer le décalage"]
    rc --> use["Base de correction lors de la corrélation"]
    mc -.-> big["Si le décalage est grand, corriger d'abord la synchronisation"]

Figure 14 : Mesurez et enregistrez le décalage d’horloge avant de capturer, et utilisez-le comme base de correction lors de la corrélation.

7.2. Un tampon circulaire pour « nous ne savons pas quand cela arrive »

Pour un événement aux conditions de reproduction inconnues, l’approche de base est de continuer à capturer dans un tampon circulaire et d’arrêter lorsqu’il se produit.

• pktmon : le mode circular est le défaut. Spécifiez la limite (Mo) avec --file-size, et les paquets les plus anciens sont écrasés en premier.⁶
• netsh trace : spécifiez-le comme maxSize=1024 filemode=circular.⁷
• Wireshark : Capture > Options > Output permet de configurer « plusieurs fichiers plus tampon circulaire ». Il tourne par taille de fichier ou par temps et ne conserve que les N fichiers les plus récents, donc il peut tourner longtemps avec un plafond d’usage disque.¹⁵

Décider non seulement la capacité mais aussi comment arrêter après l’événement

Dans tous les cas, partagez avec le personnel sur site la pratique de noter l’heure d’occurrence avant d’arrêter la capture une fois l’événement arrivé. Plus un tampon circulaire attend longtemps, plus il perd du passé, donc si la procédure de l’occurrence à l’arrêt est longue, l’intervalle critique se fait écraser.

flowchart TB
    accTitle: Attendre avec un tampon circulaire
    accDescr: Montre la pratique de laisser une capture tourner dans un tampon circulaire pour un événement aux conditions de reproduction inconnues, de noter l'heure d'occurrence lorsque l'événement arrive et d'arrêter promptement, et que si l'arrêt est retardé les paquets les plus anciens sont écrasés en premier et l'intervalle critique est perdu
    st["Démarrer la capture dans un tampon circulaire"] --> wt["Continuer à capturer et attendre"]
    wt --> ev["L'événement se produit"]
    ev --> memo["Noter l'heure d'occurrence"]
    memo --> sp["Arrêter promptement"]
    wt -.-> ow["Les paquets les plus anciens sont écrasés en premier"]
    ow -.-> late["Si l'arrêt est retardé l'intervalle critique est perdu"]

Figure 15 : Un tampon circulaire perd plus du passé plus il attend longtemps, donc notez l’heure d’occurrence et arrêtez promptement.

8. Lorsque TLS cache le contenu — ce que l’on peut encore apprendre

Vérifier le squelette de la conversation avant de déchiffrer

La plupart des communications métier d’aujourd’hui sont en TLS (HTTPS). Le réflexe est de supposer « si c’est chiffré, capturer ne sert à rien », mais la plupart de ce que vous voulez savoir dans une enquête de timeout reste visible même avec le trafic laissé chiffré.

• Si la connexion TCP a été établie (la poignée de main en trois temps)
• Jusqu’où la poignée de main TLS est allée — si un ServerHello est revenu pour le ClientHello, si la connexion a été coupée pendant la poignée de main par un RST ou une alerte
• Le nom d’hôte de destination porté dans le ClientHello (SNI) et la version TLS négociée
• Après établissement, quel côté a cessé d’envoyer. Où est le silence, les retransmissions, un RST, ou une fermeture normale (FIN)

Autrement dit, isoler « impossible de se connecter », « coupé en cours de route » et « pas de réponse » n’a presque jamais besoin du contenu déchiffré. Ce que le chiffrement retire, c’est « ce qui a été dit » ; « qui s’est tu et quand » reste.

flowchart TB
    accTitle: Ce qu'une capture TLS montre et ce qu'elle ne montre pas
    accDescr: Montre que le chiffrement ne cache que le contenu des données applicatives, tandis que l'établissement de connexion TCP, le succès ou non de la poignée de main TLS, le SNI et la version TLS, les RST, et quel côté s'est tu sont visibles avec le trafic laissé chiffré
    tls["Capture de trafic TLS"] --> vis["Visible"]
    tls --> hid["Non visible"]
    vis --> v1["Établissement de connexion TCP"]
    vis --> v2["Succès ou échec TLS et SNI"]
    vis --> v3["RST et quel côté s'est tu"]
    hid --> h1["Contenu des données applicatives"]

Figure 16 : Le chiffrement ne retire que le contenu ; le squelette de la conversation peut encore se lire avec TLS tel quel.

Vérifier si le déchiffrement est possible seulement lorsque vous avez besoin du contenu

Si vous avez encore besoin du contenu, Wireshark peut déchiffrer TLS à l’aide des clés de session écrites via la variable d’environnement SSLKEYLOGFILE. Toutefois, seules certaines implémentations le prennent en charge, telles que les navigateurs Firefox, Chrome et Edge fondé sur Chromium et les bibliothèques fondées sur OpenSSL ; SChannel intégré à Windows (applications qui utilisent WinHTTP ou WinINET) ne prend pas en charge ce mécanisme.¹⁰ Parce que les clés de session sont écrites dans un fichier, ce qui signifie que quiconque obtient ce fichier peut déchiffrer tout le trafic, cela doit être positionné non comme quelque chose à utiliser en production, mais comme un outil de reproduction et de débogage dans un environnement de développement.

flowchart TB
    accTitle: Comment fonctionne le déchiffrement via SSLKEYLOGFILE et ses limites
    accDescr: Montre que les clés de session écrites via SSLKEYLOGFILE permettent à Wireshark de déchiffrer TLS, mais que seules certaines implémentations telles que Firefox et la famille Chrome le prennent en charge et que SChannel ne le prend pas, et que parce que quiconque détient le fichier de clés peut déchiffrer le trafic c'est une technique pour les environnements de développement seulement
    env["Définir SSLKEYLOGFILE"] --> key["Clés de session écrites dans un fichier"]
    key --> ws["Déchiffrer et lire dans Wireshark"]
    key -.-> risk["Quiconque détient les clés peut tout déchiffrer"]
    risk -.-> dev["Le positionner comme environnements de développement seulement"]
    env -.-> sup["Pris en charge seulement par certaines implémentations TLS"]
    sup -.-> sch["SChannel n'est pas pris en charge"]

Figure 17 : Écrire les clés de session permet le déchiffrement, mais les implémentations prises en charge sont limitées, et par la nature des clés c’est une technique réservée aux environnements de développement.

Notez que pour le trafic via un proxy d’entreprise, la destination vue dans la capture est le serveur proxy, et le TLS circule à l’intérieur d’un tunnel CONNECT. La question préalable de vers quel proxy l’application se dirige d’abord est organisée dans l’article compagnon publié le même jour, « Proxy d’entreprise et applications Windows — démêler la résolution de proxy dans WinINET, WinHTTP et .NET ».

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

Une capture seule produit rarement une conclusion, en réalité. Ce qui tranche l’affaire en pratique, c’est placer une ligne du journal applicatif et un aller-retour de paquets sur le même axe temporel.

Remplacer une ligne de journal par les faits observés dans les paquets

D’abord, à partir de l’heure où l’exception s’est produite, trouvez l’intervalle dans lequel la communication a commencé.

Étape 1 : Trouver l’heure de début d’après l’heure d’exception et la valeur de timeout

Identifiez l’heure de l’événement d’après 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 vers 10:23:11.

Étape 2 : Passer Wireshark en affichage date-et-heure et resserrer vers cet intervalle

Passez l’affichage d’heure de Wireshark avec Affichage > Format d’affichage de l’heure > Date et heure du jour, et resserrez vers l’intervalle avec un filtre d’affichage (vous pouvez aussi resserrer par l’heure, comme dans frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00").

Étape 3 : Vérifier la poignée de main, RST, retransmissions et ZeroWindow

Dans cet intervalle, vérifiez dans l’ordre du chapitre 5 (poignée de main, RST, retransmissions, ZeroWindow). Une fois que vous pouvez corréler jusqu’à « un SYN a été envoyé 30 secondes avant l’heure de timeout du journal, suivi seulement de retransmissions SYN », le « timeout » du journal devient le fait observé « aucune réponse du tout n’est revenue à ce point de capture » (si le SYN n’a jamais atteint le pair ou si la réponse SYN/ACK a été perdue sur le retour ne peut pas se trancher depuis ce seul point de capture ; pour le trancher, corrélez avec une capture côté serveur).

Étape 4 : Corriger le décalage d’horloge et le fuseau horaire

Corrigez toujours le décalage entre l’heure de la capture et l’heure du journal (le décalage d’horloge mesuré à la section 7.1, et la notation de fuseau horaire du journal). Une erreur de corrélation de quelques secondes vous fait accuser la mauvaise communication.

flowchart TB
    accTitle: La procédure pour corréler le journal applicatif avec les paquets
    accDescr: Montre la procédure d'identifier l'heure de l'événement d'après le journal applicatif, de remonter à l'heure de début d'après la valeur de timeout, de resserrer vers cet intervalle dans Wireshark et de vérifier les formes dans l'ordre, et de corriger le décalage d'horloge pour tout aligner sur le même axe temporel
    lg["1. Identifier l'heure de l'événement dans le journal"] --> rev["Remonter au début d'après la valeur de timeout"]
    rev --> flt["2. Resserrer vers l'intervalle avec un filtre d'affichage"]
    flt --> chk["3. Vérifier les formes dans l'ordre du chapitre 5"]
    chk --> adj["4. Corriger le décalage d'horloge"]
    adj --> done["L'entrée de journal d'un mot devient un fait observé"]

Figure 18 : Resserrer vers l’intervalle d’après l’heure du journal, vérifier les formes, corriger le décalage d’horloge, et tout aligner sur le même axe.

Avant de le transmettre à un tiers, extraire seulement la conversation dont vous avez besoin

Lorsque vous transmettez 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 transmettre est à la fois une courtoisie et une mesure de sécurité. Resserrer vers seulement la conversation cible avec un filtre d’affichage dans Wireshark, puis enregistrer avec Fichier > Exporter les paquets spécifiés, en choisissant seulement les paquets « Affichés », et vous obtenez un petit pcapng contenant seulement la plage dont vous avez besoin.

Décider comment les données confidentielles sont stockées et supprimées avant de capturer

Un fichier de capture contient la communication elle-même. Il peut inclure des informations d’identification de protocoles en clair, des cookies HTTP et des clés API, le contenu d’e-mails et de formulaires, et des informations personnelles. Décidez les trois points suivants en même temps que la procédure de capture.

• Capture au minimum nécessaire : resserrez la cible avec des filtres avant capture (chapitres 3 et 4) et gardez la fenêtre temporelle minimale. Ne faites pas « tout prendre » dans un environnement client
• Resserrement avant transmission : exportez seulement la conversation cible et n’incluez pas le trafic de tiers sans rapport. Si des parties confidentielles restent, convenez avec le destinataire d’un masquage ou d’un autre moyen de livraison
• Stockage et suppression : décidez où les fichiers de capture sont stockés, pendant combien de temps, et comment ils sont supprimés, et supprimez-les lorsque l’enquête est terminée

flowchart TB
    accTitle: Trois décisions avant de transmettre un fichier de capture
    accDescr: Montre que parce qu'une capture contient la communication elle-même, trois points sont décidés en même temps que la procédure de capture, la garder au minimum avec des filtres avant capture et la fenêtre temporelle, extraire seulement la conversation cible avant de transmettre et n'inclure aucun trafic sans rapport, et décider l'emplacement de stockage et la durée de conservation et supprimer après la fin de l'enquête
    cap["Une capture contient la communication elle-même"] --> p1["Capturer le minimum nécessaire"]
    cap --> p2["Extraire seulement la cible avant de transmettre"]
    cap --> p3["Fixer une durée de conservation et supprimer"]
    p2 -.-> exp["Resserrer avec un filtre d'affichage et exporter"]

Figure 19 : Décidez capture minimale, resserrement avant transmission, et stockage et suppression en même temps que la procédure de capture.

10. Synthèse

• Un cran sous le « timeout » du journal applicatif se trouve un fait : les paquets réellement passés sur le fil. Si le SYN n’a pas eu de réponse, si la connexion a été coupée par un RST, si les retransmissions ont continué, ou si ZeroWindow est apparu change où vous enquêtez ensuite.
• Même sur les sites où Wireshark ne peut pas être installé, vous pouvez capturer avec pktmon et netsh trace intégrés à Windows. Le partage de base est de capturer avec les outils intégrés et de lire dans Wireshark sur votre propre machine.
• pktmon tient en quatre étapes : enregistrer un filtre, pktmon start --capture, pktmon stop, pktmon etl2pcap. Par défaut les paquets sont tronqués à 128 octets, donc n’oubliez pas --pkt-size 0 si vous voulez lire le contenu. Savoir où et pourquoi un paquet a été abandonné est une force que seul pktmon a.
• netsh trace capture avec un scénario qui regroupe des fournisseurs ETW, et persistent=yes lui permet de traverser un redémarrage. Convertissez l’ETL en pcapng avec etl2pcapng pour le lire.
• Dans Wireshark, commencez à lire depuis tcp.analysis.flags et cherchez des formes dans l’ordre poignée de main, RST, retransmissions, ZeroWindow. Obtenir une vue d’ensemble avec Conversations et le I/O Graph avant de resserrer est plus rapide.
• Le trafic vers localhost ne passe pas par la NIC, donc il ne peut pas se 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 corréler tranche « quel côté s’est tu ». Le préalable est la synchronisation d’heure (w32tm). Pour les événements aux conditions de reproduction inconnues, attendez avec un tampon circulaire.
• Même avec TLS, le squelette de la conversation est visible. Positionnez le déchiffrement (SSLKEYLOGFILE) comme une technique réservée aux environnements de développement, et traitez le fichier de capture lui-même comme confidentiel, en intégrant capture minimale, resserrement et suppression à votre pratique.

La capture de paquets tend à être pensée comme « un outil pour les spécialistes réseau », mais en réalité c’est un outil d’enquête côté application, qui ne devient significatif que lorsqu’il est corrélé 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
• Proxy d’entreprise et 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 bogues liés à la communication telles que « la communication de l’application métier échoue occasionnellement et nous ne savons pas pourquoi » et « nous voulons isoler une erreur de connexion qui ne se produit que dans l’environnement du client ». Nous couvrons toute la chaîne, de la conception de la capture (où, quoi et combien capturer) à l’analyse dans Wireshark, la corrélation avec le journal applicatif, et la correction de l’application elle-même.

• 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ù je ne peux pas installer Wireshark ?

Utilisez les outils Windows intégrés pktmon ou netsh trace, et vous pouvez capturer sans installer de logiciel supplémentaire. Avec pktmon, enregistrez un filtre dans un terminal élevé, démarrez la capture avec pktmon start --capture, et arrêtez-la avec pktmon stop. Le fichier ETL obtenu peut être converti en pcapng avec pktmon etl2pcap, donc vous pouvez le ramener chez vous et l'analyser dans Wireshark sur votre propre machine. Le partage « capturer avec l'outil intégré, lire avec Wireshark » est le schéma de base sur les sites à restrictions d'installation.

Faut-il utiliser pktmon ou netsh trace ?

Si l'OS a pktmon (Windows 10 / Windows Server 2019 et ultérieur), pktmon est le point de départ recommandé. Ses commandes sont simples, il peut indiquer quel composant de la pile réseau a abandonné un paquet (la raison d'abandon), et la conversion pcapng est autonome. netsh trace a l'avantage lorsque vous capturez sur un OS plus ancien qui n'a pas pktmon, lorsque vous voulez aussi collecter des événements ETW de composants Windows sous forme de scénario, ou lorsque vous voulez que la capture survive à un redémarrage avec persistent=yes. Les documents de dépannage Microsoft recommandent aussi cet ordre : pktmon d'abord, puis netsh trace si cela ne suffit pas.

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

Le trafic vers localhost ne passe pas par une NIC physique ; il est renvoyé sur le chemin de bouclage à l'intérieur de l'OS. Une capture normale qui cible un adaptateur physique ne le voit jamais. Dans Wireshark, sélectionnez l'« Adapter for loopback traffic capture » fourni par Npcap et vous pouvez capturer le trafic de bouclage. pktmon capture à l'intérieur de la pile réseau, donc il peut aussi observer le trafic de bouclage. Un autre mélange fréquent est que localhost se résout en IPv6 ::1, donc l'écran que vous regardiez pour 127.0.0.1 ne montre rien. Confirmez avec l'adresse indiquée explicitement.

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

Les données applicatives elles-mêmes sont chiffrées et ne peuvent pas être vues. Toutefois, le squelette de la conversation — établissement et fermeture de connexion TCP, succès ou non de la poignée de main TLS, une fermeture RST, et quel côté a cessé de répondre — reste visible même chiffré, donc la plupart des enquêtes d'expiration peuvent avancer en laissant TLS tel quel. Si vous avez besoin du contenu, le déchiffrement via SSLKEYLOGFILE est une option, mais seules certaines implémentations TLS comme Firefox et la famille Chrome le prennent en charge ; SChannel intégré à Windows ne le prend pas. Parce que le mécanisme écrit des matériels de clé secrète, traitez-le comme quelque chose pour les environnements de développement seulement, si vous l'utilisez.

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 informations d'identification de protocoles en clair, des cookies, des clés API et des informations personnelles. D'abord, resserrez le filtre et la fenêtre temporelle au moment de la capture au minimum nécessaire, et avant de le transmettre, extrayez seulement la conversation cible avec un filtre d'affichage Wireshark et exportez. Pour ce qui reste, convenez avec le destinataire de la façon de traiter les parties confidentielles (masquage, ou livraison par un autre moyen) avant d'envoyer. Décidez à l'avance combien de temps les fichiers de capture seront conservés et quand ils seront supprimés.

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.