Comment utiliser la commande 'traceroute' sous Linux

Cet article couvre les informations de traceroute applicables aux machines Linux et comprend des explications sur les commutateurs de commande ainsi que des informations sur la façon d'interpréter les résultats. Traceroute est utilisé différemment dans Windows.

Comment fonctionne Traceroute

La commande traceroute trace le trajet qu'un paquet d'informations entreprend de sa source à sa destination. L'une des utilisations de traceroute est de localiser le moment où une perte de données se produit sur un réseau, ce qui peut signifier qu'un nœud est en panne.

Parce que chaque saut dans l'enregistrement reflète un nouveau serveur ou routeur entre le PC d'origine et le cible, l'examen des résultats d'une analyse traceroute identifie les points lents qui peuvent nuire à votre réseau circulation.

Dépannage avec Traceroute

L'évaluation de l'itinéraire spécifique suivi par le trafic réseau (ou la recherche de la passerelle malveillante qui rejette vos paquets) présente plusieurs défis de dépannage. Traceroute utilise le protocole IP temps de vivre pour solliciter une réponse ICMP TIME_EXCEEDED de chaque passerelle le long du chemin vers un hôte de destination.

Le seul paramètre que vous devez inclure lorsque vous exécutez la commande traceroute est le nom d'hôte ou l'adresse IP de la destination.

Syntaxe et commutateurs de traceroute

Traceroute suit la syntaxe générale suivante:

traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g gateway ] [ -i iface ] [ -m max_ttl ] [ -p port ] [ -q nqueries ] [ -s src_addr ] [ -t tos ] [ -w waittime ] [ -z pausemsecs ] hôte [ packetlen ] 

Vous pouvez modifier les performances ou la sortie de la commande en spécifiant un ou plusieurs commutateurs facultatifs.

