Qu'est-ce que l'ARP ? Table ARP et domaine de diffusion

Imaginez une salle de réunion pleine. Vous avez un nom, mais vous ne savez pas à quel visage il correspond. La seule chose à faire est de demander à voix haute : « Madame Martin est-elle là ? » Quelqu’un lève la main, vous associez le visage au nom et la conversation commence.

Deux appareils sur un réseau font exactement cela. L’adresse IP est le nom ; l’adresse MAC, nécessaire pour poser une trame sur le câble, est le visage. Le protocole qui relie les deux s’appelle ARP, et cet article suit cette question à travers de vraies captures : à quoi elle ressemble sur le câble, comment la réponse est mémorisée, et ce qui déraille quand personne ne vérifie qui répond.

L’ARP est la raison pour laquelle une frontière de VLAN compte en pratique. L’article sur les VLAN renvoyait sans cesse à la table ARP comme premier point de contrôle ; celui-ci explique pourquoi. Les deux font partie du guide de la segmentation réseau.

Chaque sortie ci-dessous a été capturée sur de vraies machines de laboratoire avec tcpdump, rien n’a été reconstitué ; les adresses sont laissées telles que mesurées.

Qu’est-ce que l’ARP ? De l’adresse IP à l’adresse MAC

L’ARP (Address Resolution Protocol) trouve quelle adresse MAC correspond à une adresse IP sur le même réseau local. Un appareil demande au réseau « qui a cette IP ? », et le propriétaire répond « moi, et voici mon adresse matérielle ». C’est tout.

Ce qui frappe, c’est la discrétion de l’ARP. Pas d’écran de réglages, aucun journal, aucun tableau de bord. Un réseau peut tourner des années sans que personne ne le remarque, jusqu’au jour où deux appareils ne se trouvent plus.

Pourquoi deux adresses ? Le partage des rôles entre MAC et IP

Il y a deux adresses parce qu’elles répondent à deux questions : l’adresse MAC dit qui est sur ce câble, l’adresse IP où, dans le monde, va ce paquet. L’une est locale et inscrite dans le matériel, l’autre logique et attribuée.

La différence saute aux yeux sur un long trajet : quand un paquet traverse des continents, son adresse IP ne change jamais, son adresse MAC est réécrite à chaque routeur. Une adresse MAC ne vaut que jusqu’à la prochaine étape.

Avec seulement des adresses MAC, le routage s’effondrerait. Les adresses MAC n’ont aucune géographie : deux ordinateurs côte à côte ont des adresses sans rapport, attribuées selon le fabricant et l’ordre de production. Impossible de les regrouper. Un routeur résume aujourd’hui des millions d’adresses en une ligne ; avec des MAC, il devrait connaître chaque carte réseau de la planète.

Avec seulement des adresses IP, aucun appareil ne pourrait démarrer. Une machine qui vient d’allumer n’a pas d’adresse IP ; elle la demande au réseau. Mais demander, c’est envoyer, et envoyer exige une adresse. Le cercle est rompu par l’adresse MAC : inscrite en usine, sans configuration, présente avant que la machine ne sache quoi que ce soit. DHCP repose là-dessus : le serveur reconnaît la machine sans adresse à sa MAC et y attache le bail.

La preuve figure dans la capture qui suit, et elle passe facilement inaperçue : la ligne ARP indique ethertype ARP (0x0806), pas IPv4 (0x0800). Il n’y a aucun en-tête IP dans cette trame. L’ARP fonctionne à côté d’IP, pas au-dessus ; il ne pourrait en être autrement, puisque son rôle est de trouver quelque chose qu’IP ignore encore.

Comment fonctionne l’ARP : une requête, une réponse

L’ARP, c’est une question et une réponse : la requête who-has part en diffusion, la réponse is-at revient uniquement au demandeur. Ces deux mots figurent tels quels dans une capture.

Le montage : sur ntp01 (192.168.1.15), j’ai supprimé l’entrée en cache de ldap01 (192.168.1.25), envoyé un seul ping et capturé en même temps.

sudo ip neigh flush dev ens33
ping -c 1 192.168.1.25

Regardez l’adresse MAC de destination en début de ligne, le sens de la question et de la réponse, et les écarts d’horodatage :

