Que montre Traceroute ? Comment lire les résultats

Traceroute semble plus sûr qu'il ne l'est en réalité. Le résultat arrive sous forme de lignes numérotées bien rangées, mais ces lignes sont des observations provenant d’une série de sondes et non une carte parfaite d’Internet.

Traceroute affiche les sauts de couche 3 répondants entre une source et une destination, ainsi que des échantillons de réponse aller-retour de la source à chaque saut. Cela ne garantit pas que chaque routeur soit visible, ne mesure pas le délai entre deux sauts voisins ou ne prouve pas la perte de paquets. Une réponse vide peut simplement signifier qu'un appareil a choisi de ne pas répondre à la sonde.

Ce que traceroute montre réellement

Un traceroute classique tente de révéler le chemin, une réponse à la fois. Pour chaque saut visible, il peut signaler un numéro de saut, une adresse IP, un nom d'hôte facultatif et un ou plusieurs échantillons de temps aller-retour. Le Modèle de mesure de traceroute de l'IETF les identifie comme étant les champs de résultats communs.

Le mot prudent est répondre. Une ligne représente une interface qui a répondu à une sonde, pas nécessairement un routeur physique complet, et certainement pas tous les appareils gérant le trafic. Deux adresses au même numéro de saut peuvent être des répondeurs alternatifs sur un chemin à charge équilibrée. Une ligne manquante peut toujours transmettre parfaitement les paquets.

Il est donc préférable de lire Traceroute comme une observation de chemin provenant d'une source, à un moment donné, en utilisant une seule méthode de sonde. Exécutez-le plus tard, depuis un VPN ou depuis un autre réseau et le résultat peut changer. Il s'agit d'un comportement de routage normal, pas automatiquement d'un défaut.

La petite astuce TTL derrière chaque saut

Le mécanisme est astucieux. Dans IPv4, chaque paquet transféré comporte une valeur de durée de vie, généralement traitée comme une limite de saut. Un routeur le réduit avant le transfert. Lorsque la valeur expire, ce routeur peut renvoyer un message ICMP Time Exceeded au lieu de transmettre le paquet.

Traceroute envoie d'abord une ou plusieurs sondes avec TTL 1. Ils expirent au premier saut acheminé. L'ensemble suivant utilise TTL 2 et peut atteindre un saut plus loin. Le processus se poursuit jusqu'à ce que la destination réponde ou que l'outil atteigne son maximum configuré. IPv6 utilise un champ littéralement nommé Limite de saut, mais l'idée de découverte est similaire. Les détails du protocole sont documentés dans RFC5388 et le Spécification IPv6.

La réponse de destination dépend de la mise en œuvre. Une trace UDP traditionnelle se termine souvent lorsque la destination signale que le port choisi est inaccessible. Fenêtres tracer utilise des sondes ICMP Echo et se termine lorsque la destination répond. Des variantes basées sur TCP existent également. C'est pourquoi deux programmes traceroute peuvent effectuer le même parcours de base tout en envoyant différents types de sondes.

Comment lire une ligne de sortie

Considérons une ligne courante de style Windows avec un numéro de saut, trois valeurs de temps et une adresse. Les colonnes sont simples une fois que vous arrêtez de leur demander de faire plus qu'ils ne peuvent.

Les trois valeurs moyennes méritent une attention particulière. Ce sont trois tentatives distinctes. Microsoft les décrit comme des mesures aller-retour depuis votre appareil jusqu'à ce saut et retour dans son rapport officiel. documentation `tracert`. Il ne s’agit pas de trois étapes d’un parcours de paquet, et il ne s’agit pas d’un résumé min/moyen/max tout fait.

Un RTT inclut également le chemin de réponse et le temps de traitement au niveau du périphérique répondant. Le routage Internet peut être asymétrique, de sorte que la réponse peut revenir par un chemin différent. RFC9198 explique pourquoi ce type de timing ICMP n'est pas une estimation reproductible du retard d'une application. Traitez le numéro comme un échantillon de bout en bout entre la source et ce répondeur, et non comme un chronomètre placé sur un câble entre deux routeurs.

Les astérisques sont un silence, pas un verdict

Un astérisque signifie que la sonde n'a pas reçu de réponse avant son expiration. C'est tout ce que cela signifie en soi. Le routeur peut filtrer ce type de sonde, limiter le débit des réponses ICMP, déprioriser les réponses du plan de contrôle ou envoyer une réponse perdue au retour.

