Traceroute - chaque paquet a TTL == 1

Je travaille sur Wireshark lab-IP dans les réseaux informatiques - une approche descendante et je ne comprends pas pourquoi chaque paquet qui expire normalement a un TTL de 1.

Voici mon fichier de capture Wireshark. https://www.dropbox.com/s/rr5wgze9j20gzvu/traceroute-56.pcapng?dl=0

J'ai capturé l'exécution du tracerouteprogramme sous Linux (avec l'option de 56 octets), comme exécuté avec la commande suivante:

traceroute http://gaia.cs.umass.edu 56

Vous pouvez voir que la plupart des TTL du paquet == 1 et je ne sais pas pourquoi, car j'ai appris que chaque saut suivant a un TTL de +1 (ou plus).

PS:

• J'utilise Lubuntu sur VMware avec un réseau ponté vers l'hôte.
• Je l'ai capturé avec Wireshark sur la machine hôte (Windows)
• Je suis connecté à un point d'accès sans fil en utilisant son propre serveur DHCP en plus du protocole NAT

Permettez-moi d' essayer de répondre à cette question, car c'est un peu plus compliqué que cela puisse paraître au départ.

Il semble que vous connaissiez déjà le fonctionnement de base de, traceroutemais avant toute chose, voici un très petit récapitulatif:

tracerouteessaie de déterminer toutes les étapes intermédiaires de votre hôte à un hôte de destination, ou simplement la distance, c'est-à-dire le nombre de sauts, de votre hôte à un hôte de destination. Pour ce faire, il commence à envoyer des paquets à l'hôte de destination avec un numéro de port de destination "aléatoire" et un TTL qui commence à 1 et continue d'augmenter.
L'idée est que chaque routeur entre les deux diminue le TTL de 1. Ainsi, si le TTL atteint 0 (en réalité, il ne le fait jamais puisque le routeur qui est sur le point de le réduire à 0 produit une erreur avant cela), le routeur retournera un ICMP Message d'erreur " Time-to-live dépassé ", par exemple le numéro de paquet 24 dans votre fichier de capture. Ce que vous obtenez de cela, c'est que votre destination est plus éloignée et c'est pourquoi vous continuez à augmenter le TTL.
Lorsque votre paquet a un TTL suffisamment grand pour atteindre la destination, vous obtiendrez un message d'erreur ICMP différent: " Destination inaccessible (port inaccessible) ", par exemple le numéro de paquet 208 dans votre fichier de capture. Ce que vous obtenez de cela, c'est que le dernier TTL utilisé est en effet le nombre de sauts entre vous et le nœud de destination. La raison pour laquelle vous obtenez une erreur est simplement parce que vous envoyez un message à un port "aléatoire" que le nœud de destination (espérons-le) n'écoute pas.

Entrons maintenant dans les détails de votre fichier de capture: à
partir de la page de manuel de traceroutenous pouvons voir que chaque TTL est utilisé 3 fois (option '-q') et le protocole par défaut utilisé est UDP (option '-P'). En examinant les 3 premiers paquets UDP, c'est-à-dire les paquets 8-9-10 , nous pouvons en effet voir que le TTL est 1 . Les 3 suivants, c'est-à-dire 11-12-13 , ont un TTL 2 et ainsi de suite. Du point de vue de la source, tout semble bien se passer.

Ensuite, après un certain temps dépendant du retard du réseau, nous commençons à recevoir les messages d'erreur anticipés. Ainsi, nous pouvons voir que les paquets 24-25-26 sont des paquets d'erreur " Time to live dépassé " et donc signifient que la destination est plus éloignée.

Ce va-et-vient de tentatives et d'erreurs se poursuit jusqu'à ce que, finalement, le paquet 208 et les messages d'erreur " Port inaccessible " s'affichent, ce qui signifie que votre destination a été atteinte.

En comptant les paquets que vous envoyez et les réponses, vous pouvez réellement découvrir même à partir de la trace que TTL a réellement fonctionné, mais c'est une tâche fastidieuse :)

J'espère que cela a aidé

Votre client n'envoie que les trois premiers paquets avec un TTL de 1. Les trois suivants sont envoyés avec un TTL de 2. Les trois suivants sont envoyés avec un TTL de 3. Et ainsi de suite et ainsi de suite.

Un moyen plus simple de voir cela est de définir le champ IP TTL comme sa propre colonne dans Wireshark. Cliquez simplement avec le bouton droit sur la valeur TTL dans n'importe quel paquet et sélectionnez "Appliquer en tant que colonne":

De là, vous pouvez voir que les paquets 8,9,10 ont un TTL de 1. Et les paquets 11,12,13 ont un TTL de 2. Et ainsi de suite et ainsi de suite.

Cela se produit parce que c'est ainsi que fonctionne Traceroute. Il tire parti de ce que fait un routeur lorsqu'il réduit un TTL à 0. Plutôt que de continuer à transmettre le paquet, il renvoie au client d'origine un "message ICMP TTL expiré en transit" (voir le paquet n ° 24 dans votre capture) .

Ainsi, en tant que client, lorsque vous envoyez le premier ensemble de paquets avec un TTL de 1, le premier routeur du chemin répond avec le message TTL Expired. Vous mesurez ensuite le temps qu'il a fallu pour recevoir le message Expiré TTL par rapport à l'envoi des messages initiaux, et cela vous donne vos trois premières valeurs dans la sortie Traceroute.

Ensuite, vous envoyez un autre ensemble de trois paquets avec un TTL de 2. Le premier routeur du chemin le décrémente à 1, puis le transmet au routeur suivant du chemin. À la réception, lorsque ce deuxième routeur l'obtient, il décrémente le TTL à 0, ce qui l'invite à abandonner le paquet et à vous envoyer le TTL expiré en transit.

Le processus se poursuit jusqu'à ce que votre client ait reçu un (enfin, trois) message TTL Expired de chaque routeur en transit entre vous et la destination finale contre laquelle vous exécutez votre traceroute.