Architecture simplifiée de l’internet
Voici un schéma simplifié de la route prise par les informations qui circulent entre un client et un serveur :

 

 

Généralement, les clients sont reliés par leur modem à un réseau de collecte.
Ce réseau de collecte est relié au réseau du fournisseur d’accès, par un routeur qui n’est autre que la « passerelle par défaut » que votre machine utilise dans sa configuration. Le plus souvent ce paramètre est fourni automatiquement lors de l’établissement de la connexion à l’internet.
Vous pouvez connaître son adresse IP facilement, tous les systèmes d’exploitation fournissent un moyen de la connaître.

Pour Windows
C’est la commande route print, qui donne quelque chose du genre :

 

Passerelle par défaut :      193.253.160.3

  ===========================================================================
Itinéraires persistants :
 Aucun

C:\>

Pour Linux
C’est la commande route, qui donne quelque chose du genre :

default       193.253.160.3 0.0.0.0       UG  0    0        0 ppp0 [root@helios root]#

Ensuite...
On accède au réseau du fournisseur d’accès (lui-même peut être constitué de plusieurs sous-réseaux).

Le plus souvent, ce réseau dispose d’un point d’accès dans un ou plusieurs GIX (Global Internet eXchange), qui sont des sortes de points de rendez-vous pour tous les réseaux des divers FAI. Ces GIX permettent d’inter-connecter les divers fournisseurs de services.

Il est possible alors de joindre directement le réseau hébergeant le serveur cible ou, indirectement, par l’intermédiaire de réseaux de transit. Un réseau de transit, comme son nom l’indique, ne sert (pour une connexion donnée) qu’à faire transiter les informations d’un réseau à un autre.

Finalement...
Plusieurs cas de figure sont possibles, du plus simple, où client et serveur sont sur le même réseau (pouvant être constitué de plusieurs sous-réseaux) comme, par exemple, un client Wanadoo qui veut accéder au portail Wanadoo, au cas le plus compliqué, où les informations passeront plusieurs GIX, plusieurs réseaux de transit, avant d’atteindre le réseau hébergeant le serveur. Ce sera souvent le cas lorsque client et serveur sont géographiquement situés sur des continents différents.

Comment identifier la route ?

Là encore, tous les OS sérieux proposent une commande pour la rechercher (Windows 95/98/Millenium n’en proposent pas, mais il existe des outils tiers permettant de le faire).

Pour Windows
C’est la commande tracert :

 

 

Pour Linux
C’est la commande traceroute :

 

Bien entendu, dans un cas comme dans l’autre, nous trouvons la même route, puisque la cible est la même (www.grenouille.com) et que les deux exemples sont pris à partir du même accès à l’internet (Wanadoo ADSL Pro).

Pour Mac OS X
Commande traceroute, comme sous Linux
(traceroute effectué vers grenouille.com, depuis un abonné Free dégroupé)

 

 

Interpréter le résultat

Itinéraire
Chaque ligne affichée, sauf la dernière, correspond à un routeur, autrement dit au passage d’un réseau à un autre.
•  la ligne 1 représente donc logiquement, la « passerelle par défaut », que nous avons identifiée plus haut ;
•  les lignes 2 à 6 représentent des routeurs qui sont dans le réseau de rance Telecom (n’oublions pas qu’ici, le FAI est Wanadoo) ;
•  la ligne 7 indique un routeur qui appartient à Proxad (l’opérateur Free). Son nom (th2-6k-2-a6.routers.proxad.net) indique également qu’il est situé sur le GIX Telehouse2 ;
•  la ligne 8 (th2-1-6k.routers.ovh.net) indique que l’on est maintenant sur un routeur appartenant à OVH (fournisseur de l’hébergement), lui aussi situé sur le GIX Telehouse2 (Telehouse2 est un important GIX situé à Paris, comme d’ailleurs la grande majorité des GIX français. Plus exactement, c’est un "Carrier Hotel" situé à Paris, qui héberge, entre autres, des GIX.)
•  la ligne 9 représente le serveur de grenouille.com.

Temps de réponse
Les trois durées indiquées représentent l’équivalant d’un ping sur le routeur correspondant.
Comme on peut le constater, les temps sont sensiblement identiques sur chaque ligne, ce qui à priori ne semble pas logique. En réalité, ceci indique que le temps de réponse global est principalement introduit par le premier secteur de la route, à savoir entre le client et sa passerelle par défaut.

Pour trouver un exemple qui ferait intervenir d’autres équipements de la route, il faudrait tracer une route beaucoup plus longue :

 