Un astérisque parmi deux temps mesurés signifie qu'une des trois sondes est restée sans réponse. Trois astérisques ou « Demande expirée » signifient qu'aucune des sondes de cette ligne n'a répondu à temps. Si les sauts ultérieurs, y compris la destination, répondent toujours, la trace continue au-delà de cette durée de vie, de sorte que la ligne silencieuse ne prouve pas un échec de transfert. Le routage multivoie signifie que ces sondes ultérieures peuvent ne pas avoir suivi exactement la même séquence de répondeurs. Le propre exemple de Microsoft montre des lignes expirées suivies d'une réponse de destination réussie.

Il s'agit d'un mauvais diagnostic courant en lecture de traceroute : traiter chaque saut silencieux comme une perte de paquets. Le transfert du trafic et la réponse aux sondes de diagnostic sont des tâches différentes. Un routeur peut effectuer la première tout en refusant la seconde.

Pour une enquête réelle sur les pertes, utilisez des mesures répétées. Sous Windows, CheminPing combine la découverte de chemins avec une série plus longue de sondes et calcule des statistiques. Même dans ce cas, la perte signalée *à* un routeur intermédiaire doit être comparée aux sauts ultérieurs avant de conclure que le trafic transféré est affecté.

Comment ne pas blâmer le mauvais routeur

La question utile n’est pas « Quelle ligne contient le plus grand nombre ? » C’est « Où commence un changement et persiste-t-il vers la destination ? »

La distance, la congestion, le Wi-Fi, le routage VPN, la file d'attente et le comportement du répondeur peuvent tous modifier le RTT. Un seul échantillon élevé est un indice et non une conviction. Recherchez un modèle répété qui se poursuit dans les sauts ultérieurs et correspond au symptôme réel de l'utilisateur.

Traceroute ne mesure pas non plus la capacité de téléchargement ou de téléchargement. Si la plainte est « la connexion est lente partout », un test de vitesse Internet vérifie plus directement le débit, la latence et la gigue. Les deux outils répondent à des questions différentes.

Ce que traceroute ne peut pas afficher de manière fiable

Traceroute donne un instantané rapide du chemin. Bien le lire signifie savoir ce que cet instantané laisse de côté.

• Il se peut qu'il ne révèle pas chaque saut de couche 3 ; certains appareils ne répondent jamais aux sondes.
• Il n’affiche normalement pas les commutateurs transparents de la couche 2. Ces appareils transfèrent les trames sans apparaître comme des sauts IP.
• Il observe le chemin de la sonde aller, tandis que chaque réponse peut emprunter un chemin de retour différent.
• Il peut échantillonner un itinéraire parmi plusieurs itinéraires à coût égal plutôt que tous les chemins possibles.
• Il n’établit pas de pourcentages stables de perte de paquets à partir d’une poignée de sondes.
• Il ne peut pas prouver le chemin que prendra chaque flux d’application, en particulier lorsque les protocoles de sonde diffèrent.
• Une adresse IP ou un nom d’hôte ne constitue pas une lecture exacte de l’emplacement physique.

Utilisez le test voisin qui correspond à la question non résolue. Si un site Web répond mais pas un service particulier, une enquête soigneusement définie contrôle portuaire peut tester les ports TCP publics sélectionnés à partir du bord ClockTools. Si des plages privées ou des limites CIDR perturbent la trace, le Calculateur de sous-réseau IP permet de séparer les parties réseau et hôte.

Types de tracert, traceroute et sonde

Windows nomme la commande tracer. macOS, Linux, BSD et de nombreux appareils réseau utilisent couramment traceroute. Le résultat semble familier sur toutes les plates-formes, mais les sondes par défaut peuvent différer.

Fenêtres tracer envoie des requêtes ICMP Echo avec des valeurs TTL croissantes. Le traceroute traditionnel de type Unix commence généralement par UDP, bien que les implémentations et les options puissent également utiliser ICMP ou TCP. Évitez la règle générale selon laquelle « traceroute utilise toujours UDP » ou « traceroute utilise toujours ICMP ». Le programme et la méthode choisie décident.

Pour une trace Windows rapide sans recherche de nom d'hôte, utilisez tracert /d exemple.com. Sur un système macOS ou Linux typique, commencez par traceroute exemple.com et lisez le manuel de ce système pour connaître les options de protocole et de délai d'attente. Le /j L'indicateur peut accélérer une trace Windows en ignorant la résolution de nom reverse-DNS, mais il ne masque pas les adresses IP dans la sortie.

Le terme chemin de trace fait généralement référence à un utilitaire de type Unix associé avec une interface et un modèle de privilèges différents. MTR et WinMTR répètent les sondes au fil du temps. PathPing ajoute des statistiques répétées après avoir découvert l'itinéraire. Choisissez parmi eux selon que vous avez besoin d'un instantané de chemin rapide ou d'une mesure soutenue.