Commutateurs de commande de traceroute
Changer	Explication
-F	Définissez la durée de vie initiale utilisée dans le premier paquet de sonde sortant.
-F	Définissez le bit « ne pas fragmenter ».
-ré	Activer le débogage au niveau du socket.
-g	Spécifiez une passerelle de routage source libre (8 maximum).
-je	Spécifiez une interface réseau pour obtenir l'adresse IP source des paquets de sonde sortants. Ceci n'est normalement utile que sur un hôte multi-hébergé. (Voir le -s indicateur pour une autre façon de le faire.)
-JE	Utilisez ICMP ECHO au lieu de datagrammes UDP.
-m	Définissez la durée de vie maximale (nombre maximal de sauts) utilisée dans les paquets de sonde sortants. La valeur par défaut est 30 sauts (la même valeur par défaut utilisée pour les connexions TCP).
-n	Imprimez les adresses de saut numériquement plutôt que symboliquement et numériquement (enregistre une recherche adresse-nom de serveur de noms pour chaque passerelle trouvée sur le chemin).
-p	Définissez le numéro de port UDP de base utilisé dans les sondes (la valeur par défaut est 33434). Traceroute espère que rien n'écoute sur les ports UDP base à base + houblon - 1 sur l'hôte de destination (un message ICMP PORT_UNREACHABLE sera donc renvoyé pour terminer le traçage de l'itinéraire). Si quelque chose écoute sur un port dans la plage par défaut, cette option peut être utilisée pour choisir une plage de ports inutilisée.
-r	Contournez les tables de routage normales et envoyez directement à un hôte sur un réseau connecté. Si l'hôte n'est pas sur un réseau directement connecté, une erreur est renvoyée. Cette option peut être utilisée pour envoyer un ping à un hôte local via une interface qui n'a pas de route à travers elle (par exemple, après que l'interface a été supprimée par acheminé(8C)).
-s	Utilisez l'adresse IP suivante (qui est généralement donnée sous forme de numéro IP, et non de nom d'hôte) comme adresse source dans les paquets de sonde sortants. Sur les hôtes multi-résidents (ceux avec plus d'une adresse IP), cette option peut être utilisée pour forcer l'adresse source à être autre chose que l'adresse IP de l'interface sur laquelle le paquet de sonde est envoyé. Si l'adresse IP n'est pas l'une des adresses d'interface de cette machine, une erreur est renvoyée et rien n'est envoyé. (Voir le -je indicateur pour une autre façon de le faire.)
-t	Met le type de service dans les paquets de sonde à la valeur suivante (zéro par défaut). La valeur doit être un entier décimal compris entre 0 et 255. Cette option peut être utilisée pour voir si différents types de services entraînent des chemins différents. (Si vous n'utilisez pas 4.4bsd, cela peut être académique, car les services réseau normaux comme telnet et ftp ne vous laissez pas contrôler le TOS.) Toutes les valeurs de TOS ne sont pas légales ou significatives - voir la spécification IP pour définitions. Les valeurs utiles sont probablement `-t16' (délai faible) et `-t8' (haut débit).
-v	Sortie verbeuse. Les paquets ICMP reçus autres que TIME_EXCEEDED et UNREACHABLE sont répertoriés.
-w	Réglez le temps (en secondes) d'attente d'une réponse à une sonde (par défaut 5 secondes).
-X	Basculer l'IP sommes de contrôle. Normalement, cela empêche traceroute de calculer les sommes de contrôle IP. Dans certains cas, le système opérateur peut écraser des parties du paquet sortant mais ne pas recalculer la somme de contrôle; ainsi, dans certains cas, la valeur par défaut est de ne pas calculer les sommes de contrôle et d'utiliser -X les fait calculer. Notez que des sommes de contrôle sont généralement requises pour le dernier saut lors de l'utilisation de sondes ICMP ECHO (-JE), ils sont donc toujours calculés lors de l'utilisation d'ICMP.
-z	Définissez le temps (en millisecondes) de pause entre les sondes (0 par défaut). Certains systèmes tels que Solaris et les routeurs de Cisco limitent le débit des messages icmp. Une bonne valeur à utiliser avec ceci est 500 (par exemple, 1/2 seconde).

Interprétation des résultats

Traceroute décrit le chemin suivi par un paquet IP vers un hôte Internet en lançant des paquets de sonde UDP avec un petit TTL, puis en écoutant une réponse ICMP "temps dépassé" d'une passerelle. Démarrez les sondes avec un TTL de un et augmentez de un jusqu'à ce que vous obteniez un "port inaccessible" ICMP (ce qui signifie que le paquet est arrivé à sa destination) ou atteint une valeur maximale de tentatives, qui est par défaut de 30 sauts et peut être modifiée avec le -m drapeau.

Lorsque traceroute s'exécute, il envoie trois sondes à chaque paramètre de durée de vie, puis imprime une ligne sur la console indiquant la durée de vie, l'adresse de la passerelle et le temps d'aller-retour de chaque sonde. Si les réponses de la sonde proviennent de passerelles différentes, l'adresse de chaque système répondant s'imprime. Si traceroute ne reçoit pas de réponse dans les cinq secondes (modifié avec le -w flag), il imprime un astérisque pour cette sonde.

Pour éviter que le traitement des paquets de sonde UDP ne submerge l'hôte de destination, traceroute définit le port de destination sur une valeur que le périphérique est peu susceptible d'utiliser. Si un réseau ou un service de destination utilise ce port, modifiez la valeur à l'aide de la -p drapeau.

Exemples de résultats de trace

Un exemple d'utilisation et de sortie renverra des résultats similaires à cet exemple:

[yak 71]% traceroute nis.nsf.net.
traceroute vers nis.nsf.net (35.1.1.48), 30 sauts max, paquet de 38 octets
1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms
2 lilas-dmc. Berkeley. EDU (128.32.216.1) 39 ms 39 ms 19 ms
3 lilas-dmc. Berkeley. EDU (128.32.216.1) 39 ms 39 ms 19 ms
4 ccngw-ner-cc. Berkeley. EDU (128.32.136.23) 39 ms 40 ms 39 ms
5 ccn-nerif22.Berkeley. EDU (128.32.168.22) 39 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms
8 129.140.70.13 (129.140.70.13) 99 ms 99 ms 80 ms
9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms
10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms
11 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms

Exemple de passerelle silencieuse

Un exemple plus intéressant est:

[yak 72] % traceroute allspice.lcs.mit.edu.
traceroute vers allspice.lcs.mit.edu (18.26.0.115), 30 sauts max
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms
2 lilas-dmc. Berkeley. EDU (128.32.216.1) 19 ms 19 ms 19 ms
3 lilas-dmc. Berkeley. EDU (128.32.216.1) 39 ms 19 ms 19 ms
4 ccngw-ner-cc. Berkeley. EDU (128.32.136.23) 19 ms 39 ms 39 ms
5 ccn-nerif22.Berkeley. EDU (128.32.168.22) 20 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms
8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms
9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms
10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms
11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms
12 * * *
13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms

Notez que les passerelles à 12, 14, 15, 16 et 17 sauts n'envoient pas de messages ICMP "temps dépassé" ou les envoient avec un TTL trop petit pour nous atteindre. Les lignes 14 à 17 exécutent le code de la passerelle MIT C qui n'envoie pas de messages « temps dépassé ».

La passerelle silencieuse 12 dans l'exemple ci-dessus peut être le résultat d'un bogue dans le code réseau 4.[23]BSD et ses dérivés: les machines exécutant le code 4.3 et antérieur envoient un message inaccessible en utilisant le TTL restant dans le datagramme original. Pour les passerelles, le TTL restant est égal à zéro, le "temps dépassé" ICMP est garanti pour ne pas nous revenir.

Exemple de passerelle silencieuse du système de destination

Le comportement de ce bug est légèrement plus intéressant lorsqu'il apparaît sur le système de destination:

1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms
2 lilas-dmc. Berkeley. EDU (128.32.216.1) 39 ms 19 ms 39 ms
3 lilas-dmc. Berkeley. EDU (128.32.216.1) 19 ms 39 ms 19 ms
4 ccngw-ner-cc. Berkeley. EDU (128.32.136.23) 39 ms 40 ms 19 ms
5 ccn-nerif35.Berkeley. EDU (128.32.168.35) 39 ms 39 ms 39 ms
6 csg. Berkeley. EDU (128.32.133.254) 39 ms 59 ms 39 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 déchirure. Berkeley. EDU (128.32.131.22) 59 ms! 39 ms! 39 millisecondes !

Notez qu'il existe 12 "passerelles" (13 est la destination finale), et la dernière moitié d'entre elles sont manquantes. Ce qui se passe réellement, c'est que le serveur nommé déchirure (un Sun-3 exécutant Sun OS 3.5) utilise le TTL de notre datagramme arrivant comme TTL dans sa réponse ICMP. Ainsi, la réponse expirera sur le chemin de retour (sans notification envoyée à qui que ce soit car les ICMP ne sont pas envoyés pour les ICMP) jusqu'à ce que nous sondions avec un TTL qui est au moins le double de la longueur du chemin - en d'autres termes, le rip n'est vraiment que de sept sauts une façon.

Une réponse qui retourne avec un TTL de 1 est un indice que ce problème existe. Traceroute imprime un! après le temps si le TTL est inférieur ou égal à 1. Étant donné que les fournisseurs livrent de nombreux logiciels obsolètes (Ultrix de DEC, Sun 3.x) ou non standard (HPUX), attendez-vous à voir ce problème fréquemment et prenez soin de choisir l'hôte cible de vos sondes.

D'autres annotations possibles après l'heure sont !H, !N, ou !P (hôte, réseau ou protocole inaccessible), !S (route source échouée), !F- (fragmentation nécessaire: la valeur RFC1191 Path MTU Discovery est affichée), !X (communication administrativement interdite), !V (violation de la priorité de l'hôte), !C (coupure de priorité en vigueur), ou ! (code ICMP inaccessible). Ces codes sont définis par la RFC1812, qui remplace la RFC1716. Si presque toutes les sondes aboutissent à une sorte d'hôte inaccessible, traceroute abandonnera et quittera.