Protocole ARP : comment les adresses IP trouvent leur MAC sur un réseau local

Le protocole ARP, c’est un peu le standardiste discret des réseaux Ethernet. Sans lui, vos machines savent à qui elles veulent parler via une IP, mais elles n’ont aucun moyen de savoir quelle carte réseau physique se cache derrière. Du coup, les trames ne partent jamais. En fait, ARP fait le sale boulot de la résolution dynamique : transformer une adresse logique de couche 3 en adresse matérielle de couche 2. Et ça, sur n’importe quel LAN IPv4 qui se respecte, ça tourne encore tous les jours.

Bon, pourquoi on en parle autant ? Parce que dès qu’on branche deux PC, un switch, des VMs ou des objets connectés, ce mécanisme entre en jeu. Et franchement, la plupart du temps il fait ça sans qu’on s’en rende compte… jusqu’au jour où un problème de connectivité ou une alerte de sécurité pointe le nez.

Pourquoi l’IP seule ne suffit pas

Sur un réseau Ethernet classique, chaque paquet doit être encapsulé dans une trame qui contient obligatoirement une adresse MAC source et une adresse MAC destination. L’IP, elle, sert à router entre réseaux. Mais à l’intérieur d’un même segment de diffusion, c’est la MAC qui permet au switch de livrer la trame au bon port.

Le truc, c’est qu’aucun protocole de couche supérieure ne fournit cette information de base. Alors le système d’exploitation met en pause l’envoi, lance une résolution ARP, et attend la réponse avant de construire la trame. Sans ça, impossible d’envoyer un simple ping ou d’établir une session SSH vers une machine voisine.

Comment ça se passe concrètement, étape par étape

Imaginons deux postes sur le même VLAN : PC-A (192.168.10.50) veut envoyer des données à PC-B (192.168.10.75). PC-A regarde d’abord dans sa table ARP locale. Rien ? Il construit alors une requête ARP et la diffuse en broadcast Ethernet (destination FF:FF:FF:FF:FF:FF).

Dans cette requête on trouve :

• l’adresse MAC et l’IP de l’émetteur,
• l’IP cible,
• et un champ MAC cible laissé à zéro.

Tous les équipements du segment reçoivent le message. Seule la machine qui reconnaît son IP répond, et elle le fait en unicast directement à l’émetteur. Elle indique simplement : « C’est moi, voici ma MAC ».

PC-A enregistre la correspondance dans son cache et peut enfin envoyer ses données encapsulées dans une trame Ethernet correcte. La réponse ARP met aussi à jour le cache de PC-B avec l’info de PC-A, histoire que le retour soit direct.

Et après ? Les entrées restent en mémoire un certain temps (quelques minutes généralement, selon l’OS) pour éviter de répéter l’opération à chaque paquet. Quand le timer expire, une nouvelle requête est lancée si besoin.

Ce qu’il y a vraiment dans un paquet ARP

Le format est resté stable depuis la RFC 826. On y trouve successivement :

Le type de matériel (généralement 1 pour Ethernet), le type de protocole (0x0800 pour IPv4), la longueur des adresses physiques et logiques, puis l’opcode qui indique s’il s’agit d’une requête (1) ou d’une réponse (2). Viennent ensuite les quatre blocs d’adresses : MAC et IP de l’émetteur, MAC et IP de la cible (cette dernière étant vide dans la requête).

Tout ça est transporté dans une trame Ethernet dont le champ EtherType vaut 0x0806. Simple, compact, et surtout sans aucune forme d’authentification… ce qui va poser problème plus tard.

La table ARP au quotidien : cache, durée de vie et dépannage

Chaque système maintient sa propre table de correspondances. Sur Windows, un arp -a affiche tout ce qui est connu. Sur Linux, c’est plutôt ip neigh show ou arp -n. Les entrées dynamiques disparaissent après timeout. On peut aussi ajouter des entrées statiques avec arp -s (ou ip neigh add), mais attention : elles survivent rarement aux redémarrages sans scripts.

