Introduction
Dans ce laboratoire, vous allez explorer l'interaction fondamentale entre la couche réseau (couche 3) et la couche de liaison de données (couche 2) dans un environnement Linux. Vous utiliserez les utilitaires en ligne de commande courants ping et arp pour observer le protocole de résolution d'adresses (ARP - Address Resolution Protocol) en action. L'objectif principal est de comprendre comment votre système résout les adresses IP en adresses MAC physiques pour les périphériques sur le réseau local et comment il gère la communication avec les hôtes distants.
Vous commencerez par inspecter l'état du cache ARP. Ensuite, vous utiliserez ping pour communiquer avec un périphérique local (votre passerelle par défaut) et un périphérique distant (google.com). En observant le cache ARP avant et après ces actions, vous verrez comment votre système utilise les adresses MAC pour la communication locale et s'appuie sur la passerelle par défaut pour le trafic distant.
Afficher le cache ARP initial avec arp -a
Dans cette étape, vous allez inspecter l'état initial du cache du protocole de résolution d'adresses (ARP) de votre système. Le cache ARP est un composant réseau crucial qui stocke les correspondances entre les adresses de couche 3 (IP) et leurs adresses de couche 2 (MAC) correspondantes pour les appareils sur le même réseau local.
Tout d'abord, vérifions l'état actuel du cache ARP à l'aide de la commande arp. L'option -a indique à la commande d'afficher toutes les entrées actuelles.
Dans votre terminal, qui se trouve déjà dans le chemin ~/project, exécutez la commande suivante :
arp -a
Vous verrez probablement une ou plusieurs entrées. Il est courant que la passerelle par défaut soit déjà présente dans le cache. Votre sortie peut ressembler à ceci :
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
Il est important de noter qu'en raison de la nature virtualisée de l'environnement LabEx, il n'est pas toujours possible de vider complètement le cache ARP. Par conséquent, vous verrez probablement un cache pré-rempli dès le départ. Dans une configuration typique non virtualisée, vous verriez plus probablement une entrée vide ou
<incomplete>pour la passerelle avant la première communication.
Cette sortie montre l'état initial de notre cache ARP. Elle sert de référence pour nos prochaines étapes, où nous déclencherons une activité réseau et observerons comment cette table est utilisée.
Ping un appareil local pour déclencher une requête ARP
Dans cette étape, vous utiliserez la commande ping pour initier la communication avec un autre périphérique sur votre réseau local. Cette action utilisera la correspondance du protocole de résolution d'adresses (ARP) si elle est nécessaire. Lorsque votre système tente d'envoyer un paquet à une adresse IP locale, il vérifie d'abord son cache ARP. S'il ne trouve pas d'adresse MAC correspondante, il diffuse une requête ARP. Si l'entrée existe déjà, il utilisera l'adresse MAC mise en cache.
Pour ce faire, nous devons d'abord identifier l'adresse IP d'un périphérique sur le réseau local. La cible la plus fiable dans cet environnement est votre passerelle par défaut (le routeur virtuel). Vous pouvez trouver son adresse IP en inspectant la table de routage.
Dans votre terminal, exécutez la commande suivante pour afficher la table de routage :
ip route show
La sortie vous montrera la route par défaut. Recherchez la ligne qui commence par default via. L'adresse IP qui y est indiquée est votre passerelle.
default via 172.16.50.253 dev eth0 ...
...
D'après l'exemple de sortie ci-dessus, l'adresse IP de la passerelle est 172.16.50.253. Utilisez maintenant cette adresse IP pour envoyer quelques paquets ping. L'option -c 4 indique à ping d'envoyer exactement 4 paquets puis de s'arrêter. Remplacez 172.16.50.253 par l'adresse IP réelle de votre passerelle que vous avez trouvée.
ping -c 4 172.16.50.253
Vous devriez voir une réponse réussie pour chaque paquet, confirmant que votre système a pu communiquer avec la passerelle.
PING 172.16.50.253 (172.16.50.253) 56(84) bytes of data.
64 bytes from 172.16.50.253: icmp_seq=1 ttl=64 time=0.066 ms
64 bytes from 172.16.50.253: icmp_seq=2 ttl=64 time=0.060 ms
64 bytes from 172.16.50.253: icmp_seq=3 ttl=64 time=0.055 ms
64 bytes from 172.16.50.253: icmp_seq=4 ttl=64 time=0.045 ms
--- 172.16.50.253 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3060ms
rtt min/avg/max/mdev = 0.045/0.056/0.066/0.007 ms
Cette simple action a forcé votre système à effectuer une recherche ARP. Dans l'étape suivante, nous inspecterons à nouveau le cache ARP pour voir le résultat.
Vérifier la résolution IP-vers-MAC locale dans le cache ARP
Dans cette étape, vous allez réexaminer le cache ARP pour voir le résultat direct de la commande ping que vous avez exécutée précédemment. Étant donné que votre système a communiqué avec succès avec la passerelle locale, il devait disposer d'une correspondance d'adresses IP vers MAC valide. Voyons si la table a changé.
Inspectons à nouveau le cache ARP. Dans votre terminal, exécutez la même commande que lors de la première étape :
arp -a
Cette fois, la sortie sera différente uniquement si l'entrée n'était pas déjà complète. Dans notre cas, comme l'entrée était déjà résolue à l'étape 1, la sortie sera identique.
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
Comparez cette sortie à celle de l'étape 1. Elle est identique. C'est parce que l'entrée ARP pour la passerelle était déjà complète avant que nous envoyions le ping. Votre système n'a pas eu besoin d'effectuer une nouvelle requête ARP ; il s'est simplement basé sur les informations déjà présentes dans le cache.
Cela démontre un principe clé : le cache ARP évite les requêtes ARP redondantes. Si l'entrée avait été <incomplete> ou manquante, cette commande ping l'aurait remplie, et vous auriez constaté un changement dans la sortie.
Ping un hôte externe pour impliquer la passerelle par défaut
Dans cette étape, vous passerez de la communication avec un périphérique local à la communication avec un hôte sur Internet. Cela démontre un concept fondamental de mise en réseau : comment votre ordinateur utilise sa passerelle par défaut pour atteindre des destinations en dehors de son propre réseau local.
Lorsque l'adresse IP de destination ne se trouve pas sur le même sous-réseau que votre ordinateur, votre système sait qu'il ne peut pas envoyer le paquet directement. Au lieu de cela, il doit envoyer le paquet à sa passerelle par défaut désignée. La passerelle (un routeur) est responsable de la transmission du paquet vers sa destination finale sur Internet.
Pour observer cela en action, vous allez pinger un hôte externe bien connu, google.com.
Dans votre terminal, exécutez la commande suivante :
ping -c 4 google.com
Vous verrez le domaine google.com être résolu en une adresse IP, puis vous recevrez des réponses de cette adresse.
PING google.com (142.250.189.174) 56(84) bytes of data.
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=1 ttl=118 time=4.38 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=2 ttl=118 time=4.40 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=3 ttl=118 time=4.35 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=4 ttl=118 time=4.39 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.353/4.380/4.401/0.017 ms
Même si vous avez communiqué avec succès avec google.com, votre ordinateur n'a pas effectué de requête ARP pour l'adresse IP de Google. Il n'avait besoin que de l'adresse MAC de sa passerelle locale, qu'il avait déjà trouvée lors des étapes précédentes. Dans l'étape suivante, vous analyserez le cache ARP pour confirmer ce comportement.
Analyser le cache ARP pour la communication à distance
Dans cette dernière étape, vous analyserez le cache ARP une dernière fois pour confirmer comment votre système gère la communication avec les hôtes distants. Cela solidifiera la distinction entre la communication sur le réseau local et la communication à distance, et mettra en évidence le rôle de la passerelle par défaut.
Maintenant que vous avez réussi à pinger google.com, vérifions à nouveau le cache ARP. Dans votre terminal, exécutez la commande arp -a :
arp -a
Examinez attentivement la sortie. Elle devrait être identique à l'état du cache des étapes précédentes.
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
Vous remarquerez qu'il n'y a aucune entrée pour google.com ou son adresse IP (par exemple, 142.250.189.174). La seule entrée significative présente est toujours celle de votre passerelle par défaut.
C'est le point essentiel de ce laboratoire. L'ARP fonctionne au niveau de la couche 2 (Layer 2) et est uniquement utilisé pour trouver les adresses MAC sur le segment de réseau local. Lorsque votre ordinateur envoie un paquet à une destination distante, il sait que la destination n'est pas locale, il envoie donc le paquet à l'adresse MAC du prochain saut (next hop) – votre passerelle par défaut. Le routeur prend alors la responsabilité de transmettre le paquet IP vers sa destination finale. Votre ordinateur n'a pas besoin de connaître l'adresse MAC de google.com ; il a seulement besoin de connaître l'adresse MAC du périphérique qui peut lui transmettre le paquet.
Résumé
Dans ce laboratoire, vous avez exploré l'interaction fondamentale entre les couches réseau 3 (IP) et 2 (MAC) en utilisant les commandes ping et arp sous Linux. Vous avez commencé par inspecter l'état du cache du protocole de résolution d'adresses (ARP) avec arp -a, en observant qu'il peut déjà contenir des entrées pour des périphériques critiques tels que la passerelle par défaut. En pingant la passerelle locale, vous avez confirmé que le système utilise ces informations mises en cache pour la communication locale, évitant ainsi les recherches d'adresses redondantes.
De plus, vous avez étudié la différence de communication avec un hôte distant. Lorsque vous avez pingé une adresse IP externe, vous avez observé que le système n'effectue pas de requête ARP pour la destination finale. Au lieu de cela, il envoie le paquet à la passerelle par défaut pour qu'il soit acheminé en dehors du réseau local. L'analyse finale du cache ARP a renforcé ce concept, montrant qu'aucune entrée n'a été ajoutée pour l'hôte distant. La seule entrée pertinente est restée celle de la passerelle par défaut, soulignant son rôle crucial en tant qu'intermédiaire pour tout trafic destiné aux réseaux externes.