20:29:59.271996 00:0c:29:a0:71:9a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806): Request who-has 192.168.1.25 tell 192.168.1.15
20:29:59.272559 00:0c:29:7c:79:af > 00:0c:29:a0:71:9a, ethertype ARP (0x0806): Reply 192.168.1.25 is-at 00:0c:29:7c:79:af
20:29:59.272572 00:0c:29:a0:71:9a > 00:0c:29:7c:79:af, ethertype IPv4 (0x0800): 192.168.1.15 > 192.168.1.25: ICMP echo request
20:29:59.273029 00:0c:29:7c:79:af > 00:0c:29:a0:71:9a, ethertype IPv4 (0x0800): 192.168.1.25 > 192.168.1.15: ICMP echo reply

Le mot le plus souvent mal lu est tell : ce n’est pas un ordre, il nomme l’expéditeur. La première ligne dit exactement : « Qui a 192.168.1.25 ? C’est 192.168.1.15 qui demande. » La deuxième répond : « 192.168.1.25 est à 00:0c:29:7c:79:af. »

1. La destination de la première ligne est ff:ff:ff:ff:ff:ff, c’est-à-dire « tout le monde ». La question va à tous les appareils du domaine de diffusion.
2. La destination de la deuxième est 00:0c:29:a0:71:9a. La réponse n’est pas diffusée ; elle revient directement au demandeur.
3. 563 µs séparent les lignes un et deux. Le ping n’est même pas encore parti.
4. Le paquet ICMP de la ligne trois va à la MAC tout juste apprise. D’abord le visage, ensuite la conversation.

Cinq secondes plus tard, la même capture montrait un autre échange :

20:30:04.627661 00:0c:29:7c:79:af > 00:0c:29:a0:71:9a: Request who-has 192.168.1.15 tell 192.168.1.25
20:30:04.627682 00:0c:29:a0:71:9a > 00:0c:29:7c:79:af: Reply 192.168.1.15 is-at 00:0c:29:a0:71:9a

Cette fois, c’est l’autre côté qui demande, mais pas comme on le croit d’abord. La destination n’est pas ff:ff:ff:ff:ff:ff, mais directement 00:0c:29:a0:71:9a. ldap01 connaissait déjà la MAC de ntp01, car une requête ARP ne fait pas que demander : elle porte aussi le couple d’adresses du demandeur. Toute machine qui la reçoit peut l’enregistrer, et ldap01 l’a fait : il a répondu au ping de la première capture en 457 µs, sans rien demander.

Alors, que vaut l’échange cinq secondes plus tard ? Ce n’est pas un apprentissage, c’est une vérification. Un système ne fait pas entièrement confiance à une entrée entendue au passage ; la première fois qu’il en dépend vraiment, il vérifie une fois que l’autre est toujours là. Sous Linux, ce délai s’appelle delay_first_probe_time et valait 5 secondes sur ntp01 ; l’écart entre les deux échanges était de 5,36 secondes. La vérification elle-même est rapide : 21 µs entre question et réponse.

Deux règles en découlent. L’ARP résout dans un sens, mais l’information circule dans les deux : la question part d’un côté, le couple d’adresses s’installe des deux. Et, plus utile sur le terrain : si l’autre côté ne vous connaît pas, la raison est rarement « il n’a jamais demandé », mais « votre question ne l’a jamais atteint ».

Le cache ARP et ses états

La résolution a pris une demi-milliseconde. Bon marché, jusqu’à ce qu’on l’imagine pour chaque paquet : chaque question est une diffusion, et une diffusion interrompt toute la salle. La machine garde donc ce qu’elle apprend dans le cache ARP. Sous Linux, deux commandes le lisent : arp -a est l’ancienne, ip neigh show sa remplaçante moderne.

arp -a

? (192.168.1.25) at 00:0c:29:7c:79:af [ether] on ens33
? (192.168.1.1) at 60:d8:a4:a7:2e:99 [ether] on ens33
? (192.168.1.10) at <incomplete> on ens33
? (192.168.1.115) at ec:75:0c:9f:45:ea [ether] on ens33

ip neigh show

192.168.1.25 dev ens33 lladdr 00:0c:29:7c:79:af REACHABLE
192.168.1.1 dev ens33 lladdr 60:d8:a4:a7:2e:99 STALE
192.168.1.10 dev ens33 INCOMPLETE
192.168.1.115 dev ens33 lladdr ec:75:0c:9f:45:ea REACHABLE
fe80::1 dev ens33 lladdr 60:d8:a4:a7:2e:99 router STALE

