Comment utiliser Traceroute pour diagnostiquer les problèmes de connexion réseau

Lorsqu'un site web, un serveur ou un service en ligne ne répond plus, il n'est pas toujours clair où se trouve le problème. Votre ordinateur peut être connecté au réseau local, mais la destination reste inatteignable. Le problème pourrait provenir de votre routeur domestique, du réseau de votre fournisseur d'accès à Internet, d'un réseau distant ou du propre serveur de destination.

Le traceroute est un outil de diagnostic réseau qui permet d'afficher le chemin emprunté par les paquets depuis votre appareil vers une destination. Il liste les routeurs intermédiaires, couramment appelés sauts, et mesure le temps que prennent les réponses de chacun d'eux. Cela peut vous aider à identifier où le chemin change, où les retards commencent ou où les réponses disparaissent.

Le traceroute ne montre pas tous les détails de la façon dont le routage Internet fonctionne, et un délai d'expiration ne signifie pas automatiquement qu'un routeur ou un lien est défectueux. Beaucoup de routeurs limitent ou filtrent les réponses sur lesquelles le traceroute s'appuie. Cependant, lorsque vous comprenez ce que peut et ne peut pas vous dire la sortie, cela devient une première étape utile pour la résolution des problèmes.

Ce guide explique comment fonctionne traceroute, comment l'exécuter sur Windows, macOS et Linux, et comment interpréter les résultats courants. Si vous apprenez les bases du réseau, cela vous aide également à comprendre le rôle d'un passage par défaut et comment les plages d'adresses IP sont organisées sous-réseaux.

Qu'est-ce que Traceroute ?

Le traceroute est un outil en ligne de commande qui tente d'identifier les routeurs traversés par un paquet sur le chemin vers une destination. Sous Windows, l'outil intégré s'appelle tracert. Sur macOS et la plupart des distributions Linux, il s'appelle tracerouteLes noms sont différents, mais leur objectif principal est similaire.

L'outil envoie une série d'enquêtes avec des limites de sauts progressivement croissantes. Une limite de saut indique à un paquet combien de routeurs il peut traverser avant d'être supprimé. Dans IPv4, ce champ s'appelle le Durée de vie, ou TTL. Dans IPv6, on l'appelle Limite de saut.

Lorsqu'un routeur transfère un paquet, il diminue le TTL ou la limite de sauts. Lorsque la valeur atteint zéro, le routeur supprime le paquet et peut envoyer une réponse en retour à la source. Traceroute utilise ces réponses pour identifier les routeurs successifs. Après que l'outil ait appris le premier saut, il envoie une autre sonde avec une limite plus élevée, puis une autre, en continuant vers la destination.

Le traceroute mesure le temps entre l'envoi d'une sonde et la réception d'une réponse. Il envoie normalement plusieurs sondes pour chaque saut, c'est pourquoi la sortie contient souvent trois temps de réponse. Ces nombres mesurent le temps nécessaire à une sonde et une réponse pour voyager entre votre appareil et le routeur qui répond. Ils ne mesurent pas uniquement le temps passé à traiter le paquet à l'intérieur de ce routeur.

Qu'est-ce qu'un Traceroute montre ?

Un résultat typique comporte une ligne numérotée pour chaque saut. Le premier saut est généralement votre routeur local ou un autre premier appareil sur le réseau local. Les sauts suivants peuvent appartenir à votre fournisseur d'accès à Internet, des réseaux de transit, des fournisseurs d'hébergement ou au réseau de la destination.

Un exemple simplifié pourrait ressembler à ceci :

traceroute vers example.com, 30 sauts max

 1  192.168.1.1       2,1 ms   1,8 ms   2,0 ms
 2  100.64.0.1        8,4 ms   8,1 ms   8,6 ms
 3  203.0.113.10     13,2 ms  12,9 ms  13,5 ms
 4  *                 *        *
 5  198.51.100.20    25,6 ms  25,1 ms  26,0 ms

La première colonne identifie le numéro de saut. La valeur suivante est l'adresse ou le nom du routeur qui répond. Les valeurs restantes sont les temps de réponse pour les sondes envoyées à ce saut. Dans cet exemple, le saut 4 n'a pas répondu aux sondes, mais le saut 5 a répondu.