7  P2-0.AUVCR2.Aubervilliers.opentransit.net (193.251.128.117)  60.041 ms  60.253 ms  62.869 ms
8  P6-0.NYKCR2.New-york.opentransit.net (193.251.243.234)  138.636 ms  139.670 ms  143.527 ms

...

Ici, entre les lignes 7 et 8, nous traversons l’atlantique et là, ça introduit tout de même quelques millisecondes de plus. Les lignes suivantes introduisent également des latences supplémentaires.

Un autre exemple

Pour compléter l’exposé, voici un traceroute effectué toujours vers grenouille.com, mais depuis un abonné Free non dégroupé (Linux) :

 

 

Conclusions

Contrôler la route empruntée entre une source et une cible offre plusieurs informations :
•  vérifier que cette route existe, tout simplement, mais avec un bémol, que nous détaillerons plus bas ;
•  observer par quels réseaux transitent les informations ;
•  identifier les éventuels ralentissements sur une route. Il s’agit donc d’un outil simple de diagnostic réseau qui peut rendre bien des services pour identifier d’éventuels problèmes de connexion.

 

---

Le principeAvant toute chose, il faut savoir qu’un paquet de données envoyé sur un réseau contient toujours un compteur appelé TTL (Time To Life, durée de vie). Ce compteur peut contenir une valeur entière positive inférieure ou égale à 255. C’est l’émetteur du paquet qui décide de sa valeur initiale.
Ce compteur est décrémenté à chaque entrée dans un routeur. Lorsqu’il arrive à zéro, le routeur détruit ce paquet et envoie à l’émetteur dudit paquet un signal ICMP lui indiquant que son envoi a été détruit parce qu’il a épuisé son temps de vie.

Partant de là, la stratégie de traceroute est simple. Il lui suffit d’envoyer sur la cible un paquet avec un TTL commençant à 1, puis d’incrémenter ce TTL jusqu’à ce que la cible soit atteinte.

Identification des routeurs
Pratiquement, le premier paquet sera envoyé avec un TTL de 1. Il sera détruit par le premier routeur, qui signalera la situation au moyen d’un message ICMP à la source du paquet. En réalité, nous enverrons trois paquets identiques, qui correspondent aux trois temps de réponse annoncés à chaque ligne.
Puis, la source enverra trois paquets avec un TTL de 2, qui passera à 1 au premier routeur et à 0 au second, générant la seconde ligne de la route.
Et ainsi de suite jusqu’à atteindre la cible.

Simple non ?

Les paquets envoyés par la cible pourront être des signaux ICMP de type Echo Request, identiques au ping ou des paquets de type UDP. La commande traceroute de Linux génère par défaut des paquets UDP, mais il est possible de lui faire générer des paquets ICMP avec l’option -I. La commande tracert de Windows ne sait générer que des paquets ICMP.
Pratiquement, les mesures faites suivant l’une ou l’autre méthode sont quasiment identiques :

 

 

Les noms des routeurs
Les routeurs rencontrés sont identifiés par leur adresse IP. Les noms sont déduits par la commande traceroute en effectuant une résolution DNS inverse. Ceci explique que parfois, des routeurs restent sans nom. Le réseau n’a pas besoin de noms pour fonctionner, les IP suffisent. Les noms ne sont qu’une commodité humaine et certains routeurs n’ont pas de nom, ou ne sont pas enregistrés dans les DNS.

Il est possible d’utiliser traceroute en inhibant cette résolution inverse, avec l’option -n pour Linux et -d pour Windows :

 

 

Les effets pervers

Firewalls
Certains administrateurs de réseau choisissent de bloquer, au niveau de leurs firewalls, le protocole ICMP, voire UDP dans certaines conditions. Dans ces cas là, la commande s’arrêtera au firewall et l’on n’aura pas de moyen d’atteindre la cible.