Deux différences, utiles toutes deux : chaque ligne porte désormais un état, et il y a une ligne de plus, fe80::1, un voisin IPv6 que l’ancienne commande ne montre jamais. arp vient du vieux paquet net-tools, ignore les états et ne connaît qu’IPv4 ; utilisez ip neigh. Sous Windows, arp -a affiche dynamic/static, Get-NetNeighbor affiche les états.

Le cycle normal : une entrée REACHABLE devient STALE après environ 30 secondes, passe en DELAY au besoin, est confirmée et redevient REACHABLE. FAILED est la seule impasse, et on n’y arrive que par une question restée sans réponse.

L’état le plus mal compris est STALE. Une entrée STALE n’est pas cassée ; la machine dit simplement qu’elle ne l’a pas rafraîchie depuis un moment. Dès que du trafic circule, elle est confirmée en silence. Le routeur (192.168.1.1) ci-dessus est exactement dans cet état, et rien ne va mal.

Un second instantané de la même machine, pris quelques minutes plus tôt, montre aussi le dernier état de la table :

192.168.1.1 dev ens33 lladdr 60:d8:a4:a7:2e:99 STALE
192.168.1.20 dev ens33 FAILED
192.168.1.10 dev ens33 FAILED
192.168.1.115 dev ens33 lladdr ec:75:0c:9f:45:ea REACHABLE
fe80::1 dev ens33 lladdr 60:d8:a4:a7:2e:99 router STALE

La différence entre INCOMPLETE et FAILED fait gagner du temps : INCOMPLETE signifie que la machine demande encore ; FAILED, qu’elle a arrêté. L’un signale une panne en cours, l’autre une panne passée. Quand vous voyez FAILED, la tentative est terminée depuis longtemps et l’entrée reste là jusqu’au prochain trafic.

Laboratoire : trois machines, trois silences différents

Le cache prend toute sa valeur pendant une panne. L’une des hypothèses les plus répandues : « je pingue, pas de réponse, donc l’appareil est éteint ». Souvent fausse, et j’ai mesuré pourquoi. Trois machines du même réseau, toutes trois muettes, mais pas pour la même raison.

Machine un, 192.168.1.25 : la référence saine. Le ping répond, l’entrée est REACHABLE.

Machine deux, 192.168.1.10 : un serveur éteint.

PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
From 192.168.1.15 icmp_seq=1 Destination Host Unreachable
From 192.168.1.15 icmp_seq=2 Destination Host Unreachable

2 packets transmitted, 0 received, +2 errors, 100% packet loss

20:27:11.143707 00:0c:29:a0:71:9a > ff:ff:ff:ff:ff:ff: Request who-has 192.168.1.10 tell 192.168.1.15
20:27:12.167705 00:0c:29:a0:71:9a > ff:ff:ff:ff:ff:ff: Request who-has 192.168.1.10 tell 192.168.1.15

1. Destination Host Unreachable vient de 192.168.1.15, la machine qui pingue. Aucun routeur ne signale rien ; c’est votre propre noyau qui dit « je ne peux pas poser ce paquet sur le câble, je n’ai pas trouvé la MAC de la destination ». Le prendre pour un message de routeur envoie la recherche au mauvais endroit dès le départ.
2. La question diffusée reste sans réponse et se répète chaque seconde. Dans le cache : INCOMPLETE, puis FAILED.

Machine trois, 192.168.1.115 : et là, l’attente s’effondre. Le résultat du ping est presque identique :

PING 192.168.1.115 (192.168.1.115) 56(84) bytes of data.

3 packets transmitted, 0 received, 100% packet loss

Mais la capture montre tout autre chose :

20:28:43.518120 00:0c:29:a0:71:9a > ec:75:0c:9f:45:ea, ethertype IPv4: 192.168.1.15 > 192.168.1.115: ICMP echo request
20:28:44.519826 00:0c:29:a0:71:9a > ec:75:0c:9f:45:ea, ethertype IPv4: 192.168.1.15 > 192.168.1.115: ICMP echo request

192.168.1.115 dev ens33 lladdr ec:75:0c:9f:45:ea REACHABLE