En cas de galère réseau (plus de ping alors que l’IP répond ailleurs, ou latence bizarre), vider le cache est souvent le premier réflexe : arp -d * sous Windows, ip neigh flush all sous Linux. Ça force une nouvelle résolution et résout pas mal de situations où une vieille entrée pourrie traîne.

Gratuitous ARP et Proxy ARP : les variantes qu’on croise encore

Parfois une machine envoie une requête ARP sans attendre de réponse. C’est le gratuitous ARP. Elle annonce simplement « je suis 192.168.10.75 et ma MAC est xx:xx:xx ». Utile au démarrage pour détecter les conflits d’IP ou forcer les switches à mettre à jour leurs tables CAM. Certains équipements l’utilisent aussi en mode haute disponibilité.

Le Proxy ARP, lui, permet à un routeur de répondre à la place d’un hôte situé sur un autre segment. Moins courant aujourd’hui avec le routage classique, mais ça existe encore dans certaines configurations legacy ou pour simplifier des environnements sans subnetting propre.

Quand l’ARP devient un problème de sécurité

Le gros défaut de conception, c’est l’absence totale de vérification. N’importe qui sur le segment de diffusion peut répondre à une requête ARP… ou envoyer des réponses non sollicitées. Un attaquant peut donc empoisonner les caches des autres machines en associant l’IP d’une passerelle ou d’un serveur à sa propre MAC.

Résultat classique : attaque de l’homme du milieu. Tout le trafic passe par la machine de l’attaquant avant d’être réexpédié. Parfait pour sniffer des identifiants en clair ou injecter du code. Sur un Wi-Fi ouvert, un switch non protégé ou un réseau de test, c’est d’une facilité déconcertante avec des outils comme Ettercap ou des scripts simples.

Comment limiter les dégâts dans la vraie vie

Sur un petit réseau, les entrées statiques pour la passerelle et les serveurs critiques restent une protection basique, même si c’est lourd à maintenir quand les adresses changent souvent.

Dans un environnement un peu plus sérieux, on active les fonctionnalités des switches gérés : Dynamic ARP Inspection (DAI) qui recoupe les réponses ARP avec les baux DHCP ou des listes statiques, et Port Security qui limite le nombre de MAC par port. Segmenter le réseau en VLANs réduit aussi la surface d’attaque : un attaquant reste confiné à son domaine de broadcast.

Surveiller reste utile : des outils comme arpwatch ou des solutions IDS peuvent alerter sur des changements suspects de correspondances. Et évidemment, chiffrer tout ce qui peut l’être (HTTPS, SSH, VPN site-à-site) limite l’intérêt d’une interception même réussie.

ARP et les réseaux d’aujourd’hui

Avec l’IPv6, c’est le Neighbor Discovery Protocol (NDP) qui remplace ARP. Il apporte quelques protections supplémentaires (bien que pas parfaites non plus). Mais la réalité, c’est que la plupart des infrastructures restent en dual-stack. Tant qu’il y aura de l’IPv4 sur les LAN, le protocole ARP continuera de tourner en arrière-plan.

Dans les environnements virtualisés ou cloud, le principe reste le même, même si les hyperviseurs et les SDN ajoutent parfois leurs propres couches de protection. Le fond du problème ne change pas : dès qu’on a un segment de diffusion partagé, il faut faire confiance… ou le sécuriser.

Au bout du compte, ARP est l’un de ces protocoles qu’on oublie parce qu’il « juste marche ». Jusqu’au jour où une VM change de MAC, un switch perd sa table, ou quelqu’un teste un outil d’attaque sur le réseau de dev. Le comprendre en profondeur, c’est déjà avoir une longueur d’avance pour diagnostiquer plus vite et concevoir des réseaux un peu plus solides.