Explication du commandement de la Traceroute

Traceroute peut être un outil inestimable pour tenter de diagnostiquer les problèmes de connexion aux hôtes d'autres réseaux. Toutefois, pour l'utiliser efficacement, il faut comprendre son fonctionnement et la signification de ses résultats.

Traceroute fonctionne en manipulant la valeur du Time-To-Live (TTL) dans l'en-tête IP (figure 1). Comme je devais faire mes exemples en utilisant le réseau interne Stratus , j'ai supprimé la représentation hexadécimale de l'adresse IP dans les traces de paquets et j'ai traduit tous les octets en notation décimale pointillée en un code de lettre unique de A à W. Le nombre de lettres représente le nombre de chiffres de l'octet. C'est-à-dire que AAA représente un nombre à 3 chiffres tandis que J représente un nombre à 1 chiffre.

Figure 1 - trame de packet_monitor avec TTL à haute luminosité

Chaque routeur qui traite le paquet réduira la valeur TTL de 1 et, si la valeur TTL est supérieure à 0, transmettra le paquet au routeur suivant ou à la destination finale. Si la valeur TTL est égale à 0, le routeur rejettera le paquet et *peut* renvoyer à l'expéditeur un message de dépassement du temps ICMP. La clé est *mai*, certains routeurs ne renverront pas de message de dépassement de temps ou ne le feront que s'ils ne sont pas occupés. En outre, certains pare-feu bloquent le message ICMP, de sorte que même si le routeur envoie le message de dépassement de temps, l'hôte qui exécute traceroute peut ne jamais le voir.

Traceroute commence par envoyer un message à la destination cible avec une valeur TTL de 1. Il chronomètre le temps qui s'écoule entre le moment où il envoie le message et celui où il reçoit une réponse.

Figure 2 - Trame et réponse du traceroute packet_monitor

Par défaut, la commande traceroute envoie trois messages avec un TTL de 1 et signale les trois fois ainsi que le nom et/ou l'adresse IP du routeur qui a envoyé la réponse. J'utilise toujours l'argument -numérique pour ne pas avoir à attendre la résolution du nom (figure 3). Traceroute incrémente ensuite le TTL de 1 et le fait à nouveau. Il continuera d'incrémenter le TTL jusqu'à ce qu'il obtienne une réponse de la destination cible ou qu'une limite, 30 (par défaut), soit atteinte. Vous pouvez trouver de la documentation sur tous les arguments de traceroute dans le manuel OpenVOS STREAMS TCP/IP Administrator's Guide (R419 ).

Figure 3 - Sortie du traceroute

On pourrait s'attendre à ce que les temps augmentent à mesure que le TTL augmente et c'est généralement le cas, mais pas toujours, comparez les troisièmes temps déclarés du saut 6 (79 ms) et du saut 5 (80 ms) dans la figure 3. Il y a plusieurs raisons à cela. Premièrement, le réseau n'est pas déterministe, parfois il prend simplement plus de temps. Deuxièmement, le routeur du saut N-1 peut être plus occupé que celui du saut N et prendre plus de temps pour envoyer le message ICMP. Enfin, la voie de retour du routeur N peut être plus rapide que celle du routeur N-1. Par exemple, il n'est pas nécessaire que le quatrième routeur renvoie sa réponse à la source via les routeurs 3, 2 et 1. Il pourrait envoyer sa réponse directement au routeur 1, ce qui pourrait être beaucoup plus rapide. Cela signifie que si traceroute est très efficace pour signaler le chemin qu'un paquet prend de l'hôte émetteur à l'hôte cible, vous ne pouvez pas vous fier au fait qu'un paquet envoyé de l'hôte cible à l'hôte émetteur ne prenne le même chemin qu'en sens inverse. C'est ce qu'on appelle le routage asymétrique.

Traceroute peut ajouter un drapeau à une heure qui indique qu'il a reçu autre chose que le message de dépassement de l'heure prévue. Les drapeaux sont :

!H - hôte injoignable
!N - réseau injoignable
!P - protocole injoignable

Par exemple, la figure 4 montre que le premier routeur ne sait pas comment atteindre le réseau cible et renvoie donc un message de réseau inaccessible et traceroute se termine à ce point.

Figure 4 : messages inaccessibles sur le réseau

Un astérisque (*) à la place d'une heure indique que traceroute n'a pas reçu de réponse. Comme je l'ai indiqué ci-dessus, il se peut que le routeur n'envoie pas de message ICMP de dépassement de temps, qu'un pare-feu bloque le message de dépassement de temps sur son chemin de retour ou qu'un pare-feu bloque le message sortant. Il se peut également que le réseau ait simplement supprimé le message sortant ou le message de retour.