Un saut de réponse est une preuve qu'une sonde a reçu une réponse depuis ce point. Cela ne prouve pas que toutes les autres parties du chemin sont saines. De même, un saut qui ne répond pas ne prouve pas que le routeur est tombé. L'appareil peut être configuré pour acheminer le trafic tout en ignorant ou limitant les sondes diagnostiques.

Le traceroute peut également montrer différents chemins à des moments différents. Le routage Internet change lorsque les réseaux ajustent les itinéraires, équilibrent le trafic, gèrent les pannes ou appliquent des politiques. Un itinéraire observé lors d'une trace est une capture d'écran, pas une carte permanente.

Comment exécuter le traceroute sur Windows

Windows inclut tracertOuvrez le Invite de commandes ou PowerShell et saisissez un nom d'hôte ou une adresse IP :

tracert example.com

Windows résout le nom d'hôte en une adresse IP puis affiche les sauts qu'il peut observer. Vous pouvez utiliser -d pour prévenir tracert à la résolution des adresses de routeur en noms :

tracert -d example.com

Utilisation -d peut faire apparaître les résultats plus rapidement, car Windows ignore les recherches DNS inverses pour les adresses intermédiaires. Cela est utile lorsque vous vous préoccupez du chemin et du délai plutôt que des noms associés à chaque routeur.

Vous pouvez limiter le nombre maximum de sauts avec -h et définir le délai d'attente pour chaque réponse avec - wPar exemple :

tracert -d -h 20 -w 2000 example.com

Cette commande ignore les recherches de noms, s'arrête après un maximum de 20 sauts et attend jusqu'à 2 000 millisecondes pour une réponse à chaque sonde. Si une destination est éloignée ou si le chemin est lent, une limite de saut faible peut arrêter la trace avant qu'elle n'atteigne la destination.

Pour tester une adresse IP particulière au lieu d'un nom d'hôte, exécutez :

tracert -d 203.0.113.25

Lors de la comparaison des résultats, testez toujours la même destination. Une trace vers un nom de domaine et une trace vers une adresse IP particulière peuvent emprunter des chemins différents si le domaine résout vers des serveurs différents.

Comment exécuter le traceroute sur macOS

Sur macOS, ouvrez le Terminal et exécutez :

traceroute example.com

Pour afficher les adresses numériques sans tenter de résoudre les noms, utilisez :

traceroute -n example.com

Vous pouvez limiter le nombre maximum de sauts avec - m et ajustez le temps d'attente avec - wPar exemple :

traceroute -n -m 20 -w 2 example.com

Cela demande une sortie numérique, limite le trace à 20 sauts, et attend jusqu'à deux secondes pour une réponse à chaque saut. Les options exactes disponibles peuvent varier légèrement entre les implémentations, vérifiez donc le manuel local si une option de commande n'est pas reconnue :

homme traceroute

Le traceroute peut prendre un certain temps pour se terminer car elle envoie plusieurs sondes à chaque saut et attend les réponses. Si elle semble s'arrêter sur une ligne, elle peut attendre des réponses de routeurs qui ne répondent pas à ces sondes.

Comment exécuter Traceroute sous Linux

De nombreuses distributions Linux incluent traceroute, mais certains peuvent nécessiter l'installation en premier. Un test basique est :

traceroute example.com

Pour éviter les recherches DNS inverses et afficher uniquement les adresses numériques, utilisez :

traceroute -n example.com

Vous pouvez également définir un nombre maximum de sauts et un délai d'attente pour la réponse :

traceroute -n -m 20 -w 2 example.com

Sur Linux, les options de commande disponibles dépendent de l'implémentation de traceroute installée. Si la commande n'est pas présente, utilisez le gestionnaire de paquets de votre distribution pour installer le package approprié, ou utilisez une alternative disponible telle que tracepath.

Pour les destinations IPv6, de nombreux systèmes Linux prennent en charge :

traceroute -6 example.com

