Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 045-icmpv4:040-bonusicmp [le 04/10/2025 à 15:53] – supprimée - modification externe (Date inconnue) 127.0.0.1
+++ 045-icmpv4:040-bonusicmp [le 04/10/2025 à 15:54] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. prof
@@ Ligne 1: / Ligne 1: @@
+====== Bonus: le traceroute ======
+Bien que cette commande n'utilise pas que les propriétés d'ICMP, il est utile de bien comprendre son utilité, son fonctionnement et ses limites.
+===== Objectif =====
+Comme son nom le laisse supposer, cette commande s'efforce de tracer l'itinéraire d'une trame émise par une source pour atteindre une cible quelque-part sur l'internet.
+===== Principe de base =====
+La commande envoie une trame vars la cible, avec un «Time To live» initialement = 1, puis incrémenté jusqu'à l'arrivée vers la cible. Nous savons qu'un routeur décrémente ce TTL sitôt que la trame lui arrive, puis toutes les secondes et que si ce TTL arrive à 0, le message ICMP de code 11 est renvoyé à la source. Lorsque tout se passe bien, la source est donc capable de reconstituer la liste de tous les routeurs impliqués dans le chemin.
+La commande ''traceroute'' de GNU/Linux utilise par défaut des datagrammes UDP vers le port Port 33434 de la cible. Les routeurs qui mettent à 0 le TTL réponde par le message ICMP type 11 (Time-to-live exceeded). Il est cependant possible de paramétrer le fonctionnement de façon différente, par exemple en envoyant un «ICMP echo request» plutôt qu'un datagramme UDP. Il existe même une commande analogue ''tcptraceroute'' qui envoie un paquet [SYN] sur un port indiqué dans la commande. Le principe de fonctionnement reste le même. Voici un exemple:
+<html><pre class="code">
+<b>traceroute -4 -n www.free.fr</b>
+traceroute to www.free.fr (212.27.48.10), 30 hops max, 60 byte packets
+  192.168.60.254  0.366 ms  1.036 ms *
+  * 194.149.174.110  15.461 ms *
+  212.27.57.126  15.357 ms  15.531 ms  16.008 ms
+  194.149.161.246  16.276 ms  17.439 ms  17.436 ms
+  212.27.48.10  15.805 ms  15.801 ms  15.798 ms
+</pre></html>
+Lorsqu'il y a des étoiles dans les réponses, c'est justement que la commande n'a pas reçu de réponse.
+Graphiquement, ça donne ceci:
+{{ 045-icmpv4:tracert.svg?800 |Traceroute vers www.free.fr}}
+Si nous recherchons avec ''whois'' à qui sont attribuées ces adresses, il y a des chances de retrouver Proxad ou une de ses filiales. Mais en regardant bien ce graphique, que voyons-nous ?
+  * nous ne voyons que les adresses par lesquelles le datagramme **entre** sur les routeurs, donc:
+  * au mieux nous visualisons le chemin  pour **aller vers** la cible.
+Ce qui ne donne aucune informations sur le chemin ** de retour**. De plus, rien ne dit que les messages ICMP que l'on reçoit reviennent par le même chemin.
+Comme nous ne sortons probablement pas du réseau Proxad, il n'est pas forcément absurde d'imaginer une architecture de ce genre:
+{{ 045-icmpv4:tracert2.svg?800 |Supposition d'architecture}}
+Les chemins de retour des divers messages ICMP et même le retour du serveur ''www.free.fr'' peuvent être totalement différents du chemin de la requête et ''traceroute'' ne le montrera pas.
+Finalement, cette commande n'offre qu'assez peu d'intérêt sur le bon (ou le mauvais) état d'une connexion entre client et serveur lorsque l'on ne connaît pas déjà plus ou moins l'architecture de l'inter-réseau impliqué, sans compter les cas où les routeurs ne répondent tout simplement pas.
+===== Tout de même =====
+''traceroute'' a de plus en plus de difficultés à tracer son chemin, compte tenu des routeurs ou même des cibles qui ne répondent plus. En revanche, ''tcptraceroute'', si l'on cible un hôte dont on est certain que le port demandé est ouvert, affichera généralement au moins la dernière étape. Voici un exemple qui permet de découvrir quelques informations.
+Le site ''ipindia.gov'' présente un site web en https (port 443)
+<html><pre class="code">
+<b>tcptraceroute ipindia.gov.in 443</b>
+Selected device sw0, address 192.168.60.47, port 49657 for outgoing packets
+Tracing the path to ipindia.gov.in (164.100.236.140) on TCP port 443 (https), 30 hops max
+  192.168.60.254  0.529 ms  0.432 ms  0.255 ms
+  * * *
+  * * *
+  * * *
+  prs-bb2-link.ip.twelve99.net (62.115.118.62)  15.299 ms  15.812 ms  15.578 ms
+  mei-b5-link.ip.twelve99.net (62.115.124.57)  25.359 ms  26.241 ms  25.838 ms
+<span class="hly"> 7  reliance-ic-361536.ip.twelve99-cust.net (62.115.155.139)  <b>39.008 ms  38.343 ms  38.923 ms</b>
+  103.198.140.210  <b>142.933 ms  222.755 ms  143.117 ms</b></span>
+  49.44.220.240  141.860 ms  141.285 ms  141.508 ms
+  * * *
+  * * *
+<span class="hlo">12  103.156.182.67  <b>144.159 ms  143.503 ms  143.514 ms</b>
+  * * *
+  * * *
+  * * *
+  * * *
+  * * *
+  * * *
+  * * *
+  164.100.236.140 [open]  <b>160.266 ms  160.591 ms  159.867 ms</b></span>
+</pre></html>
+Il y a une très grosse différence de temps de réponse entre le hop 7 et le hop 8. La géolocalisation des IP concernées dit que:
+  * ''62.115.155.139'' est gérée par [[https://www.arelion.com/|Arelion]] en Suède;
+  * ''103.198.140.210'' l'est par [[https://en.wikipedia.org/wiki/Jio|Reliance Jio Infocomm Limited]] à Singapour
+La latence entre les deux routeurs peut paraître anormale, mais [[040-adresses:060-iana-as-etc#whois|nous avons vu précédemment]] que la distance à parcourir était supérieure à 11000 km.
+  * ''49.44.220.240'' du hop 9 est également attribuée à [[https://en.wikipedia.org/wiki/Jio|Reliance Jio Infocomm Limited]] mais en en Inde (en gros 3500 km en ligne droite et il n'y a quasiment aucune latence entre les deux);
+  * ''103.156.182.67'' du hop 12 à [[https://fr.wikipedia.org/wiki/Bharti_Airtel|BHARTI Airtel Ltd]] (Inde)
+  * ''164.100.236.140'', la cible est assignée à [[https://en.wikipedia.org/wiki/National_Informatics_Centre|National Informatics Centre]].
+Entre les hops 12 et 20 il y a également un peu de latence, pourtant dans le même pays.
+Il peut donc y avoir quelques informations intéressantes à tirer d'un ''tcptraceroute'' lorsque la cible est très lointaine.