Un seul ou même deux timeouts lors d'un saut (figure 5) indique probablement soit que le routeur n'a pas envoyé le message parce qu'il était occupé, soit que le réseau lâchait des paquets (ou les deux). Remarquez le 8e saut dans la figure 5, l'astérisque avant l'adresse IP signifie que le premier message de l'ensemble a été temporisé.

Figure 5 - Routeur occupé ou paquets déposés

Si les trois messages ont un délai d'attente mais que les sauts suivants indiquent des temps (figure 6), il est probable que le routeur pour ce saut n'envoie tout simplement pas les messages dont le temps ICMP est dépassé.

Figure 6 - Routeur(s) non réactif(s)

Si tous les sauts dépassent un certain délai (figure 7), il est probable qu'un pare-feu bloque les messages sortants ou les messages de retour.

Figure 7 - blocage du pare-feu

Il y a une autre raison pour laquelle tout ce qui dépasse un certain point se retrouve à un moment donné. C'est le moment où la cible ne répond pas. Toutes les cibles ne répondent pas et lorsque cela se produit, vous avez quelque chose qui ressemble à la figure 8. La différence entre les figures 7 et 8 est que dans la figure 8, le dernier routeur à envoyer une réponse est celui qui est local à la cible. Comment pouvez-vous dire que c'est le cas ? Parfois, l'adressage le rend évident, par exemple la cible est 192.168.1.12 et 192.168.1.1 est le dernier routeur à répondre. Ce n'est pas aussi évident sur la figure 9, EEE.FFF.W.XXX peut être le dernier routeur avant EEE.FFF.GGG.HHH, ils ont les 16 premiers bits en commun. Mais sans connaître le schéma de sous-réseautage utilisé par le réseau de la cible, il n'y a aucun moyen d'en être sûr sans demander.

Figure 8 - cible ne répondant pas

Il est également possible d'obtenir des réponses de deux ou plusieurs routeurs pour un même saut (figure 9). Cela peut se produire si les routeurs sont en équilibrage de charge ou si le réseau est instable et que les routes changent ou, comme dans le cas de la figure 9, le routeur AAA.BBB.CC.KKK n'était pas le routeur optimal et, après avoir transmis le paquet à AAA.BBB.II.J, il a renvoyé un message de redirection à la source pour changer sa table de routage.

Figure 9 - deux réponses pour le même saut

Il existe deux types de commandes traceroute qui se distinguent par le type de message qu'elles envoient. Certaines traceroutes, comme celle que l'on trouve sur les systèmes Microsoft Windows, envoient des messages ICMP de demande d'écho (ping) ; d'autres, comme celle qui fonctionne sous STCP, envoient des messages UDP. Il est important de savoir quel type de traceroute vous utilisez si vous devez configurer des pare-feu pour laisser passer des paquets ou écrire des filtres d'analyse de protocole. La réponse de la cible sera également différente. Si la cible reçoit une requête ping, elle renvoie une réponse ping ; si elle reçoit un message UDP, la réponse dépend du numéro de port. Si le port est utilisé, l'application d'écoute rejettera plus que probablement le paquet parce qu'il ne répond pas aux exigences de l'application en matière de structure de message. Si le port n'est pas utilisé, l'hôte *peut* renvoyer un message ICMP de destination sur un port inaccessible. C'est pourquoi traceroute sélectionne des ports qui ne sont généralement pas utilisés.

Le numéro de port vu par l'hôte cible dépendra du nombre de houblon nécessaire pour l'atteindre. Traceroute démarre le port de destination à 33435 (par défaut) et incrémente le numéro de port pour chaque message (figure 10). La cible voit donc 3 ports différents, il y a de fortes chances que les trois ne soient pas utilisés. Le port source est basé sur l'ID du processus d'envoi. Un processus donné utilisera toujours le même port source.

Enfin, à moins qu'il y ait un problème au premier saut, vous ne pourrez probablement pas faire grand-chose pour le régler. Une fois que le STCP (ou la pile réseau d'un hôte) envoie un paquet au routeur local, il n'est plus entre ses mains (et les vôtres). Cependant, si vous connaissez l'adresse IP du dernier saut qui répond ou du saut où les délais commencent soudainement à se produire, vous avez une idée de l'endroit où se situe le problème et vous pouvez contacter le bon groupe d'administrateurs réseau pour le résoudre.