Les paquets ICMP partent vers la bonne MAC, vers une seule destination. L’ARP a fonctionné. Ce qui reste sans réponse n’est pas l’ARP mais le ping : le pare-feu de cette machine jette l’ICMP.

La colonne du milieu est la thèse de cet article : le ping peut se taire, l’ARP non. Le ping dépend d’une application, d’une politique et d’une règle de pare-feu ; l’ARP est obligatoire pour qu’une trame atteigne le câble. D’où l’inversion de l’ordre habituel : quand « le ping ne marche pas », regardez d’abord ip neigh, pas les couches supérieures.

Une question, deux réponses : Linux répond pour des adresses qui ne sont pas là

Ce constat ne figure pas dans l’original turc, et il est né d’une mesure qui avait d’abord mal tourné.

Pour tester ce qui se passe quand une adresse IP change de MAC, j’ai donné à ntp01 une seconde interface virtuelle avec sa propre MAC, et placé dessus l’adresse de test 192.168.1.99. Le premier essai semblait parfait : l’adresse a changé de MAC, l’observateur a perdu zéro paquet. Trop parfait. La capture d’une seule question l’a expliqué :

ARP, Request who-has 192.168.1.99 tell 192.168.1.115
ARP, Reply 192.168.1.99 is-at 00:0c:29:a0:71:9a
ARP, Reply 192.168.1.99 is-at d6:76:8d:f7:d1:fb

Une question, deux réponses, de deux adresses MAC différentes de la même machine. La seconde venait de l’interface qui portait réellement 192.168.1.99. La première venait de ens33, l’interface principale, qui ne portait pas du tout cette adresse.

C’est le comportement par défaut de Linux, le modèle weak host : une adresse IP appartient à la machine, pas à une interface, donc le noyau répond à l’ARP pour chacune de ses adresses sur toute interface qui entend la question. Le réglage en cause est arp_ignore, par défaut 0 : « répondre pour toute adresse locale ». Le résultat sans perte était un artefact ; l’observateur atteignait toujours la machine par la réponse qu’il croyait. Avec arp_ignore=1 (ne répondre que si l’adresse est configurée sur l’interface qui reçoit la requête), la double réponse a disparu, et seulement alors la mesure a pris un sens. Le premier essai a été écarté.

Pourquoi cela compte hors du laboratoire :

• Deux réponses ne signifient pas forcément une attaque. Un serveur Linux à deux interfaces sur le même segment peut répondre deux fois à la même question, et les outils de la section sur le spoofing le signaleraient comme suspect. Vérifiez arp_ignore avant d’escalader.
• Le trafic peut arriver par la « mauvaise » interface. La dernière réponse crue par un voisin décide du câble emprunté par son trafic.
• Votre test peut mentir. Mesurer un basculement sous Linux avec les réglages par défaut, c’est risquer qu’une seconde interface continue de répondre et masque la coupure même que vous cherchez à mesurer.

Qui se souvient combien de temps ? Trois compteurs sur un même chemin

Le chiffre le plus répété sur le terrain est cinq minutes. Il est juste, mais souvent attribué à la mauvaise table. Sur le chemin d’une trame, il y a trois compteurs distincts, sur trois équipements, avec trois durées :

La première ligne s’appelle base_reachable_time_ms sous Linux et BaseReachableTime sous Windows ; j’ai mesuré 30000 sur les deux. Les deux autres viennent du switch du laboratoire :

console#show mac address-table

Aging time is 300 Sec

Vlan     Mac Address           Type        Port
-------- --------------------- ----------- ---------------------
1        F48E.381B.184D        Management  Vl1
5        5811.22B1.0E54        Dynamic     Gi1/0/1
5        F48E.381B.184D        Management  Vl5

Total MAC Addresses in use: 3

console#show arp

Age Time (seconds)............................. 1200
Response Time (seconds)........................ 1
Retries........................................ 4
Cache Size..................................... 1000
Dynamic Renew Mode ............................ Enable
Total Entry Count Current / Peak .............. 2 / 2

IP Address       MAC Address        Interface       Type      Age
---------------  -----------------  --------------  --------  -----------
192.168.1.2      F48E.381B.184D     Vl5             Local         n/a
192.168.1.224    5811.22B1.0E54     Vl5             Dynamic    0h  0m  0s

