AccueilPortailFAQRechercherS'enregistrerMembresGroupesConnexion

Partagez | 
 

 TraceRoute [Partie 2] (FIN)

Voir le sujet précédent Voir le sujet suivant Aller en bas 
AuteurMessage
>¦WebMaster¦<
Admin
Admin
avatar

Nombre de messages : 86
Localisation : Montréal
Date d'inscription : 29/12/2005

MessageSujet: TraceRoute [Partie 2] (FIN)   Ven 24 Mar à 16:32

Nous avons vu globalement ce que l’on peut obtenir comme informations avec cet outil. Nous allons ici en détailler un peu plus le fonctionnement et voir les limites des analyses que l’on peut faire avec.



La technique de traceroute

19 mai 2004

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 :


[root@helios root]# traceroute www.grenouille.com
traceroute to grenouille.com (213.186.35.33), 30 hops max, 38 byte packets
1 193.253.160.3 (193.253.160.3) 49.020 ms 53.429 ms 48.136 ms
2 ge0-1-289.ncmar302.marseille.francetelecom.net (80.10.209.226) 45.530 ms 45.420 ms 48.410 ms
3 pos3-2.nrlyo202.lyon.francetelecom.net (193.252.101.150) 70.188 ms 53.748 ms 56.003 ms
4 pos12-0.ntsta302.paris.francetelecom.net (193.252.103.110) 194.985 ms 66.390 ms 235.187 ms
5 pos0-0-0-0.nosta102.paris.francetelecom.net (193.252.103.117) 61.999 ms 61.445 ms 61.826 ms
6 193.252.103.245 (193.252.103.245) 61.093 ms 70.241 ms 62.656 ms
7 th2-6k-2-a6.routers.proxad.net (213.228.3.9) 61.242 ms 61.923 ms 60.810 ms
8 th2-1-6k.routers.ovh.net (213.186.32.250) 61.784 ms 61.637 ms 61.480 ms
ns351.ovh.net (213.186.35.33) 62.476 ms 62.410 ms 62.801 ms

[root@helios root]# traceroute -I www.grenouille.com
traceroute to grenouille.com (213.186.35.33), 30 hops max, 38 byte packets
1 193.253.160.3 (193.253.160.3) 48.212 ms 49.381 ms 49.246 ms
2 ge0-1-289.ncmar302.marseille.francetelecom.net (80.10.209.226) 51.695 ms 46.860 ms 45.703 ms
> 3 pos3-2.nrlyo202.lyon.francetelecom.net (193.252.101.150) 52.818 ms 53.768 ms 58.622 ms
4 pos12-0.ntsta302.paris.francetelecom.net (193.252.103.110) 58.817 ms 61.432 ms 59.348 ms
5 pos0-0-0-0.nosta102.paris.francetelecom.net (193.252.103.117) 80.819 ms 59.674 ms 59.750 ms
6 193.252.103.245 (193.252.103.245) 96.838 ms 60.856 ms 64.975 ms
7 th2-6k-2-a6.routers.proxad.net (213.228.3.9) 62.070 ms 59.626 ms 60.428 ms
8 th2-1-6k.routers.ovh.net (213.186.32.250) 61.727 ms 61.684 ms 60.788 ms
9 ns351.ovh.net (213.186.35.33) 59.345 ms 61.533 ms 60.000 ms
[root@helios root]#



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 :


[root@helios root]# traceroute -n www.grenouille.com
traceroute to grenouille.com (213.186.35.33), 30 hops max, 38 byte packets
1 193.253.160.3 48.040 ms 56.429 ms 54.340 ms
2 80.10.209.226 44.764 ms 46.971 ms 45.490 ms
3 193.252.101.150 55.754 ms 55.560 ms 54.310 ms
4 193.252.103.110 62.424 ms 59.711 ms 59.073 ms
5 193.252.103.117 59.350 ms 60.026 ms 59.832 ms
6 193.252.103.245 59.268 ms 59.748 ms 59.659 ms
7 213.228.3.9 60.713 ms 59.398 ms 59.407 ms
8 213.186.32.250 59.671 ms 60.100 ms 60.012 ms
9 213.186.35.33 62.022 ms 61.125 ms 59.784 ms
[root@helios root]#



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 :


traceroute to 82.254.100.210 (82.254.100.210), 30 hops max, 38 byte packets
1 193.253.160.3 (193.253.160.3) 49.092 ms 48.815 ms 48.445 ms
2 GE1-2-278.ncmar302.Marseille.francetelecom.net (80.10.209.130) 48.027 ms 46.218 ms 57.819 ms
3 pos3-1.nrlyo202.Lyon.francetelecom.net (193.252.101.78) 55.369 ms 54.066 ms 55.977 ms
4 pos12-0.ntsta302.paris.francetelecom.net (193.252.103.110) 61.408 ms 80.927 ms 62.094 ms
5 pos0-0-0-0.nosta102.paris.francetelecom.net (193.252.103.117) 60.625 ms 60.402 ms 60.799 ms
6 193.252.103.245 (193.252.103.245) 96.092 ms 206.448 ms 204.356 ms
7 vlq-6k-2-a6.routers.proxad.net (213.228.3.2) 59.570 ms 59.125 ms 59.854 ms
8 lns-vlq-34.routers.proxad.net (212.27.37.135) 60.596 ms 61.595 ms 61.764 ms
9 * * *



De Wanadoo vers Free :


traceroute to 81.248.157.2 (81.248.157.2), 30 hops max, 38 byte packets
1 192.168.254.254 (192.168.254.254) 77.602 ms 75.361 ms 72.546 ms
2 vlq-6k-2-a11.routers.proxad.net (212.27.37.190) 81.982 ms 80.366 ms 75.324 ms
3 th1-6k-2-a6.routers.proxad.net (213.228.3.6) 80.724 ms 76.804 ms 72.377 ms
4 GE1-27.nosta102.Paris.francetelecom.net (193.252.103.246) 80.681 ms 67.788 ms 65.691 ms
5 pos5-0.ntsta302.Paris.francetelecom.net (193.252.103.118) 65.108 ms 69.131 ms 65.011 ms
6 pos9-0.nrlyo202.Lyon.francetelecom.net (193.252.103.109) 75.432 ms 76.656 ms 73.272 ms
7 pos9-0.ncmar302.Marseille.francetelecom.net (193.252.101.149) 79.524 ms 83.071 ms 75.993 ms
8 bsmar207-NET2GE9-0.279.francetelecom.net (80.10.209.201) 84.398 ms 80.792 ms 82.218 ms
9 * * *



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
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://www.Radiohacktive.tk
 
TraceRoute [Partie 2] (FIN)
Voir le sujet précédent Voir le sujet suivant Revenir en haut 
Page 1 sur 1
 Sujets similaires
-
» Quelle partie de votre cerveau utilisez-vous ?
» RPGMAKERVXACE! écran titre nouvelle partie ect...
» Supprimer une partie de trace
» Offre Ideo, résiliation de la partie internet
» Resiliation partie box sur forfait Ideo

Permission de ce forum:Vous ne pouvez pas répondre aux sujets dans ce forum
 :: Archives :: Hacking-
Sauter vers: