TP 3 — Les protocoles de communication
Huit captures Wireshark décortiquées : ARP et le ping à travers la passerelle, l'erreur ICMP, la fragmentation, UDP, puis TCP — ouverture, données et fermeture de connexion — avec le geste à faire dans Wireshark pour chaque réponse.
Le geste du TP
Observer les protocoles du ch. 3 en vrai, dans des trames
capturées : huit fichiers captureN.pcapng (archive captures.zip sur Moodle) à ouvrir dans
Wireshark, chacun illustrant un protocole ou un mécanisme. Les questions annotées du symbole
d'un cahier sont des questions de cours — les réponses sont dans le chapitre.
La configuration de Wireshark demandée avant les captures 5 à 8
Edit → Preferences → Protocols : pour IPv4, désactiver Reassemble fragmented IP
datagrams (sinon Wireshark recolle les fragments et la fragmentation devient invisible) ; pour
TCP, désactiver Relative sequence numbers (sinon les numéros de séquence affichés
commencent à 0 et on ne voit pas les vrais numéros initiaux — c'est justement ce qu'on cherche).
Les filtres qui font gagner du temps
La barre de filtre d'affichage : arp, icmp, tcp, udp — et cliquer sur un champ dans le
panneau du milieu sélectionne l'octet correspondant dans la trame. Tous les champs cités
ci-dessous (Total Length, Time to Live, Identification, Fragment Offset…) sont lisibles
directement dans le panneau du milieu, au niveau de l'en-tête concerné.
Capture 1 — ARP : la requête avant le ping
Contexte de la capture : un ping de la machine 192.168.1.5 vers 210.10.10.1, et deux
trames qui précèdent tout écho.
ARP (Address Resolution Protocol). Il sert à trouver l'adresse MAC (niveau 2) associée à une adresse IP (niveau 3) : sans elle, aucune trame ne peut être émise, car la trame Ethernet s'adresse à une MAC, pas à une IP.
ff:ff:ff:ff:ff:ff — l'adresse de diffusion. La requête ARP est posée à tout le lien
parce que la machine ne connaît pas encore la MAC cherchée : c'est justement la question « qui
a cette IP ? ».
La MAC de la machine qui a posé la question (192.168.1.5). La réponse ARP part en direct, en unicast, uniquement vers le demandeur — pas en diffusion : elle ne l'intéresse que lui.
Celle de la passerelle par défaut du réseau local — 192.168.1.254 dans la capture. Le
champ à lire dans la trame est Target IP (à ne pas confondre avec Sender IP, qui est la
machine qui demande).
La destination 210.10.10.1 est hors du réseau local 192.168.1.0/24 : la remise sera
indirecte, confiée au routeur de sortie. La requête ARP cherche donc l'adresse MAC de la
passerelle — le seul destinataire direct de la trame. Le paquet IP, lui, garde intacte sa
destination finale 210.10.10.1 : deux niveaux, deux adresses, deux rôles.
Capture 2 — un ping, et son en-tête IP
Contexte : un échange ICMP Echo / Echo Reply entre deux machines, deux trames.
La pile complète du ping : Ethernet (la trame), IPv4 (le paquet), ICMP (Echo Request puis Echo Reply). Trois en-têtes superposés dans chaque trame — l'encapsulation du cours visible en clair.
ping : un ICMP de type 8 (Echo) puis type 0 (Echo Reply), avec les mêmes données
dans les deux sens.
Le champ Total Length de l'en-tête IP (en octets, en-tête IP compris). Pour un ping standard : 84 octets — 20 d'en-tête IP + 8 d'en-tête ICMP + 56 de données. La trame Ethernet, elle, est plus lourde (14 octets d'en-tête + 4 de FCS).
Le champ IHL, en mots de 32 bits. Avec 5 mots = 20 octets : le ping n'utilise pas d'options. Si IHL valait 6, l'en-tête ferait 24 octets.
64 − TTL de la trame 2. Le TTL de l'Echo Reply est décrémenté de 1 à chaque routeur traversé au retour ; la valeur lue dans la capture donne directement le nombre de routeurs (par exemple un TTL de 62 → 2 routeurs). Le TTL part à 64 car c'est la valeur initiale posée par la machine qui répond.
Capture 3 — un paquet d'erreur ICMP
Contexte : une seule trame, un ICMP qui signale une erreur — le type de paquet que le cours résume en « IP n'est pas fiable, ICMP signale ».
Un Destination Unreachable (ICMP type 3), dont le code précise la raison — code 3, par exemple : port unreachable, l'application visée n'écoute pas sur ce port. La cause : le datagramme a bien été acheminé jusqu'à un point du réseau, mais la livraison a échoué (application injoignable, réseau suivant inaccessible selon le code).
Elles sont dans le début du paquet détruit, que le paquet d'erreur ICMP transporte toujours (jusqu'à 576 octets) — c'est fait exprès pour retrouver la communication fautive : lisez les adresses IP de l'en-tête embarqué, pas celles de l'ICMP lui-même.
Le même extrait embarqué contient la suite : le protocole de transport et les numéros de ports source et destination du paquet qui a échoué — donc l'application visée.
La source du paquet ICMP : l'équipement qui a abandonné la livraison — dans cette capture, un routeur intermédiaire (pas la machine destinataire, qui n'a jamais reçu le paquet). Un paquet d'erreur ICMP ne génère jamais d'erreur ICMP à son tour.
Capture 4 — un ping fragmenté
Contexte : un ICMP Echo Request trop gros pour le réseau de sortie, parti en plusieurs fragments. (N'oubliez pas d'avoir désactivé Reassemble fragmented IP datagrams.)
Au niveau réseau (couche 3, IPv4) : c'est IP qui découpe et le destinataire final qui recolle. TCP et UDP n'y voient que du feu — ils envoient leurs segments, IP se débrouille — et les routeurs traversés ne recollent jamais, ils re-fragmentent au besoin.
Le champ Fragment Offset se compte en unités de 8 octets : il donne la position du fragment dans le datagramme initial. La 2ᵉ trame démarre là où la 1ᵉʳᵉ s'arrête, donc la quantité de données de la 1ᵉʳᵉ trame vaut offset × 8 octets (offset 185 → 1480 octets).
Données du 1ᵉʳ fragment + 20 octets d'en-tête IP = MTU. Avec 1480 de données : 1480 + 20 = 1500 — le MTU d'Ethernet. C'est le MTU qui a décidé de la taille des fragments, la fragmentation « remplit » toujours au maximum.
Le drapeau MF (More Fragments) vaut 0 uniquement sur le dernier fragment — sur tous les autres il vaut 1 (« encore des fragments après »). Complétez la vérification avec les offsets : ils doivent recoller les uns aux autres sans trou ni recouvrement jusqu'à la fin.
Capture 5 — UDP, le service minimum
Contexte : un datagramme UDP capturé, son en-tête à mesurer.
UDP — le champ Protocol de l'en-tête IP vaut 17 (TCP vaudrait 6). C'est ce champ qui dit à qui remettre la charge utile du paquet.
L'éphémère (> 1024) est le côté client ; le port connu (IANA, /etc/services) est
celui du service interrogé — par exemple 53 pour un DNS. Le port source sert au serveur à
savoir où répondre.
La charge utile de UDP = Longueur totale IP − en-tête IP − en-tête UDP. L'en-tête UDP se déduit du champ Length de UDP, qui comprend en-tête + données : un en-tête UDP fait toujours 8 octets (2 ports, la longueur, la somme de contrôle) — donc données = longueur UDP − 8.
Capture 6 — l'ouverture d'une connexion TCP
Contexte : trois segments entre un client et un serveur, aucune donnée applicative.
TCP — champ Protocol = 6.
La mise en connexion : le three-way handshake (SYN, SYN + ACK, ACK). Il sert à partager un état cohérent avant la moindre donnée : les deux parties échangent leurs numéros de séquence initiaux, dont dépendent toute l'ordonnancement et les acquittements.
Le seq du SYN du client (ISN côté client) et le seq du SYN + ACK du serveur (ISN côté serveur) — deux valeurs indépendantes, une par sens de transmission. Sans Relative sequence numbers, ce sont les vrais numéros aléatoires de la RFC ; avec, Wireshark affiche 0 et 1.
Le MSS (Maximum Segment Size) est annoncé dans les options des SYN, typiquement 1460 : c'est le maximum de données par segment. Par rapport au MTU : MSS = MTU − 20 (en-tête IP) − 20 (en-tête TCP) — 1500 − 40 = 1460. Bien calé, un segment TCP donne une trame de 1500 octets : jamais de fragmentation IP.
Capture 7 — l'échange de données TCP
Contexte : des segments de données avec leurs acquittements — les numéros prennent le relais des drapeaux.
Le seq du segment = la position du premier octet de ses données dans le flux envoyé. Un segment qui démarre au ISN avec 450 octets de données occupe donc les octets seq à seq + 449.
L'ack vaut le numéro du prochain octet attendu — par exemple seq + 450 pour acquitter un segment de 450 octets. La différence : le seq repère ce que j'émets (position dans mon flux), l'ack confirme ce que j'ai reçu dans l'ordre (position dans le flux de l'autre). Deux compteurs, un par sens — d'où quatre champs de numéros dans l'en-tête TCP.
PSH (push) : le segment contient des données à remonter à l'application sans attendre. Les autres drapeaux vus en cours : SYN, ACK, FIN, RST, URG.
Capture 8 — la fin d'une connexion TCP
La fermeture de connexion : FIN + ACK, ACK, puis FIN + ACK, ACK. Chaque partie doit clore son propre sens de transmission — quatre segments, deux FIN et deux ACK, car une connexion TCP est full-duplex : un côté peut avoir fini d'émettre pendant que l'autre continue.
Les pièges de ce TP
L'offset de fragmentation est en unités de 8 octets (l'erreur classique : lire 185 et croire que le fragment démarre à 185 octets, alors qu'il démarre à 185 × 8 = 1480) ; la taille de l'en-tête IP est en mots de 32 bits (IHL 5 = 20 octets) ; et les numéros TCP relatifs de Wireshark masquent l'échange des numéros initiaux — d'où la configuration demandée au début. Enfin, un ping qui traverse la passerelle fait apparaître une requête ARP vers la passerelle, pas vers le destinataire final.
tp3-protocoles.pdf
R3.06 · TP 3 — Yvan Peter, IUT de Lille · 2 pages
Chargement du document…
Dernière mise à jour le
TP 1 — Gestion des adresses IPv4
Kathará, commande ip, table de routage et passerelle par défaut, configuration permanente, plans d'adressage VLSM — l'énoncé et le corrigé pas à pas des trois labs.
TP 4 — IPv6 : fonctionnement et configuration
Les trois labs IPv6 corrigés : autoconfiguration minimale et détection d'adresse dupliquée, SLAAC avec annonce de routeur sous Kathará, puis renumérotation d'un réseau sur FRR avec les durées de validité et de préférence.