La deuxième table distingue un switch d’un hub : le switch apprend quelle MAC se trouve derrière quel port en lisant l’adresse source des trames qui passent, et n’envoie chaque trame que par ce port. Personne n’a écrit la ligne Dynamic ci-dessus. (On l’appelle aussi table CAM.)

Ces chiffres sont des minimums, pas des échéances. Après la disparition complète d’une adresse, son entrée dans la table MAC était encore là à la 373e seconde et avait disparu à la 439e, malgré les 300 configurées. Les switchs parcourent la table périodiquement et ne suppriment une entrée qu’après un parcours complet sans usage ; la suppression réelle tombe entre une et deux fois la valeur configurée.

Laboratoire : même IP, nouvel appareil. Qui s’en aperçoit, et quand ?

Ces compteurs font mal dans un cas courant : un appareil tombe en panne, vous installez un remplaçant et lui donnez la même adresse IP. L’adresse ne change pas, le matériel derrière si. Tous ceux qui s’en souviennent détiennent maintenant une entrée fausse, et personne ne les a prévenus. J’ai reproduit exactement cela : 192.168.1.99 fixe, MAC remplacée, l’ancienne complètement retirée, sans annonce du nouvel appareil. Puis j’ai observé deux équipements qui cherchaient cette adresse.

Le poste de travail s’est rétabli en cinq secondes environ :

17:24:13  OK     D6-76-8D-F7-D1-FB  Probe
17:24:18  KAYIP  D6-76-8D-F7-D1-FB  Unreachable
17:24:23  OK     52-57-6E-C6-D0-81  Reachable

(KAYIP signifie « perdu » en turc ; le script de surveillance était écrit en turc.) L’entrée est passée en Probe, puis Unreachable ; la machine a rediffusé la question, appris la bonne MAC et continué. Perte : un paquet.

Le switch a mis vingt et une minutes. Six minutes après l’échange :

console#ping 192.168.1.99
 Pinging 192.168.1.99 with 0 bytes of data:

----192.168.1.99 PING statistics----
4 packets transmitted, 0 packets received, 100% packet loss

console#show arp
IP Address       MAC Address        Interface       Type      Age
---------------  -----------------  --------------  --------  -----------
192.168.1.99     1A4A.ED68.B905     Vl5             Dynamic    0h  6m 15s

L’entrée est tombée exactement à l’expiration de Age Time, pas une seconde avant. Pendant quatre relevés sans réponse, le switch n’a jamais redemandé ; Dynamic Renew Mode était actif et n’y a rien changé, car il résout à nouveau à l’expiration du compteur, pas quand les réponses cessent. Traduction sur le terrain : quand vous déplacez une caméra ou un point d’accès vers une nouvelle adresse, votre portable le joint aussitôt, un autre équipement du réseau peut ne pas le trouver pendant vingt minutes. Pensez-y la prochaine fois qu’on vous dira « chez moi, ça marche ».

Le domaine de diffusion : où s’arrête le mur de l’ARP

Tout ce qui précède dépend d’une condition : être dans le même domaine de diffusion. Si la requête ARP ne peut atteindre la cible, aucune MAC n’est apprise et aucune trame n’est construite. Un domaine de diffusion est la zone la plus large qu’une diffusion peut atteindre, et donc la portée exacte de l’ARP. Dans la plupart des réseaux d’entreprise, le mur n’est pas un câble mais une étiquette sur les trames : c’est le sujet de l’article sur les VLAN.

Pour en mesurer la réalité, j’ai écouté l’ARP sur ntp01 pendant 30 secondes sans rien faire :

sudo tcpdump -i ens33 -n "arp"

20:25:30.133858 ARP, Request who-has 192.168.1.158 tell 192.168.1.115
20:25:38.766755 ARP, Request who-has 192.168.1.15 tell 192.168.1.1
20:25:38.869127 ARP, Request who-has 192.168.1.25 tell 192.168.1.1
20:25:38.971489 ARP, Request who-has 192.168.1.30 tell 192.168.1.1

Rien de tout cela ne vient de moi. Nous entendons tout parce que nous sommes dans la même salle. Un domaine de diffusion n’est pas une abstraction ; c’est le bruit qu’on entend quand on écoute.

Laboratoire : deux appareils « sur le même réseau », deux domaines de diffusion

Ici vient une objection légitime : si le switch a l’adresse 192.168.1.2/24, il est sur le même réseau ; comment peut-il être injoignable ? Les cinq adresses en jeu étaient toutes dans 192.168.1.0/24 :