Où ClockTools correspond

Une page de navigateur normale ne peut pas ouvrir les mêmes sondes brutes ICMP, UDP ou TCP qu'une commande de terminal local. Les bacs à sable du navigateur et le runtime ClockTools Cloudflare Worker n'exposent pas le contrôle TTL de paquet requis, donc ClockTools n'invente pas de table de sauts.

Le ClockTools Diagnostic de trace d'itinéraire travaille à l’intérieur de cette limite. Le protocole HTTP et le RTT client décrivent la jambe du navigateur vers ClockTools. Une requête publique distincte HTTP ou HTTPS s'exécute depuis le bord ClockTools vers la cible et signale l'accessibilité, l'état, le temps de réponse, le type de contenu et les redirections. Il est utile pour une vérification rapide du site Web de l'extérieur vers l'intérieur, mais il ne s'agit pas de la table de saut locale de votre ordinateur portable.

Dans la capture d'écran, la légende 1 marque l'avis de limitation ; la légende 2 marque les données de réponse cibles. L'exemple utilise exemple.com, un domaine de documentation public (et non un hôte privé) et généralise le code Edge spécifique à la requête.

Utilisez une URL publique que vous possédez, gérez ou que vous êtes autorisé à tester. Si la cible répond rapidement depuis la périphérie mais semble lente sur votre appareil, le Wi-Fi local, un chemin ISP, un VPN, la charge de l'appareil ou le comportement du navigateur méritent d'être vérifiés, mais les deux tests proviennent également de points de vue différents et peuvent utiliser des itinéraires différents. En cas d'échec à la fois depuis la périphérie et localement, DNS, l'hébergement, le pare-feu ou la disponibilité de la cible deviennent plus plausibles.

Une séquence de dépannage pratique

Commencez par le symptôme, pas par le tiroir à outils.

• Le site Internet est-il accessible depuis l’extérieur de votre connexion ? Exécutez le diagnostic de l'itinéraire ClockTools et notez l'état, les redirections et le temps de réponse.
• Toute votre connexion est-elle lente ? Comparez le débit, le ping et la gigue avec un test de vitesse Internet.
• Avez-vous besoin d'une vue locale étape par étape ? Exécuter tracer ou traceroute sur l'appareil et le réseau concernés.
• Un service tombe-t-il en panne pendant que l'hôte répond ? Vérifiez uniquement le port TCP public approprié et autorisé à partir du dispositif Edge ClockTools.
• Un RTT ou un délai d'attente élevé est-il apparu une fois ? Répétez la trace. Un comportement persistant en aval compte plus qu’une seule ligne dramatique.
• Comparez-vous des adresses publiques et privées ? Quelle est mon adresse IP identifie votre adresse publique visible, tandis que le calculateur de sous-réseau vous aide avec les plages de réseau privé.

Cet ordre évite une erreur courante : utiliser un seul diagnostic pour répondre à chaque question du réseau. L'accessibilité, l'observation d'itinéraire, les pertes subies, le débit et la disponibilité du service sont liés, mais ils ne sont pas interchangeables.

Partagez les résultats de traceroute en toute sécurité

Une trace peut exposer des adresses IP publiques et privées, des noms d'hôtes internes, des noms de fournisseurs, des modèles de synchronisation et des éléments de la conception d'un réseau. Avant de publier une sortie dans un forum, un ticket, un article ou une capture d'écran, supprimez les détails dont le destinataire n'a pas besoin.

Rédigez les noms de périphériques internes, les noms d'utilisateur intégrés dans les noms d'hôte, l'adressage privé lorsque la topologie n'est pas pertinente et les adresses publiques si vous ne souhaitez pas qu'ils soient associés à la publication. Gardez suffisamment de structure pour que le problème reste compréhensible : le nombre de sauts, la présence de délais d'attente et les timings représentatifs sont souvent suffisants.

Ne présumez pas tracert /j anonymise une trace. Il ignore la résolution de nom ; il affiche toujours les adresses IP répondantes. N'oubliez pas non plus qu'une estimation de géolocalisation IP n'est pas un emplacement physique précis, mais elle peut révéler un fournisseur ou une vaste région.

La meilleure lecture de traceroute est modeste. Il vous indique quelles sondes ont reçu des réponses, combien de temps ont duré ces allers-retours et où un modèle peut commencer. Cela devient véritablement utile lorsque vous combinez ces preuves avec des tests répétés et le symptôme que vous essayez d’expliquer.