Si le domaine possède des enregistrements IPv4 et IPv6, l'outil peut sélectionner une famille d'adresses par défaut. Pour comparer les chemins, exécutez des traces séparées pour les IPv4 et IPv6 là où cela est pris en charge. Cela peut aider à identifier si un problème de connectivité affecte une famille d'adresses mais pas l'autre.

Comment lire chaque houblon

Commencez par vérifier le premier saut. Sur un réseau domestique, il s'agit souvent du routeur local. Si le premier saut répond rapidement, votre appareil peut au moins atteindre un routeur sur le réseau local. S'il ne répond pas, cela ne prouve pas seul une panne locale car le routeur peut filtrer les réponses de diagnostic. Vérifiez si d'autres appareils locaux et les services Internet fonctionnent avant de tirer une conclusion.

Ensuite, comparez les temps de réponse au fur et à mesure que le chemin progresse. Une augmentation soudaine et constante qui persiste lors des sauts suivants peut indiquer un changement de chemin ou un point où le délai réseau commence. Cependant, un temps de réponse élevé à un routeur suivi de temps plus faibles aux routeurs suivants reflète souvent comment ce routeur gère le trafic de diagnostic, et non nécessairement un délai affectant le trafic transmis.

Recherchez le dernier saut qui répond, mais considérez-le comme une piste plutôt qu'une localisation définitive de la panne. Le prochain routeur peut filtrer les sondes, le chemin de retour peut être différent, ou le réseau de destination peut bloquer le type de réponse que traceroute attend.

Enfin, comparez plusieurs exécutions et, si possible, testez une deuxième destination au sein du même service ou du même réseau. Une seule trace peut être affectée par une congestion temporaire ou un filtrage. Les schémas obtenus lors d'essais répétés sont plus informatifs qu'un seul résultat isolé.

Que signifie un astérisque ?

