====== Livraisons ====== ===== La livraison des données ===== Voyons un peu les mécanismes mis en oeuvre pour le transport de données d'un hôte à un autre. Imaginons une application qui doive envoyer des données d'un hôte A1 à un hôte A2. Nous sommes ici sur la couche 7. Les données sont prêtes à être envoyées, elles vont descendre les diverses couches du système. (Nous sommes sur un système TCP/IP) * D'abord, il faudra résoudre les noms en adresses IP. * Construire les sockets nécessaires à l'établissement de la connexion. * Plus bas encore, il va falloir trouver l'adresse physique des hôtes, parce que la couche liaison (couche 2) ne sait utiliser que ce moyen.\\ A ce niveau, deux cas de figure peuvent se présenter {{ :routage:livraisons.gif |Livraisons directe et indirecte}} ==== La livraison directe ==== Les deux hôtes sont sur le même réseau physique (et logique), c'est le cas le plus simple. La source et la cible se trouvant sur le même réseau, il suffit qu'il y ait quelque part une table de correspondance entre adresse IP et adresse MAC. Cette table de correspondance est construite localement, sur chaque hôte au moyen du protocole ARP. Cette table ARP est visualisable avec la commande "arp -a" Exemple: * Je vérifie que la table ARP est bien vide. * Depuis mon poste pchris, je fais un ping sur gw1. * Je regarde à nouveau l'état de ma table ARP E:\>arp -a Aucune entrée ARP trouvée E:\>ping gw1.maison.mrs Envoi d'une requête 'ping' sur gw1.maison.mrs [192.168.0.250] avec 32 octets de données : Réponse de 192.168.0.250 : octets=32 temps<10 ms TTL=255 Réponse de 192.168.0.250 : octets=32 temps<10 ms TTL=255 Réponse de 192.168.0.250 : octets=32 temps<10 ms TTL=255 Réponse de 192.168.0.250 : octets=32 temps<10 ms TTL=255 Statistiques Ping pour 192.168.0.250: Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%), Durée approximative des boucles en millisecondes : minimum = 0ms, maximum = 0ms, moyenne = 0ms E:\>arp -a Interface : 192.168.0.10 on Interface 0x1000003 Adresse Internet Adresse physique Type 192.168.0.250 00-20-18-61-90-e3 dynamique Et, bien entendu, mon "sniffeur" embusqué sur gw1 n'a rien perdu de l'échange: * gw1 est enregistré sous gateway1.maison.mrs (gw1.maison.mrs est un alias) * pchris est enregistré sous pchris.maison.mrs No. Source Destination Protocol Info 1 pchris.maison.mrs ff:ff:ff:ff:ff:ff ARP Who has 192.168.0.250? Tell 192.168.0.10 2 gateway1.maison.mrs pchris.maison.mrs ARP 192.168.0.250 is at 00:20:18:61:90:e3 3 pchris.maison.mrs gateway1.maison.mrs ICMP Echo (ping) request 4 gateway1.maison.mrs pchris.maison.mrs ICMP Echo (ping) reply 5 pchris.maison.mrs gateway1.maison.mrs ICMP Echo (ping) request 6 gateway1.maison.mrs pchris.maison.mrs ICMP Echo (ping) reply 7 pchris.maison.mrs gateway1.maison.mrs ICMP Echo (ping) request 8 gateway1.maison.mrs pchris.maison.mrs ICMP Echo (ping) reply 9 pchris.maison.mrs gateway1.maison.mrs ICMP Echo (ping) request 10 gateway1.maison.mrs pchris.maison.mrs ICMP Echo (ping) reply 11 gateway1.maison.mrs pchris.maison.mrs ARP Who has 192.168.0.10? Tell 192.168.0.250 12 pchris.maison.mrs gateway1.maison.mrs ARP 192.168.0.10 is at 00:20:18:b9:49:37 Remarquez: * Ligne 1 la requête ARP émise en broadcast (ff:ff:ff:ff:ff:ff) par mon poste de travail:\\ Qui a l'adresse 192.168.0.250 (gw1)? Dites-le à 192.168.0.10 (pchris) * Ligne 2 la réponse ARP de gw1 à pchris:\\ 192.168.0.250 est à 00:20:18:61:90:e3 Viennent ensuite les échanges pour la commande ping et enfin (mais ce n'est pas systématique) gw1 qui recherche l'adresse MAC de pchris. Ce n'est pas une bonne idée d'ailleurs, parce qu'il l'a déjà. En effet, si l'on regarde le détail de la trame 1:
Frame 1 (60 on wire, 60 captured) Arrival Time: Feb 15, 2001 16:02:12.2750 Time delta from previous packet: 0.000000 seconds Frame Number: 1 Packet Length: 60 bytes Capture Length: 60 bytes Ethernet II Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) Source: 00:20:18:b9:49:37 (pchris.maison.mrs) Type: ARP (0x0806) Trailer: 20202020202020202020202020202020... Address Resolution Protocol (request) Hardware type: Ethernet (0x0001) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (0x0001) Sender hardware address: 00:20:18:b9:49:37 Sender protocol address: 192.168.0.10 Target hardware address: 00:00:00:00:00:00 Target protocol address: 192.168.0.250On s'aperçoit que l'adresse MAC de pchris est déjà donnée dedans. Et si ça ne suffisait pas, l'information se trouve également dans la trame 2:
Frame 2 (60 on wire, 60 captured) Arrival Time: Feb 15, 2001 16:02:12.2753 Time delta from previous packet: 0.000285 seconds Frame Number: 2 Packet Length: 60 bytes Capture Length: 60 bytes Ethernet II Destination: 00:20:18:b9:49:37 (pchris.maison.mrs) Source: 00:20:18:61:90:e3 (gateway1.maison.mrs) Type: ARP (0x0806) Trailer: 769E8580000000010000000020454E45... Address Resolution Protocol (reply) Hardware type: Ethernet (0x0001) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: reply (0x0002) Sender hardware address: 00:20:18:61:90:e3 Sender protocol address: 192.168.0.250 Target hardware address: 00:20:18:b9:49:37 Target protocol address: 192.168.0.10==== La livraison indirecte ==== Cette fois-ci, le transfert de données doit passer par le routeur, parce que le destinataire est dans un autre réseau logique. Prenons au hasard ftp.oleane.net:(195.25.12.28) E:\>arp -a Aucune entrée ARP trouvée E:\>ping 195.25.12.28 Envoi d'une requête 'ping' sur 195.25.12.28 avec 32 octets de données : Réponse de 195.25.12.28 : octets=32 temps=30 ms TTL=245 Réponse de 195.25.12.28 : octets=32 temps=40 ms TTL=245 Réponse de 195.25.12.28 : octets=32 temps=30 ms TTL=245 Réponse de 195.25.12.28 : octets=32 temps=30 ms TTL=245 Statistiques Ping pour 195.25.12.28: Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%), Durée approximative des boucles en millisecondes : minimum = 30ms, maximum = 40ms, moyenne = 32ms E:\>arp -a Interface : 192.168.0.10 on Interface 0x1000003 Adresse Internet Adresse physique Type 192.168.0.250 00-20-18-61-90-e3 dynamique === Que s'est-il passé ? === No. Source Destination Protocol Info 1 pchris.maison.mrs ff:ff:ff:ff:ff:ff ARP Who has 192.168.0.250? Tell 192.168.0.10 2 gateway1.maison.mrs pchris.maison.mrs ARP 192.168.0.250 is at 00:20:18:61:90:e3 3 pchris.maison.mrs ftp.oleane.net ICMP Echo (ping) request 4 ftp.oleane.net pchris.maison.mrs ICMP Echo (ping) reply 5 pchris.maison.mrs ftp.oleane.net ICMP Echo (ping) request 6 ftp.oleane.net pchris.maison.mrs ICMP Echo (ping) reply 7 pchris.maison.mrs ftp.oleane.net ICMP Echo (ping) request 8 ftp.oleane.net pchris.maison.mrs ICMP Echo (ping) reply 9 pchris.maison.mrs ftp.oleane.net ICMP Echo (ping) request 10 ftp.oleane.net pchris.maison.mrs ICMP Echo (ping) reply La requête ARP a porté sur la passerelle par défaut (gw1) parce que la couche 2 ne sait pas franchir les routeurs, elle ne sait transporter l'information que sur un seul réseau physique. Son travail se borne donc à transporter l'information jusqu'à la passerelle qui remontera la trame jusqu'au niveau 3 (IP) pour la passer ensuite sur un autre réseau. **La table ARP d'un hôte ne peut donc contenir que des adresses MAC d'hôtes ou de passerelles situées sur le même réseau physique.** Un peu plus loin, nous allons essayer de voir comment un paquet voyage en l'espionnant de chaque côté d'une passerelle.