Exemple : [root@helios root]# traceroute www.ac-aix-marseille.fr
traceroute to www.ac-aix-marseille.fr (195.83.252.48), 30 hops max, 38 byte packets
1  193.253.160.3 (193.253.160.3)  49.984 ms  49.992 ms  47.760 ms
2  ge0-1-288.ncmar302.marseille.francetelecom.net (80.10.209.162)  44.552 ms  46.421 ms  48.032 ms
3  pos3-2.nrlyo202.lyon.francetelecom.net (193.252.101.150)  55.334 ms  55.368 ms  52.935 ms
4  pos12-0.ntsta302.paris.francetelecom.net (193.252.103.110)  62.087 ms  60.211 ms  59.782 ms
5  pos9-0.ntsta202.Paris.francetelecom.net (193.252.161.57)  72.558 ms  61.913 ms  58.383 ms
6  193.251.126.58 (193.251.126.58)  78.910 ms  132.230 ms  210.691 ms
7  P12-0.PASCR2.Pastourelle.opentransit.net (193.251.241.98)  61.748 ms  61.500 ms  59.772 ms
8  P4-0.BAGCR3.Bagnolet.opentransit.net (193.251.241.118)  59.706 ms  59.872 ms  60.783 ms
9  P1-0.BAGBB1.Bagnolet.opentransit.net (193.251.241.145)  59.702 ms  81.062 ms  59.816 ms
10  193.51.185.30 (193.51.185.30)  64.816 ms  64.783 ms  65.959 ms
11  marseille-pos1-0.cssi.renater.fr (193.51.179.222)  71.381 ms  71.092 ms  74.772 ms
12  rrthd-marseille.cssi.renater.fr (193.51.181.21)  71.464 ms  72.916 ms  70.732 ms
13  194.214.68.1 (194.214.68.1)  124.046 ms  72.166 ms  71.821 ms
14  194.214.68.14 (194.214.68.14)  71.751 ms  73.916 ms  72.813 ms
15  194.214.68.58 (194.214.68.58)  71.386 ms  74.283 ms  73.203 ms
16  * * *
* * *

A partir de la ligne 16, la commande n’est plus opérationnelle, à cause d’un firewall, parce que le site de l’académie (www.ac-aix-marseille.fr) est bien en service, on y accède sans problème avec son navigateur.

Notez sur cet exemple un autre effet pervers, qui vient de l’architecture centralisée de l’internet français. Un client marseillais abonné chez wanadoo (réseau France Telecom), pour joindre un serveur marseillais situé sur le réseau Renater (réseau des facultés et centres de recherche) devra passer par Paris, parce que FT et Renater sont inter connectés à Paris.

Ce que l’on voit
Un routeur, ça a au moins deux adresses IP, puisqu’un routeur a, pour ainsi dire, un pied dans chaque réseau qu’il interconnecte. L’adresse IP que l’on observe est celle par laquelle on arrive sur le routeur et non celle par laquelle on sort.
Si l’on peut faire un traceroute inverse (retour), même si la route inverse est rigoureusement la même que la route prise à l’aller, c’est à dire que l’on passe par les mêmes routeurs, mais dans l’autre sens (ce qui n’est pas une obligation), on ne les verra pas avec la même IP, et peut-être même pas avec le même nom...

Exemple d’un traceroute entre abonnés internet, l’un chez Wanadoo et l’autre chez Free :

De Free vers Wanadoo :

 

 

De Wanadoo vers Free :

 

 

Les deux clients ont un firewall qui bloque le fonctionnement de la commande (ligne 9 dans les deux cas)

Bien qu’ici les routes aller et retour semblent être les mêmes, du moins au niveau des réseaux traversés, rien ne peut certifier que l’on passe par les mêmes routeurs physiques. L’important est que les deux routes existent.

Il peut parfaitement se faire que les deux routes ne soient pas du tout les mêmes, ce qui pose un problème philosophique de taille :
Nous visualisons toujours la route aller (source vers cible) et jamais la route retour. Hors, de part le fonctionnement même de traceroute, les paquets ICMP « durée de vie dépassée » qu’envoient chaque routeur à la source, empruntent chacun une route qui peut être différente et que l’on ne peut visualiser...
Le temps de réponse affiché tient compte des temps aller et retour, le temps retour peut être (beaucoup) plus long que le temps aller, suivant la route empruntée au retour...
Bref, on ne sait plus très bien ce que l’on mesure.

Un outil moins spartiate que tracert

Il existe de nombreux outils plus évolués que les commandes tracert ou traceroute, mais qui font la même chose ou à peu près (de façon plus jolie, plus ergonomique...).
Sous Windows, « Sam Spade » est un outil vite indispensable pour diagnostiquer diverses choses sur un réseau. Il propose, entre autres, un traceroute en mode fenêtré :

SamSpade for Windows

 

Vous trouverez cet outil « freeware » ici

Note du macounet de service : un tel outil (« Utilitaire de réseau ») est inclus dans les utilitaires Mac OS X.

Utilitaire de réseau Mac OS X

---

Pour aller plus loin

  la RFC 792 qui décrit le protocole ICMP (en français) ;
  L’internet rapide et parmanent pour comprendre comment sont inter-connectés les réseaux des opérateurs ;
  toujours L’internet rapide et parmanent pour comprendre le principe du routage (des connaissances approfondies de IP sont nécessaires) ;
  et encore L’internet rapide et permanent si vous voulez raffraîchir vos connaissances sur IP ;
  n’oubliez pas le site CCM fort utile ;
  ni le très bon site frameip.

 

From : http://www.piaf.asso.fr