Traceroute (tracert) : diagnostic et localisation de latence

Traceroute (ou tracert sous Windows) est un utilitaire de diagnostic réseau qui affiche la route suivie par des paquets IP vers une destination et les délais mesurés à chaque saut, ce qui aide à localiser des ruptures ou des points de latence.

Qu’est‑ce qu’une trace de route (traceroute / tracert) ?

Une trace de route est un procédé de diagnostic réseau. Elle vise à afficher, hop par hop, les routeurs qui relaient des paquets depuis l’origine jusqu’à une adresse IP ou un nom d’hôte. L’utilitaire correspondant s’appelle traceroute sur Unix/Linux/macOS et tracert sur Windows.

La raison d’être d’une trace de route est simple : quand la latence est anormale, quand des paquets sont perdus ou quand une connexion échoue, on cherche à savoir où dans le chemin se produit la dégradation. Traceroute expose la succession de sauts et affiche des durées de réponse pour chaque sonde, ce qui aide à pointer une zone problématique sans prétendre prouver une faute d’un opérateur tiers.

Comment ça fonctionne (principe technique)

Le principe repose sur la variation du champ TTL (Time To Live) dans l’en-tête IP. En envoyant des paquets avec un TTL initial bas puis en l’augmentant, traceroute provoque des expirations de TTL sur les routeurs intermédiaires. Ces routeurs renvoient alors des messages ICMP « Time Exceeded », qui permettent d’identifier l’adresse du saut ayant déclenché l’expiration. La méthode exploite donc la réaction des routeurs pour reconstruire la chaîne de relais.

Les outils n’utilisent pas tous la même sonde par défaut : sous Unix/Linux et macOS, traceroute envoie classiquement des sondes UDP vers des ports élevés (par défaut des plages comme 33434–33534 sont citées dans la documentation) ; sous Windows, tracert envoie des ICMP Echo Request. De nombreux implémentations proposent des variantes permettant de forcer ICMP ou TCP selon le besoin.

Enfin, traceroute envoie généralement plusieurs sondes pour chaque valeur de TTL — trois sondes sont fréquemment utilisées — et affiche les temps aller‑retour observés (RTT) pour chacune d’elles. Ces valeurs renseignent sur la variabilité latence entre les sondes.

Que lit‑on dans la sortie (interpréter les sauts)

Une ligne typique de sortie liste d’abord le numéro du saut, puis l’adresse IP ou éventuellement un nom DNS résolu, puis les durées mesurées pour les sondes envoyées à ce TTL. Lorsqu’un saut ne renvoie pas de réponse, des astérisques apparaissent à la place des temps. L’astérisque signifie absence de réponse pour la sonde correspondante, ce qui peut traduire un filtrage, un drop de la sonde ou un délai de réponse dépassé.

La présence d’une adresse IP privée sur un saut indique que le routeur intermédiaire utilise une adresse de l’espace privé (RFC 1918) ou que la perspective montre un segment interne. Cela n’indique pas nécessairement qu’un saut est « mort » : un saut peut ne pas dévoiler son IP publique pour des raisons de routage, NAT ou topologie interne.

Comparer les temps affichés permet de distinguer un signe probable de congestion (temps élevés et récurrents sur un même saut) d’un filtrage sélectif (absence de réponses alors que d’autres sauts répondent). Toutefois, une seule trace fournit une perspective limitée : il faut croiser plusieurs mesures pour confirmer un comportement.

Limites et biais de la méthode (ce qu’elle ne dit pas)

Traceroute observe le trajet des paquets depuis un point d’origine donné ; il ne garantit pas d’observer le chemin de retour. Les routes peuvent être asymétriques : le chemin aller vers la destination peut différer du chemin retour, ce qui rend une interprétation hâtive risquée.

Les firewalls et les politiques de filtrage peuvent bloquer les sondes ICMP/UDP/TCP ou limiter le taux de réponses. Des routeurs configurés pour limiter les réponses ICMP peuvent ne pas renvoyer de « Time Exceeded » pour chaque sonde, produisant des lignes d’astérisques sans qu’un lien soit forcément en panne. Les technologies de transport comme MPLS ou des tunnels peuvent également masquer des sauts réels en rendant les adresses invisibles.

Par conséquent, traceroute est un outil complémentaire, utile pour orienter une investigation, mais insuffisant à lui seul pour attribuer une panne ou une responsabilité à un opérateur tiers.

Variantes et outils pratiques

Plusieurs variantes existent pour s’adapter aux environnements où ICMP ou UDP sont filtrés. Les probes TCP tentent de simuler du trafic applicatif (par exemple des flux web) et traversent parfois des pare‑feux qui bloqueraient des sondes classiques. Des outils modernes, comme MTR, offrent un suivi continu et agrègent perte et latence dans le temps au lieu d’une seule mesure ponctuelle.

Les différences entre traceroute et tracert tiennent principalement aux sondes par défaut : traceroute (Unix/Linux/macOS) se base typiquement sur UDP vers des ports élevés, tandis que tracert (Windows) utilise ICMP Echo Request. La possibilité de forcer ICMP ou TCP, d’augmenter le TTL maximal ou de modifier le nombre de probes est utile pour s’adapter, sans pour autant exiger ou détailler des commandes à privilèges.

Cas pratiques (lecture selon OS / situation)

Lire un extrait de sortie consiste à identifier le numéro du saut, l’adresse ou le nom résolu, puis les trois temps affichés pour les sondes successives. Si un saut montre des temps très supérieurs aux sauts voisins, cela suggère une latence introduite à ce point. Si un saut alterne entre réponse et astérisque, cela peut indiquer un filtrage ou un rate‑limiting.

Scénarios fréquents et interprétations possibles : latence élevée sur un saut intermédiaire peut indiquer congestion locale ; une série d’astérisques après plusieurs sauts répondants peut traduire une politique de filtrage en bordure du réseau cible ; un changement de route après un certain TTL montre que le routage dynamique a modifié la topologie observée. Dans tous les cas, les actions courantes consistent à compléter les mesures depuis plusieurs points et à contacter l’opérateur en fournissant ces traces plutôt que de tirer une conclusion immédiate.

Bonnes pratiques et précautions

Obtenir une autorisation est nécessaire avant de lancer des traces sur des réseaux qui ne vous appartiennent pas. Les sondes générées peuvent être perçues comme du trafic intrusif ; il faut donc respecter les droits d’accès et la vie privée des tiers.

Compléter traceroute par d’autres outils — ping, mesures depuis plusieurs points d’émission, et solutions spécialisées d’analyse réseau — améliore la fiabilité d’un diagnostic. Interpréter un traceroute demande prudence : une seule mesure ne suffit pas pour attribuer une responsabilité ou pour valider une hypothèse.

Ressources et lectures complémentaires

Sources

• en.wikipedia.org
• netsh.io
• man7.org
• cloudflare.com
• ipferret.com
• fr.wikipedia.org