Êtes-vous nouveau sur les captures de paquets Wireshark?
J’y étais – j’ai reçu mes premières captures de paquets et on m’a demandé de les analyser.
Croyez-moi! Avoir cette compétence – être capable de dire où se trouve le problème en lisant une capture de paquets est un plus pour vous. Maintenant et à l’avenir!
Après un certain temps, vous avez une idée des premières étapes à faire avec Wireshark et de la façon de donner un premier feedback.
Utilisez un profil Wireshark personnalisé
Lorsque j’étais nouveau sur Wireshark et que je n’avais jamais analysé de captures de paquets auparavant, j’étais perdu.
Je me souviens de l’époque car l’analyse de paquets est devenue un rôle important en tant qu' »Ingénieur en fiabilité de site ». Et je n’étais pas prêt.
Wireshark ouvre votre fichier avec le profil « Par défaut » qui contient les colonnes de base Numéro de paquet, Heure, Source, Destination, Protocole, Longueur, Informations.
Au fil du temps, j’ai compris qu’avoir plus de colonnes disponibles dès le début, cela économiserait du temps et aiderait également au dépannage.
Comme vous pouvez le voir sur la capture d’écran, j’ai ajouté plusieurs colonnes. Certains d’entre eux sont très importants:
- Delta Time = > Il affiche le temps delta du paquet capturé précédent
- Octets en vol = > Données qui ont été envoyées mais pas encore acquittées
- Numéro de séquence
- Numéro reconnu
- Numéro de séquence suivant
L’ajout de ces colonnes m’a aidé à gagner du temps dans l’analyse!
Obtenez les premières informations de la prise de contact à 3 voies
La prise de contact à 3 voies est l’étape la plus importante de TCP pour établir une communication entre le client et le serveur.
Voici un bref récapitulatif de l’apparence de la poignée de main:
- Le Client envoie un paquet SYN avec son Numéro de Séquence Initial au Serveur
- Le Serveur accuse réception (ACK) du paquet SYN (du Client) et envoie son propre paquet SYN avec son Numéro de Séquence Initial
- Le Client accuse réception (ACK) du paquet SYN (du Serveur)
- Maintenant, la communication TCP est établie et capable d’échanger des données
Au cours de la poignée de main à 3 voies, il y a beaucoup d’informations utiles échangées entre le Client et le Serveur.
À côté de l’IP Source, de l’IP de Destination, du Port Source, du Port de Destination, du MAC Source, du MAC de Destination, vous pouvez également obtenir:
- RTT = > Temps de trajet aller-retour entre le Client et le Serveur
- TTL = > Temps de vie – Avec cette valeur, vous pouvez calculer le nombre de sauts entre le Client et le Serveur
- Taille de la fenêtre calculée = > La taille des données qui peuvent être reçues avant d’être acquittées
Avec seulement 3 paquets, vous pouvez obtenir un aperçu de votre communication TCP.
Filtrez vos captures de paquets à votre adresse de destination (pour les filtres nécessaires, utilisez mon Introduction à Wireshark – Partie 2) et commencez à analyser.
À partir de maintenant, j’utilise comme exemple une communication TCP entre mon client dans mon réseau privé et le tcpdump-it.com serveur (173.212.216.192).
Vérifiez combien de paquets ont été perdus
Puisque je travaille du côté de l’infrastructure, mon premier objectif est de comprendre si le réseau se comporte comme il se doit.
Lorsqu’on me demande d’analyser une capture de paquets réseau, c’est une étape obligatoire pour comprendre le pourcentage de perte de paquets (retransmissions TCP).
Pour ce faire, j’utilise le filtre d’affichage « ip.addr == 173.212.216.192 et tcp.analyse.retransmission ». Il montre tous les paquets qui ont été retransmis.
L’étape suivante consiste à ouvrir les « Propriétés du fichier de capture » sous l’onglet « Statistique ».
Dans la section Statistiques, vous pouvez voir les colonnes « Capturées » et « Affichées ».
La colonne « Affichée » est basée sur votre filtre d’affichage et affiche les statistiques par rapport aux données « capturées ».
J’ai utilisé cet exemple pour vous montrer un cas extrême. Vous pouvez voir qu’il y a 10,4% de paquets retransmis.
Cela dépend de nombreux facteurs du pourcentage de perte de paquets critique. Il y a des opinions différentes.
Probablement aucune réponse n’est correcte, mais lorsque la perte de paquets est supérieure à 1% et provoque un retard élevé dans la communication, vous devriez commencer à mieux vérifier.
Ouvrez les informations d’expert
Les informations d’expert Wiresharks sont très utiles et vous donnent une idée de ce qu’il faut vérifier dans la capture de paquets.
Dans la documentation Wireshark, vous trouverez la déclaration suivante « Prenez les informations d’experts comme indice sur ce qui vaut la peine d’être regardé, mais pas plus »
C’est exactement ce que vous devriez faire. Lorsque j’ai analysé une capture de paquets pour la première fois, les informations d’experts m’ont été très utiles et m’ont donné des conseils dans quelle direction analyser.
Allez dans l’onglet « Expert » et sélectionnez « Informations d’expert ». Une nouvelle fenêtre s’ouvrira:
Dans les versions précédentes de Wireshark (v1), l’aperçu des « Avertissements », des « Notes », des « Chats » était plus clair.
Habituez-vous à ouvrir les informations d’expert. Cela vous aidera absolument!
Ouvrez le graphique du Temps Aller-retour
Un bref récapitulatif de ce que signifie le Temps Aller-retour:
RTT signifie le temps entre l’envoi d’un paquet et le retour d’une réponse.
Pour notre analyse de capture de paquets, il est important de comprendre s’il existe des paquets avec une RTT élevée.
Cela signifierait que nous souffrions d’une communication lente.
Pour ouvrir le graphique de Temps Aller-retour, allez dans « Statistiques » > > « Graphiques de flux TCP » > > « Temps Aller-retour ».
Le graphique montre sur l’axe des ordonnées le RTT en ms tandis que l’axe des abscisses indique le temps de capture du paquet en secondes.
Ce graphique RTT dans ma capture d’écran n’est pas significatif mais semble bien avec une RTT d’environ 60 ms.
Recherchez des pointes dans l’axe des Y pour identifier les paquets lents!
Résumé
Je veux répéter ma phrase que j’ai écrite au début du post:
Avoir cette compétence – être capable de dire où se trouve le problème en lisant une capture de paquets est un plus pour vous.
Si vous considérez certaines parties de cet article, vous aurez plus de succès dans l’analyse des captures de paquets avec Wireshark!
Si vous souhaitez en savoir plus, rejoignez mon espace de travail Slack ou envoyez-moi un e-mail.
Restez à jour et abonnez-vous à ma Newsletter!