TP09 Barbieri Fumasoli

+0.
01/05/2020 TP09 –IP/ICMP

Téléinformatique
Fumasoli Nabil & Barbieri Samuel

T-1a
HES-SO FRIBOURG
TP09 –IP/ICMP Fribourg, le 01.05.2020
Table des matières

1 Introduction..................................................................................................................................................... 3
2 Rapport technique ........................................................................................................................................ 3
2.1 Question 1.............................................................................................................................................. 3
2.2 Question 2.............................................................................................................................................. 4
2.3 Question 3.............................................................................................................................................. 4
2.4 Question 4.............................................................................................................................................. 4
2.5 Question 5.............................................................................................................................................. 5
2.6 Question 6.............................................................................................................................................. 6
2.7 Question 7.............................................................................................................................................. 7
2.8 Question 8.............................................................................................................................................. 7
2.9 Question 9.............................................................................................................................................. 9
2.10 Question 10 ......................................................................................................................................... 10
2.11 Question 11 ......................................................................................................................................... 10
2.12 Question 12 ......................................................................................................................................... 10
2.13 Question 13 ......................................................................................................................................... 11
2.14 Question 14 ......................................................................................................................................... 11
2.15 Question 15 ......................................................................................................................................... 12
2.16 Question 16 ......................................................................................................................................... 12
2.17 Question 17 ......................................................................................................................................... 13
2.18 Question 18 ......................................................................................................................................... 15
2.19 Question 19 ......................................................................................................................................... 15
3 Conclusion ..................................................................................................................................................... 16
4 Annexes........................................................................................................................................................... 16
4.1 Sources .................................................................................................................................................. 16
4.2 Tables des illustrations .................................................................................................................... 17
T-1a / Fumasoli Nabil & Barbieri Samuel Page 2 sur 17

1 Introduction
Durant ce travail pratique, nous allons utiliser l’outil traceroute en apprenant ses spécificités
(protocoles et interprétation des résultats). Nous allons analyser le fonctionnement de la
fragmentation IP encore plus en détail. Nous utiliserons Wireshark pour ces analyses.
2 Rapport technique
2.1 Question 1
Quels sont les protocoles utilisés pour réaliser la fonction de cette commande ? Quel
protocole est utilisé pour faire quoi ?
OK
Les protocoles utilisés lors de la commande « tracert » sont IP, ICMP et DNS. Notre machine
effectue des pings (ICMP Echo (ping) request) à chaque intermédiaire avec un TTL (Time-To-
Live) commençant à 1 (puis s’incrémente de 1 à chaque fois).
Le but est de recevoir une réponse (Time-to-live exceeded) de chaque périphérique et ainsi
connaître le délai entre les 2. Nous pouvons constater les délais dans l’encadré rouge. Il y a 3
colonnes étant donné que lors d’un ping, il y a 3x l’échange ICMP qui est effectué. Les valeurs
affichées ici sont le RTT (Round Trip Time – Durée de voyage aller-retour) de l’échange 1, 2
et 3. OK
Le protocole DNS est utilisé pour connaître le nom de domaine d’une adresse IP. Dans notre
exemple, l’adresse IP 192.168.1.1 est « internetbox.home » (voir encadré bleu). OK
Bien
Figure 1 | Traceroute vers 8.8.8.8
Voici la capture Wireshark qui nous donne encore plus de détail. On peut apercevoir
les requêtes ping et le retour dû au TTL expiré. De plus, les query DNS sont aussi existantes.
Bien
Figure 2 | Capture wireshark du traceroute

2.2 Question 2
Quel champ de l'entête IP est-il déterminant pour cette fonction ? Pourquoi ?
Le champ de l’entête IP qui est déterminant pour le traceroute est le TTL (Time-to-live). Il est
déterminant car c’est lui qui permet de dire quand la requête ping « se termine/ne peut pas
aller plus loin ». On commence le premier ping avec un TTL = 1 puis on l’incrémente de 1 à
chaque nouvelle requête. On va donc recevoir une réponse (Time-to-live exceeded) de
chaque périphérique et ainsi connaître le délai entre un périphérique A et B. Bien
et surtout la route !
2.3 Question 3
A combien de sauts (hops) se trouvent la destination ?
On peut voir dans la figure 1 de la question 1 qu’il y a 10 sauts pour atteindre l’adresse IP
8.8.8.8 (voir encadré en vert). OK
2.4 Question 4
Pour chaque hop, comment le nom logique (DNS) de l’interface du routeur qui nous répond
est-il déterminé ?
Notre PC (192.168.1.144) veut connaître le nom logique du routeur 62.203.8.1.
Il envoie une query en précisant qu’il aimerait remplir son cache DNS.
PTR NAME
1.8.2013.62.in-addr.arpa ?
Figure 3 | Requête DNS
Le routeur intermédiaire (192.168.1.1) va « transférer » la query plus loin et va recevoir une