Sous Windows, cette commande montre la table des voisins avec l’interface sur laquelle chaque entrée a été résolue :

Get-NetNeighbor -IPAddress 192.168.1.2, 192.168.1.1

InterfaceAlias IPAddress   LinkLayerAddress        State
-------------- ---------   ----------------        -----
Wi-Fi          192.168.1.2 00-00-00-00-00-00 Unreachable
Wi-Fi          192.168.1.1 60-D8-A4-A7-2E-99   Reachable
Ethernet       192.168.1.2 F4-8E-38-1B-18-4D   Reachable
Ethernet       192.168.1.1 00-00-00-00-00-00  Incomplete

00-00-00-00-00-00 n’est pas une adresse MAC, c’est une case vide. Les réponses se croisent : le routeur ne répond que côté Wi-Fi, le switch que côté câble. Deux adresses à un chiffre d’écart, même masque, deux câbles différents. Depuis le poste, les deux pings passent, parce qu’il a un pied dans chaque domaine. Sur ntp01, une seule interface :

sudo ip neigh flush dev ens33
ssh ilker@192.168.1.2

ssh: connect to host 192.168.1.2 port 22: No route to host

Puis la table des voisins :

ip neigh show dev ens33

192.168.1.1    lladdr 60:d8:a4:a7:2e:99 REACHABLE
192.168.1.115  lladdr ec:75:0c:9f:45:ea REACHABLE
192.168.1.2                             FAILED
192.168.1.224                           INCOMPLETE

Quatre adresses, toutes les quatre dans le même /24, deux trouvées, deux non. Le routeur et l’interface sans fil du poste sont REACHABLE ; le switch est FAILED, l’interface Ethernet du poste INCOMPLETE. Les deux adresses introuvables n’ont qu’un point commun : elles sont à l’autre bout du câble.

Voilà la réponse à l’objection. ntp01 considère 192.168.1.2 comme son propre réseau d’après son masque ; il ne confie donc pas le paquet au routeur, il fait une requête ARP directe et attend. Rien ne vient. Si le switch avait été dans un autre bloc, par exemple 192.168.99.2, ntp01 aurait remis le paquet à la passerelle. Être « sur le même réseau » n’est pas ici une garantie, c’est la cause de la panne. Le masque dit « voisin », le câble dit « non », et l’ARP croit le câble.

La table a encore une ligne, et elle porte à elle seule la thèse de cet article. Depuis la même machine, j’ai envoyé un ping à l’adresse sans fil du poste :

ping -c 2 192.168.1.115

2 packets transmitted, 0 received, 100% packet loss, time 1031ms

Le ping reste totalement muet, pourtant l’entrée voisine de la même adresse est REACHABLE, avec la bonne adresse MAC. L’appareil est là ; le pare-feu Windows rejette l’ICMP en silence : le paquet est jeté et pas même un message d’erreur ne revient. Le ping peut se taire, l’ARP non. Dans cette table, les deux se côtoient.

Topologie : la facture cachée de l’ARP

Un routeur termine un domaine de diffusion ; un switch, par défaut, l’étend. Pour tracer la limite sur un switch, l’outil est le VLAN. La portée de l’ARP n’est donc pas fixée par le protocole, mais par vous, par le câblage et le choix du matériel.

Des switchs en cascade. L’une des topologies les plus pénibles de ma carrière : des switchs branchés à la suite, chaque nouveau besoin raccordé au port libre du précédent, jusqu’à dégrader les performances de tout le site. Une telle chaîne accumule trois coûts : la bande passante (le trafic du dernier switch traverse chaque liaison montante), un seul domaine de diffusion (chaque who-has traverse tous les switchs et atteint chaque carte), et la pression dans les switchs (chacun doit apprendre toutes les adresses ; quand la table MAC est pleine, il inonde tous ses ports pour les destinations inconnues et se comporte comme un hub pour ces trames).

Pourquoi un switch non administrable rend l’ARP aveugle. Un switch non administrable n’est pas « idiot » : il a une table MAC et commute correctement. Il lui manque seulement la capacité de vous répondre. La table ARP dit quelle MAC a répondu ; quel câble y correspond, c’est la table du switch qui le dit. Sans elle, vous avez une MAC et aucune idée d’où elle se trouve dans le bâtiment. Vous pouvez pourtant le trouver, par le switch administrable au-dessus : un port voit normalement une adresse MAC ; s’il en montre plusieurs, quelque chose derrière multiplie les trames.

