9. Tracer le chemin suivi par le trafic réseau

Couches réseau & application

Si la commande ping du protocole ICMP permet d'obtenir des informations l'état de l'hôte destination, elle ne permet pas de tracer le chemin suivi par les paquets IP. C'est justement l'objectif du service traceroute dont le principe est le suivant :

  • La source émet un premier message avec la valeur 1 dans le champ TTL de l'en-tête IP.

  • Le routeur qui reçoit ce message décrémente la valeur du champ TTL de l'en-tête IP et obtient 0. Il jette donc le message et émet un message ICMP à destination de l'émetteur indiquant qu'il est impossible d'atteindre la destination.

  • La source émet un deuxième message avec la valeur 2 dans le champ TTL de l'en-tête IP.

  • Cette fois-ci, c'est le deuxième routeur qui décrémente la valeur du champ TTL et obtient 0. C'est donc à lui d'émettre un message ICMP indiquant qu'il est impossible d'atteindre la destination.

  • Ainsi de suite avec les valeurs du champ TTL de l'en-tête IP 3, 4, 5, etc.

[Avertissement] Avertissement

Pour des raisons de sécurité, il peut être nécessaire de cacher le chemin suivi par le trafic utilisateur. C'est la raison pour laquelle les résultats obtenus varient énormément suivant les contextes d'interconnexion réseau. Il devient de plus en plus difficile d'obtenir une information correcte.

Pour illustrer le fonctionnement du service, on peut utiliser la commande mtr fournie par la paquet mtr-tiny. Cette commande possède de nombreuses options et fournit une présentation dynamique des résultats. Voici deux exemples qui illustrent la «dispersion» des résultats :

Exemple de rapport basé sur ICMP echo
$ mtr -4 -c 10 --report www.nic.fr
Start: 2018-01-08T14:55:31+0100
HOST: inetdoc-ttn                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- h7.tetaneutral.net         0.0%    10    0.3   0.3   0.3   0.3   0.0
  2.|-- te0-0-2-3.rcr11.tls01.atl  0.0%    10    1.1   1.4   1.0   3.6   0.8
  3.|-- te0-2-1-2.rcr21.bod01.atl  0.0%    10    4.1   4.2   4.1   4.4   0.1
  4.|-- be2840.rcr21.eas02.atlas.  0.0%    10    7.8   7.8   7.7   7.9   0.1
  5.|-- be2839.ccr52.bio02.atlas.  0.0%    10    8.8   8.8   8.7   8.8   0.1
  6.|-- be3358.ccr32.mad05.atlas.  0.0%    10   13.6  13.5  13.3  13.7   0.2
  7.|-- ae-20.r01.mdrdsp03.es.bb.  0.0%    10   13.6  13.6  13.4  14.3   0.2
  8.|-- ae-7.r24.londen12.uk.bb.g  0.0%    10   30.4  30.5  30.3  31.3   0.4
  9.|-- ae-1.r25.londen12.uk.bb.g  0.0%    10   30.4  30.4  30.3  30.9   0.2
 10.|-- ae-2.r04.parsfr01.fr.bb.g  0.0%    10   30.6  30.6  30.5  30.8   0.1
 11.|-- ae-5.r03.parsfr02.fr.bb.g  0.0%    10   30.7  30.7  30.6  30.9   0.1
 12.|-- ae-8.r02.parsfr02.fr.bb.g  0.0%    10   30.6  30.8  30.6  31.0   0.2
 13.|-- 82.112.96.178              0.0%    10   31.1  31.0  30.9  31.1   0.1
 14.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 15.|-- isg-th3.interco.nic.fr     0.0%    10   30.3  30.3  30.3  30.4   0.1
 16.|-- lb01-1.nic.fr              0.0%    10   30.5  30.4  30.4  30.6   0.1
Exemple de rapport basé sur UDP
$ mtr -4 -u -c 10 --report www.nic.fr
Start: 2018-01-08T14:57:32+0100
HOST: inetdoc-ttn                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- h7.tetaneutral.net         0.0%    10    0.3   0.3   0.3   0.3   0.0
  2.|-- te0-0-2-3.rcr11.tls01.atl  0.0%    10    1.1   1.1   1.0   1.2   0.1
  3.|-- te0-2-1-2.rcr21.bod01.atl  0.0%    10    4.2   4.3   4.2   4.4   0.1
  4.|-- be2840.rcr21.eas02.atlas.  0.0%    10    7.8   7.8   7.7   8.0   0.1
  5.|-- be2838.ccr51.bio02.atlas.  0.0%    10    8.8   8.8   8.6   9.2   0.2
  6.|-- be3357.ccr31.mad05.atlas.  0.0%    10   13.6  13.5  13.2  13.7   0.1
  7.|-- ae-4.r01.mdrdsp03.es.bb.g  0.0%    10   14.3  13.6  13.4  14.3   0.3
  8.|-- ae-7.r24.londen12.uk.bb.g  0.0%    10   30.3  28.2  27.3  30.3   1.1
  9.|-- ae-1.r25.londen12.uk.bb.g  0.0%    10   27.3  28.8  27.3  31.5   1.4
 10.|-- ae-2.r04.parsfr01.fr.bb.g  0.0%    10   27.7  28.6  27.7  29.9   0.8
 11.|-- ae-5.r03.parsfr02.fr.bb.g  0.0%    10   28.5  28.5  27.1  31.2   1.5
 12.|-- ae-8.r02.parsfr02.fr.bb.g  0.0%    10   27.8  28.4  27.0  30.7   1.0
 13.|-- 82.112.96.178              0.0%    10   31.1  29.1  27.6  31.1   1.1
 14.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

La comparaison entre les deux rapports montre que le protocole ICMP subit un filtrage important relativement aux requêtes UDP. Les très nombreuses attaques de type «déni de service distribué» basées sur ICMP ont nécessité la mise en place de protections qui entraînent quelques désagréments dans les tests de fonctionnement des réseaux.

Pour aller plus loin dans les manipulations sur le tracé de route, il existe d'autres outils intéressants tels que tracepath fourni par le paquet iputils-tracepath.