query response de la part du bon routeur. Il connaît donc le nom logique de 62.203.8.1.
Figure 4 | Schéma requête / réponse DNS

Bien

Mais le routeur intermédiaire doit encore transférer cette information au PC. Il lui envoie donc
la query response. Notre PC peut ainsi remplir son cache DNS.
PTR NAME
1.8.2013.62.in-addr.arpa dynamic…swisscom.ch
Figure 5 | Entrée DNS
2.5 Question 5
Comment obtenir les mêmes informations (comme traceroute) avec quelques commandes
« ping » (+ une autre commande qui cherche le DNS) ? indice : chercher les solutions avec la
commande « ping / ? » et démontrer vos résultats au travers de copie(s) d’écran de votre
terminal.
La commande ping comporte une option « ttl » (ping -i) permettant de définir manuellement
le nombre de sauts que nous voulons effectuer. Pour déterminer le nombre de sauts jusqu’au
routeur de destination, nous pouvons lancer plusieurs fois la même commande en modifiant
à chaque fois cette valeur. Dès que nous aurons la bonne valeur, nous recevrons une réponse,
ce qui signifie que nous avons déterminé le nombre de sauts. et tous les routeurs traversés !
OK
Figure 6 | Traceroute manuel (commande ping avec option i)

La commande qui permet d’obtenir le nom d’un équipement d’après son adresse IP est
« nslookup x.x.x.x». Nous pouvons constater ici que le routeur domestique est la « porte de
sortie ».
OK
Figure 7 | Commande nslookup
2.6 Question 6
Comparer et commenter le résultat obtenu avec le résultat de la mesure précédente faite sur
votre réseau domestique.
Lors de l’exécution de la commande « tracert 8.8.8.8 » en étant connecté au réseau mobile

(via un partage de connexion), nous obtenons un résultat bien différent :
Figure 8 | Traceroute vers 8.8.8.8 (réseau mobile)
Seul 1 routeur (en plus de notre passerelle par défaut) a été configuré pour nous répondre
(voir 2.10 Question 10). Cependant, le nombre de sauts est identique. De plus, en explorant
la capture Wireshark, nous pouvons voir que plusieurs requêtes DNS ont été effectuées mais
qu’aucun nom pour les 2 routeurs n’a été trouvé.
Figure 9 | Capture wireshark (réseau mobile)

OK