Vlan     Mac Address           Type        Port
-------- --------------------- ----------- ---------------------
5        000C.29A0.719A        Dynamic     Gi1/0/2
5        5811.22B1.0E54        Dynamic     Gi1/0/2
5        EEA7.58A3.9726        Dynamic     Gi1/0/2

Trois adresses sur un port ; ici un poste qui faisait tourner des VM, mais la signature est la même, et les candidats sont peu nombreux : un switch non administrable sous un bureau, un hôte de virtualisation, un téléphone IP avec port PC ou un point d’accès.

L’ARP gratuit : parler sans qu’on vous demande

Jusqu’ici, chaque réponse ARP répondait à une question. Le protocole permet aussi de parler sans question : l’ARP gratuit (gratuitous ARP). Un appareil annonce lui-même son adresse. Cela sert à détecter les conflits d’adresses au démarrage, à rafraîchir les caches des autres et au basculement, quand une adresse virtuelle change de machine dans un système redondant.

Le basculement paraît propre sur le papier. Mesuré, beaucoup moins. L’annonce est bien partie :

ARP, Request who-has 192.168.1.99 tell 192.168.1.99

Source et cible identiques : la signature d’un ARP gratuit. Mais le poste du même réseau l’a ignorée. L’ancienne MAC est restée 19 secondes de plus dans son cache, et n’a changé qu’après la propre vérification de la machine. Ce n’est pas un défaut, c’est une défense : remplacer une entrée valide sur la foi d’une annonce non sollicitée reviendrait à offrir l’ARP spoofing à n’importe qui. Les systèmes traitent l’annonce comme un indice, pas comme un ordre.

Deux décisions distinctes se cachent ici, et sur le terrain on les confond sans cesse. Ce qui se passe quand une annonce arrive pour une adresse sans aucune entrée est une question ; sous Linux, c’est arp_accept qui en décide, et par défaut aucune entrée n’est créée. Savoir si une entrée existante est écrasée par une annonce est une autre question, et c’est ce qui a été mesuré plus haut : l’entrée existait, l’annonce est arrivée, l’entrée n’a pas changé. Le poste a attendu sa propre vérification, pas l’annonce. Conséquence pratique : modifier arp_accept ne raccourcit pas ces 19 secondes, car elles dépendent du compteur de vérification de la machine, pas de ce réglage.

Côté émetteur aussi, une surprise absente de l’original turc. Linux a un réglage censé envoyer ces annonces : arp_notify. Activé, j’ai ajouté une adresse secondaire à une interface active et compté les ARP gratuits sur le câble : zéro. Le réglage agit quand une interface monte, pas quand on ajoute une adresse à une interface déjà active. Si votre conception de basculement compte sur arp_notify pour annoncer une adresse flottante sur une interface active, vérifiez-le par une capture ; le nom promet plus que le réglage ne tient.

En pratique : l’émetteur doit annoncer, et il faut vérifier sur le câble qu’il le fait ; côté récepteurs, ne supposez pas que l’annonce a fonctionné. C’est souvent pourquoi le basculement d’un pare-feu ou d’un répartiteur de charge redondant prend des minutes au lieu de secondes : l’annonce n’a pas été bloquée, elle n’a pas été écoutée.

ARP spoofing : le prix d’un protocole qui ne demande jamais de pièce d’identité

L’ARP gratuit soulève une question : un appareil peut annoncer son adresse sans qu’on le lui demande, et les autres le croient. Comment savent-ils que c’est vrai ? Ils ne le savent pas. L’ARP n’a aucune authentification.

Les attaquants n’aiment pas l’ARP ; ils aiment qu’on ne puisse pas le désactiver. Le couper, c’est arrêter le réseau. Il répond toujours, même quand un pare-feu jette l’ICMP. Il n’attend pas qu’on lui pose une question. Et il ne laisse aucune trace. Le revers de la médaille, d’où vient la défense : tout cela ne vaut que si l’attaquant est déjà dans le domaine de diffusion. L’ARP ne traverse pas les routeurs. La segmentation n’empêche pas le premier pas, mais elle réduit la salle à laquelle il donne accès.