Un astérisque (*signifie que traceroute n'a pas reçu de réponse à cette sonde pendant la période d'attente. Un routeur peut avoir tout de même transmis la sonde vers la destination. Il a simplement pu refuser d'envoyer une réponse diagnostique.

Les routeurs et les pare-feux limitent souvent les messages du protocole de message de contrôle Internet (ICMP) ou d'autres réponses diagnostiques pour protéger les performances et réduire le trafic indésirable. Certaines réseaux permettent le trafic d'application normal tout en filtrant les sondes de traceroute. En conséquence, une trace peut afficher un ou plusieurs astérisques puis continuer avec des sauts répondants ultérieurement dans le chemin.

Si chaque saut suivant un point donné affiche des astérisques, le chemin peut être filtré à ce point, la destination peut être inatteignable, ou le trafic de retour peut être bloqué. Pour distinguer ces cas, testez le service réel en utilisant l'application concernée, telle qu'un navigateur web ou un client SSH, et comparez les traces avec d'autres destinations.

Temps de réponse et latence

Les valeurs de temps du traceroute montrent combien de temps il a fallu pour qu'une sonde atteigne un saut répondant et pour que la réponse revienne. Elles comprennent le retard réseau dans les deux sens et peuvent être affectées par la congestion, la file d'attente et la politique de réponse du routeur.

Une valeur élevée à un saut peut être trompeuse. Les routeurs privilégient le transfert du trafic transit par rapport à la réponse aux paquets de diagnostic adressés à eux-mêmes. Un routeur peut mettre longtemps à répondre à un traceroute tout en transférant rapidement le trafic ordinaire. Si les sauts suivants montrent des temps de réponse plus faibles, cette valeur élevée est moins susceptible de représenter un retard persistant dans le chemin des données.

Un motif plus utile est une augmentation de délai qui commence à un saut et reste visible à des sauts ultérieurs et à la destination sur plusieurs tests. Même dans ce cas, traceroute seul ne peut pas prouver la cause exacte. Il peut indiquer où approfondir l'enquête, par exemple un transfert de fournisseur, un lien encombré ou une segment de réseau éloigné.

Modèles courants de traceroute

Si le premier saut répond mais les sauts suivants ne le font pas, le réseau local peut fonctionner tandis qu'un réseau plus loin filtre le trafic de diagnostic. Vérifiez si le service de destination est lui-même accessible avant d'assumer que la connexion est interrompue.

Si la trace atteint la destination mais que l'application échoue toujours, le chemin réseau peut fonctionner tandis que le service a un autre problème. Le serveur pourrait refuser les connexions, l'application pourrait être indisponible, ou un pare-feu pourrait bloquer le port spécifique.

Si la trace s'arrête au même endroit à chaque fois et la destination est également inatteignable, le dernier réseau répondant peut aider à affiner l'endroit où demander de l'aide. Il ne identifie pas nécessairement l'appareil responsable, car le filtrage et les chemins de retour asymétriques peuvent rendre le point d'arrêt apparent trompeur.

Si IPv4 fonctionne mais pas IPv6, ou inversement, effectuez des traces séparées pour chaque famille d'adresses. Les deux chemins peuvent utiliser différents fournisseurs, routeurs, politiques de pare-feu ou serveurs de destination. La comparaison peut révéler si le problème est spécifique à un côté du réseau.

Le Traceroute et le Tracert ne sont pas identiques

Les commandes tracert et traceroute servent à une même fin, mais leurs méthodes de diagnostic et leurs options peuvent différer selon le système d'exploitation et l'implémentation. Windows tracert utilise couramment des sondes ICMP Echo. Les implémentations similaires à Unix peuvent utiliser le UDP par défaut, certaines prenant en charge les modes de sonde ICMP ou TCP.

Cela a de l'importance car un pare-feu peut autoriser un type d'analyse et bloquer un autre. Deux outils peuvent donc produire des résultats différents même s'ils sont exécutés depuis le même ordinateur vers la même destination.

Certains implémentations de traceroute permettent de sélectionner la méthode d'envoi des sondes. Par exemple, les versions Linux peuvent prendre en charge des options pour les sondes UDP, ICMP ou TCP. Le traçage basé sur TCP peut être utile lorsque les sondes habituelles sont filtrées mais qu'un service TCP particulier est accessible. La syntaxe des options varie, consultez donc le manuel local avant de vous fier à un indicateur spécifique.

Lors du partage des résultats avec un administrateur de réseau ou un fournisseur, incluez le système d'exploitation, la commande, les options, la destination et l'heure approximative du test. Ce contexte les aide à interpréter les différences entre les traces.

Traceroute vs Ping

Les tests Ping vérifient si une destination répond à un type particulier d'analyse réseau et mesurent le temps aller-retour. Il est utile pour vérifier la connectivité de base, mais il ne montre pas le chemin intermédiaire.

Les tentatives de traceroute visent à révéler la séquence des routeurs qui répondent vers une destination. Elles peuvent aider à identifier où les réponses s'arrêtent ou où un délai commence, mais elles sont plus sensibles au filtrage et aux politiques de réponse des routeurs.

Ces outils répondent à des questions différentes. Utilisez ping pour tester si une destination répond. Utilisez traceroute pour inspecter le chemin vers celle-ci. Aucun de ces outils ne garantit seul que un site web ou une application est en bonne santé, car des problèmes spécifiques à l'application peuvent survenir même lorsque les tests réseau de base réussissent.

Un workflow de dépannage pratique

Commencez par confirmer le nom et l'adresse de la destination. Si vous utilisez un nom d'hôte, vérifiez qu'il est correctement résolu. Ensuite, exécutez traceroute et notez le temps, la famille d'adresses, les options de commande et la destination.

Testez le même destination plus d'une fois. Si la sortie change de manière significative, le problème peut être intermittent ou la route peut avoir changé. Si la trace est stable mais que l'application échoue, vérifiez si le service écoute, si un pare-feu bloque son port et si le serveur retourne une erreur.

Comparer avec une autre destination hébergée par le même fournisseur ou dans la même région. Si plusieurs destinations montrent un problème similaire commençant au même point, cela donne une indication plus forte que le segment de réseau concerné mérite d'être examiné.

Si vous signalez le problème à un fournisseur d'accès Internet ou à une entreprise d'hébergement, fournissez la sortie brute au lieu de dire simplement « le traceroute échoue ». Incluez la destination, le temps, le système d'exploitation, et si le service de destination est lui-même inatteignable. Ces détails facilitent l'enquête.

Limites du Traceroute

Le traceroute ne montre pas tous les routeurs sur Internet. Certaines réseaux cachent ou filtrent leurs réponses, et certaines routes utilisent des technologies qui rendent les informations de saut incomplètes. L'équilibrage de charge peut également envoyer des sondes différentes par des chemins différents, donc les lignes adjacentes ne représentent pas toujours une route end-to-end stable.

Les temps de réponse ne sont pas des mesures directes de la vitesse à laquelle le routeur transmet le trafic normal. Ils mesurent le temps nécessaire pour l'enquête et la réponse, et les routeurs peuvent traiter ces paquets de diagnostic différemment du trafic d'application régulier.

Le traceroute ne prouve pas non plus qui possède une adresse de routeur, n'identifie pas la cause exacte des pertes de paquets, ni ne confirme qu'un chemin est autorisé. Les données de routage et d'enregistrement publics nécessitent des vérifications séparées. Pour une revue plus large d'une ressource IPv4 ou IPv6 publique, utilisez le Vérificateur de disponibilité des ressources IP.

Foire aux questions

Le traceroute est-il sécurisé à utiliser ?

Le traceroute est un outil de diagnostic standard qui envoie des sondes réseau vers une destination. Effectuer quelques tests pour le dépannage est normal. Évitez de générer un trafic excessif ou de sonder des systèmes que vous ne gérez pas à un rythme élevé.

Pourquoi le traceroute affiche-t-il un chemin différent à chaque fois ?

Les réseaux peuvent changer les itinéraires, utiliser l'équilibrage de charge ou diriger le trafic via différents fournisseurs. Le trafic de sondage peut également être traité différemment du trafic d'application ordinaire. De petites différences de chemin ne signifient pas automatiquement une panne.

Un astérisque signifie-t-il qu'un routeur est hors service ?

Non. Cela signifie que traceroute n'a pas reçu de réponse à cette sonde dans le délai imparti. Le routeur peut toujours transmettre le trafic tout en filtrant ou limitant les réponses diagnostiques.

Pourquoi le traceroute s'arrête-t-il avant d'atteindre un site web ?

Le réseau de destination ou un pare-feu intermédiaire peut bloquer le type de sonde. Le site web peut toujours être accessible via le trafic HTTPS normal. Testez le service lui-même avant de conclure que le chemin est indisponible.

Le traceroute peut-elle identifier où se produit la perte de paquets ?

Il peut aider à identifier où les réponses s'arrêtent, mais il ne peut pas toujours prouver où le trafic d'application est perdu. Comparez plusieurs exécutions, des sauts ultérieurs et le service réel. Des outils tels que mtr peut fournir des mesures répétées, mais leur sortie doit également être interprétée avec soin.

Puis-je exécuter un traceroute vers une adresse IPv6 ?

Oui. Windows, macOS et Linux prennent en charge le traçage des routes IPv6, bien que les noms de commandes et les options diffèrent. Sous Linux, traceroute -6 est couramment pris en charge. Sur Windows, tracert can trace IPv6 when given an IPv6 destination.

Le traceroute vous permet de voir quels routeurs répondent lorsque le trafic voyage depuis votre appareil vers une destination. Le premier saut est souvent votre passerelle locale, et les sauts suivants appartiennent peut-être à votre fournisseur d'accès à Internet et à d'autres réseaux avant d'atteindre la destination.

Utiliser tracert sur Windows et traceroute sur macOS ou Linux. Vérifiez le premier saut, comparez les modèles de réponse aux sauts ultérieurs, et répétez le test lorsque les résultats semblent anormaux. Les astérisques et les temps de réponse élevés isolés sont courants et ne prouvent pas automatiquement qu'un réseau est défectueux.

Les conclusions les plus utiles proviennent de la combinaison du traceroute avec des tests d'application, des vérifications DNS, des mesures répétées et des rapports d'autres utilisateurs ou réseaux. Traitez les résultats comme des preuves qui aident à guider l'enquête, plutôt que comme un diagnostic complet en soi.

Pour comprendre la partie réseau local du chemin, poursuivez avec notre guide sur passages par défaut. Pour les vérifications de l'adresse publique et du routage, voir le Vérificateur de disponibilité des ressources IP.