2.7 Question 7
Sur la base de vos deux mesures, essayer d’en déduire un schéma du réseau simple (routeurs
et leurs adresses IP).
Bien
Figure 10 | Schéma réseau simple (d'après données traceroute)
2.8 Question 8
Documenter les résultats et comparer-les. Les paquets prennent-t-ils le même chemin aller
et retour ?
Pour cette question, nous avons fait le test depuis le PC de Nabil car il se trouve chez Salt et
ses captures étaient plus intéressantes que celles de Samuel qui se trouve chez Swisscom.
Sur la capture effectuée depuis le PC, nous constatons que nous traversons, à priori, 3
routeurs Salt (commençant par 10.xxx.xxx.xxx) avant d’atteindre un routeur Internet
(213.55.255.181) (encadrés en rouge). Puis, nous traversons 2 routeurs (encadrés en vert) dont
la configuration ne permet pas de répondre aux paquets ICMP. Enfin, nous arrivons chez
SWITCH en parcourant 5 routeurs (encadrés en bleu) avant d’atteindre notre cible, à savoir
leur site internet (switch.ch).
Figure 11 | Traceroute vers switch.ch

En comparant avec la même mesure faite depuis le site internet, nous constatons plusieurs
différences. La première réside dans les routeurs traversés pour sortir du réseau SWITCH (voir
encadré bleu). En comparant les noms et les adresses IP, nous voyons qu’ils sont différents à
l’aller et au retour. L’autre différence se situe au niveau des routeurs Internet et Salt avant
d’atteindre la destination. Leur nombre et leurs adresses sont différentes, ce qui prouve que
ce n’est pas la même route qui est utilisée (voir encadrés rouge).
Figure 12 | Traceroute depuis switch.ch vers notre IP publique
En conclusion, la route utilisée à l’aller n’est pas forcément la même que celle utilisée au
retour. De plus, le nombre de sauts est différent, ce qui signifie que le retour est plus court
que l’aller.
Bien

2.9 Question 9
Faire un schéma bidirectionnel avec les différents routeurs sur la route entre SWITCH et votre réseau domestique.
Figure 13 | Schéma bidirectionnel Bien

2.10 Question 10
Question générale : quelle est l’explication des entrées « * » ?
Les entrées avec « * » signifient que la configuration des routeurs traversés ne permet pas de
répondre aux paquets ICMP. Le blocage de ces réponses peut être lié à des raisons de sécurité
ou de performances. Cela ne signifie pas pour autant que la communication ne fonctionne
pas. Bien
2.11 Question 11
Donner la commande que vous avez utilisé pour envoyer un paquet de 3000B.
Ping -n 1 -l 3000 1.1.1.1 OK
2.12 Question 12
Analyser, documenter et expliquer la fragmentation de ces 3000 octets de données (nombre
de fragments, valeurs des champs et flags liés à la fragmentation, répartition des données
utiles entre les fragments, etc.).
Nous pouvons voir que le paquet de 3000 octets est divisé en 3 fragments (à la requête
comme à la réponse). A l’aller, les fragments ont tous le même ID (0xaced) pour signifier
qu’ils viennent du même paquet. Au retour, l’ID est 0x95b4. OK
OK
Figure 14 | Capture wireshark fragmentation
Le 1er fragment du paquet (ligne en rose, ICMP) a un offset de 0.
Figure 15 | Détails premier fragment
Le 2ème fragment a un offset de 1480. Le 3ème possède un offset de 2960 (voir figure 14). Les
3 fragments peuvent se reconstituer dans le bon ordre grâce à leur l’offset.
Concernant la répartition des données utiles entre les fragments, le 1er a 1472 bytes, le 2ème
1480 bytes et le 3ème 48 bytes. Nous pouvons trouver ces informations dans la couche « Data »
de chaque fragment. OK
Analyse des flags ? Bien

2.13 Question 13
Indiquer et commenter les résultats de la commande « netstat –s –p IP » (avant et après le
ping).
Globalement, plusieurs valeurs relatives aux paquets ont été changées. Cependant, le plus
intéressant ici est encadré en rouge :
• Réassemblage requis : après le ping, nous constatons que 3 fragments

supplémentaires nécessitent d’être réassemblés.
• Réassemblage réussi : un réassemblage supplémentaire a été réussi après le ping, ce
qui correspond à nos 3 fragments.
• Fragmentation de datagrammes réussies : la fragmentation de notre paquet a réussi.
• Fragments créés : le paquet a été fragmenté en 3.
OK
Figure 16 | netstat avant le ping Figure 17 | netstat après le ping
2.14 Question 14
Documenter et expliquer le résultat (commande et mesure).
L’option « -f » force à ne pas fragmenter. Dans ce cas, le paquet ne peut pas être réceptionné
sans avoir été fragmenté avant car la taille totale d’un paquet (entête compris) est de 1500
octets (voir question 16). OK
Figure 18 | Paquet avec mention "do not fragment"

2.15 Question 15
Refaire le même ping sans mesure Wireshark, mais cette fois-ci utiliser la commande « netstat
–s –p IP » (avant et après le ping) pour sortir des statistiques. Comparer les valeurs et expliquer
les différences.
Le nombre de paquets en sortie rejetés est incrémenté de 1 car notre paquet a été perdu/pas
réceptionné. Non, il n'a même pas été envoyé car trop gros (fragmentation)
Figure 19 | netstat avant ping Figure 20 | netstat après ping
2.16 Question 16
Quelle est la valeur maximale de Lmax dans la commande suivante : « ping -n 1 -l <Lmax> -
f 1.1.1.1 » (Windows) « ping -c 1 -s <Lmax> -M do 1.1.1.1 » (Linux) Expliquer le pourquoi de
cette valeur Lmax et pourquoi Lmax < 1480.
Nous avons remarqué sur nos mesures Wireshark que la taille utile d’un fragment ICMP n’est
pas la même que celle d’un fragment IPv4. Ceci est dû au fait que l’entête ICMP vaut 8 octets. OK
La taille totale maximale d’un paquet est de 1500 octets. Nous pouvons le constater dans la
figure 22 (Total Length: 1500). Dès lors, la taille maximale Lmax s’obtient en soustrayant à ces
1500 octets les 20 octets de l’entête IPv4 ainsi que les 8 octets de l’entête ICMP. 1472

Figure 21 | Taille utile d'un fragment ICMP Figure 22 | Taille utile d'un fragment IPv4
Comme nous pouvons voir ci-dessous, nous avons vérifié nos calculs en faisant 2 ping avec
des valeurs limites.
Très bien !
Figure 23 | Taille utile maximale d'un fragment
2.17 Question 17
Analyser les trames résultant de la commande « ping -r 8 160.98.12.9 ». Documenter,
expliquer le résultat et analyser les paquets IP correspondants dans la mesure.
L’option « -r » de la commande ping permet d’afficher le nombre maximal de routeurs

traversés pour atteindre la destination. Ceci permet de voir les routes utilisées à l’aller et au
retour.
-r (record route) permet initialement d'enregistrer les routes

À l’aide de la capture d’écran ci-dessous qui a été fournie, il est possible de déterminer par
quels routeur le paquet ICMP est passé.
Figure 24 | Détermination de la route grâce à la commande ping
Dans la capture Wireshark également fournie, nous pouvons retrouver les mêmes routes que
dans la capture ci-dessus.
Figure 25 | Capture wireshark contenant les routes
Ceci signifie que la requête du paquet ICMP est passée par les routeurs 160.98.44.2 et
160.92.12.10 avant d’atteindre sa destination (160.98.12.9). Puis, pour informer la source que
l’hôte a été trouvé, la réponse ICMP passe par les routeurs 160.98.44.1 et 160.98.30.1 avant
de l’atteindre. OK

2.18 Question 18
Comparer avec le résultat d’un traceroute vers 160.98.12.9.
Contrairement à la commande ping -r, la commande tracert n’affiche pas les routeurs
traversés pour le retour. De ce fait, nous ne savons pas si le paquet ICMP utilise le même
itinéraire à l’aller et au retour.
OK
Figure 26 | Traceroute vers 160.98.12.9 (pour comparaison avec ping -r)
2.19 Question 19
Quelle est la longueur de l’entête IP dans la réponse au ping ? Expliquer pourquoi cette valeur.
La longueur de l’entête IP est de 56 octets. Ceci est dû au fait que nous avons 20 octets pour
l’entête IPv4 par défaut + 36 octets pour les options regroupant l’enregistrement des routes.
OK
Figure 27 | Capture wireshark longueur de l'entête IP

3 Conclusion
Pour conclure, ce TP nous a permis d’en savoir davantage sur la fragmentation IP et de
découvrir la commande traceroute. Nous avons apprécié le fait d’analyser en détail les
protocoles utilisés et de devoir réfléchir à la logique du fonctionnement de la fragmentation.
4 Annexes
4.1 Sources
https://fr.wikipedia.org/wiki/Nslookup
https://fr.wikipedia.org/wiki/Ping_(logiciel)
https://www.lifewire.com/ping-command-2618099
https://www.inmotionhosting.com/support/website/ssh/read-traceroute/

4.2 Tables des illustrations

Figure 1 | Traceroute vers 8.8.8.8 ..................................................................................................................... 3
Figure 2 | Capture wireshark du traceroute ................................................................................................. 3
Figure 3 | Requête DNS ....................................................................................................................................... 4
Figure 4 | Schéma requête / réponse DNS .................................................................................................. 4
Figure 5 | Entrée DNS ........................................................................................................................................... 5
Figure 6 | Traceroute manuel (commande ping avec option i) ............................................................ 5
Figure 7 | Commande nslookup ....................................................................................................................... 6
Figure 8 | Traceroute vers 8.8.8.8 (réseau mobile) .................................................................................... 6
Figure 9 | Capture wireshark (réseau mobile) ............................................................................................. 6
Figure 10 | Schéma réseau simple (d'après données traceroute) ....................................................... 7
Figure 11 | Traceroute vers switch.ch ............................................................................................................. 7
Figure 12 | Traceroute depuis switch.ch vers notre IP publique .......................................................... 8
Figure 13 | Schéma bidirectionnel ................................................................................................................... 9
Figure 14 | Capture wireshark fragmentation ........................................................................................... 10
Figure 15 | Détails premier fragment ........................................................................................................... 10
Figure 16 | netstat avant le ping .................................................................................................................... 11
Figure 17 | netstat après le ping .................................................................................................................... 11
Figure 18 | Paquet avec mention "do not fragment" ............................................................................. 11
Figure 19 | netstat avant ping ......................................................................................................................... 12
Figure 20 | netstat après ping ......................................................................................................................... 12
Figure 21 | Taille utile d'un fragment ICMP ............................................................................................... 13
Figure 22 | Taille utile d'un fragment IPv4 ................................................................................................. 13
Figure 23 | Taille utile maximale d'un fragment....................................................................................... 13
Figure 24 | Détermination de la route grâce à la commande ping .................................................. 14
Figure 25 | Capture wireshark contenant les routes ............................................................................... 14
Figure 26 | Traceroute vers 160.98.12.9 (pour comparaison avec ping -r) .................................... 15
Figure 27 | Capture wireshark longueur de l'entête IP .......................................................................... 15

TP09 Barbieri Fumasoli

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TP09 Barbieri Fumasoli

Transféré par

Droits d'auteur :

Formats disponibles

+0.

01/05/2020 TP09 –IP/ICMP

Fumasoli Nabil & Barbieri Samuel

Table des matières

T-1a / Fumasoli Nabil & Barbieri Samuel Page 2 sur 17

Figure 1 | Traceroute vers 8.8.8.8

T-1a / Fumasoli Nabil & Barbieri Samuel Page 3 sur 17

Notre PC (192.168.1.144) veut connaître le nom logique du routeur 62.203.8.1.

Figure 3 | Requête DNS

Le routeur intermédiaire (192.168.1.1) va « transférer » la query plus loin et va recevoir une

Figure 4 | Schéma requête / réponse DNS

T-1a / Fumasoli Nabil & Barbieri Samuel Page 4 sur 17

Figure 5 | Entrée DNS

Figure 6 | Traceroute manuel (commande ping avec option i)

T-1a / Fumasoli Nabil & Barbieri Samuel Page 5 sur 17

Figure 7 | Commande nslookup

Lors de l’exécution de la commande « tracert 8.8.8.8 » en étant connecté au réseau mobile

Figure 8 | Traceroute vers 8.8.8.8 (réseau mobile)

Figure 9 | Capture wireshark (réseau mobile)

T-1a / Fumasoli Nabil & Barbieri Samuel Page 6 sur 17

Figure 10 | Schéma réseau simple (d'après données traceroute)

Figure 11 | Traceroute vers switch.ch

T-1a / Fumasoli Nabil & Barbieri Samuel Page 7 sur 17

Figure 12 | Traceroute depuis switch.ch vers notre IP publique

T-1a / Fumasoli Nabil & Barbieri Samuel Page 8 sur 17

Figure 13 | Schéma bidirectionnel Bien

T-1a / Fumasoli Nabil & Barbieri Samuel Page 9 sur 17

Ping -n 1 -l 3000 1.1.1.1 OK

Le 1er fragment du paquet (ligne en rose, ICMP) a un offset de 0.

Figure 15 | Détails premier fragment

T-1a / Fumasoli Nabil & Barbieri Samuel Page 10 sur 17

• Réassemblage requis : après le ping, nous constatons que 3 fragments

Figure 16 | netstat avant le ping Figure 17 | netstat après le ping

Figure 18 | Paquet avec mention "do not fragment"

T-1a / Fumasoli Nabil & Barbieri Samuel Page 11 sur 17

Figure 19 | netstat avant ping Figure 20 | netstat après ping

T-1a / Fumasoli Nabil & Barbieri Samuel Page 12 sur 17

Figure 23 | Taille utile maximale d'un fragment

L’option « -r » de la commande ping permet d’afficher le nombre maximal de routeurs

T-1a / Fumasoli Nabil & Barbieri Samuel Page 13 sur 17

Figure 24 | Détermination de la route grâce à la commande ping

Figure 25 | Capture wireshark contenant les routes

T-1a / Fumasoli Nabil & Barbieri Samuel Page 14 sur 17

Figure 27 | Capture wireshark longueur de l'entête IP

T-1a / Fumasoli Nabil & Barbieri Samuel Page 15 sur 17

T-1a / Fumasoli Nabil & Barbieri Samuel Page 16 sur 17

4.2 Tables des illustrations

T-1a / Fumasoli Nabil & Barbieri Samuel Page 17 sur 17

Vous aimerez peut-être aussi