Là, la métaphore se brise : dans une vraie salle, personne ne peut lever la main à la place d’un autre, car on se reconnaît. L’ARP n’a pas de reconnaissance faciale. L’ARP spoofing consiste pour un attaquant à répondre à la place de l’adresse IP d’un autre pour faire passer son trafic par sa propre machine : il dit à la victime « la MAC de la passerelle, c’est moi », à la passerelle « la MAC de la victime, c’est moi », et les deux mettent leurs tables à jour. Les paquets continuent d’arriver, donc chacun voit un fonctionnement normal. C’est le moyen le moins cher de se placer en homme du milieu.

La Dynamic ARP Inspection vient en premier, parce qu’elle place la défense dans le réseau. Mais ne l’imposez pas d’emblée : marquez les ports de confiance, faites-la tourner en surveillance, lisez les journaux, puis imposez. Et, comme mesuré plus haut, un hôte Linux à deux interfaces peut ressembler exactement à ce que la DAI doit attraper ; connaissez vos hôtes multi-interfaces avant. Aucune de ces mesures ne rend l’ARP sûr ; la vraie défense est que le trafic intercepté soit illisible : des protocoles chiffrés.

Diagnostiquer avec l’ARP : quelle sortie dit quoi

Tout se résume à une habitude : devant un problème de connectivité, lisez ip neigh avant de pinguer.

La dernière ligne est là exprès. Beaucoup vident la table parce qu’ils ont vu STALE et croient avoir réparé quelque chose. Vider ne fait pas de mal, mais ne répare rien.

Toute cette table regarde l’entrée ARP. Il reste un symptôme, et il n’y apparaît jamais : plusieurs adresses MAC sur un même port de switch. ip neigh ne connaît pas les ports, vous ne le verrez donc pas là ; il n’apparaît que dans la table du switch lui-même et signale qu’un appareil multiplie les trames derrière ce port. Ce que cela signifie et comment le cerner est traité dans la section sur le switch non administrable, plus haut.

Si vous devez vider : sous Windows (droits d’administrateur requis ; sans eux, la machine du labo, sous Windows en turc, a répondu Erişim engellendi, c’est-à-dire « Accès refusé » ; l’équivalent PowerShell Remove-NetNeighbor exige les mêmes droits) arp -d * ou arp -d 192.168.1.25, sous Linux :

sudo ip neigh flush dev ens33
sudo ip neigh del 192.168.1.25 dev ens33

Dans la mesure, une entrée supprimée était reconstruite en une demi-milliseconde. Le seul cas risqué est une entrée statique erronée : elle survit à la suppression, et c’est justement sa signature. Windows affiche static au lieu de dynamic ou Permanent, et sous Linux la ligne se termine par PERMANENT et résiste à flush. Les commandes qui en créent une à la main tiennent aussi en une ligne : arp -s sous Windows, ip neigh ... nud permanent sous Linux. Une entrée statique sert à figer une association le temps d’un diagnostic, jamais comme solution durable ; laissée en place, elle devient la panne dont personne ne se rappelle la raison six mois plus tard.

Conclusion : ce que dit le protocole le plus discret

L’ARP est le protocole le plus discret de votre réseau. Pas de réglages, pas de journal, personne ne le voit travailler. Mais quand il tombe, ou quand on lui ment, il emporte toutes les couches au-dessus.

Quatre résultats mesurés serviront sur le terrain :

• Le ping peut se taire, l’ARP non. Un ping sans réponse ne prouve pas qu’un appareil est éteint ; une ligne de ip neigh dit ce qu’il en est.
• Le même bloc d’adresses n’est pas le même domaine de diffusion. Deux appareils peuvent partager un /24 sans jamais s’entendre.
• L’ARP ne demande jamais de pièce d’identité. Il croit les réponses, et c’est une conception, pas un bogue. La défense est dans le switch et dans le chiffrement.
• Par défaut, Linux répond pour ses adresses sur toutes ses interfaces. Une question peut recevoir deux réponses, ce qui peut masquer une coupure en test ou ressembler à une attaque en production.

L’ARP n’est pas méconnu ; on ne le regarde simplement pas. Mais le jour de la panne, un seul mot dans la sortie de ip neigh place un problème qu’on aurait sinon cherché des jours dans la mauvaise couche.