Étrange: pourquoi Linux répond au ping avec une requête ARP après la dernière réponse au ping?

12

Moi (et un collègue) je viens de remarquer et de tester que lorsqu'une machine Linux reçoit un ping, après le dernier ping, elle lance une requête ARP unicast vers la machine qui a lancé le ping ICMP. Lors d'un ping vers une machine Windows, la machine Windows n'émet pas de demande ARP à la fin.

Quelqu'un sait-il quel est le but de cette requête ARP unicast, et pourquoi elle se produit sur Linux et non sur Windows?

La trace Wireshark (avec 10.20.30.45 étant une boîte Linux):

No.Time        Source           Destination      Prot  Info
19 10.905277   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
20 10.905339   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
21 11.904141   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
22 11.904173   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
23 12.904104   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
24 12.904137   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
25 13.904078   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
26 13.904111   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
27 15.901799   D-Link_c5:e7:ea  D-Link_33:cb:92  ARP   Who has 10.20.30.14?  Tell 10.20.30.45
28 15.901855   D-Link_33:cb:92  D-Link_c5:e7:ea  ARP   10.20.30.14 is at 00:05:5d:33:cb:92

Mise à jour: je viens de googler un peu plus pour les requêtes ARP unicast , et la seule référence utile que j'ai trouvée se trouve dans la RFC 4436 qui concerne la "Détection de la connexion réseau" (de 2006). Cette technique utilise des ARP unicast pour permettre à un hôte de déterminer s'il est reconnecté à un réseau précédemment connu. Mais je ne vois pas comment cela s'applique à une requête ARP suite à un ping. Donc, le mystère demeure ...

linux kernel ping arp icmp Rabarberski
la source

Réponses:

4

Linux envoie diverses requêtes ARP unicast pour mettre à jour son cache ARP. Il s'agit d'empêcher les entrées de cache ARP périmées (et potentiellement malveillantes).

Il y a quelques situations où ARP unicast est utilisé, essentiellement pour valider le cache ARP. Si l'entrée est périmée, la solution de secours consiste à diffuser ARP.

Ceci est discuté dans RFC1122 2.3.2.1

Je pense que c'est ce qu'il fait, pourquoi, ma première supposition serait une sorte de mesure anti-usurpation. Les paquets ARP ne sont jamais routés, donc je suppose que vous faites cela sur votre LAN local? Cette situation se produit-elle de manière cohérente à chaque fois que vous envoyez une requête ping à l'hôte ou que vous venez de tracer une fois? Dans ce cas, le cache ARP de cet hôte peut avoir expiré par coïncidence.

De quel système d'exploitation s'exécute sur l'hôte à partir duquel vous envoyez une requête ping à la machine?

Philip Reynolds
la source
Merci pour le lien RFC. Je pensais que les délais d'attente étaient le moyen par défaut de se débarrasser des anciennes entrées d'arp et de limiter la taille du cache d'arp. Ce dernier ne semble pas être fait en effectuant des ARP unicast (mais il y a peut-être aussi un délai d'attente). Nous l'avons testé 3 fois sur un réseau local de banc d'essai local (deux fois depuis une machine Linux et une fois depuis une machine WinXP). J'ai également testé cela sur le «vrai» LAN en envoyant une requête ping depuis mon PC (WinXP) vers un VMWare Ubuntu 9.04 fonctionnant sur mon PC. Même résultat, même timing (2 secondes).
Rabarberski
Avez-vous un lien vers la revendication «Linux envoie diverses requêtes ARP unicast ...»?
Rabarberski
Je ne suis pas sûr, mais cela ressemble à une contre-mesure d'usurpation d'arp. Je me demande bien à quel point c'est efficace, je veux dire, les adresses MAC sont utilisées pour commuter les trames Ethernet, en utilisant un message unicast, cela ira directement à la dernière machine avec le mac de destination ...
Hubert Kario
1

Je pense que c'est un bug. La trace suivante provient d'un ping vers une adresse qui se trouve dans le cache ARP mais périmée. Je ne vois aucune bonne raison pour monodiffuser ARP deux fois en si peu de temps. C'est avec 4.14.15 mais j'ai vu le comportement sur de nombreuses versions du noyau.

root@observer:~# tcpdump -nevi eth0 arp
device eth0 entered promiscuous mode
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

13:11:57.362910 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.1 tell 10.1.2.2, length 28
13:11:57.363018 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.1 is-at 42:5f:03:40:00:22, length 28
13:11:57.392890 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.2 tell 10.1.2.1, length 28
13:11:57.393049 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.2 is-at 42:5f:03:40:00:43, length 28
Tony
la source
Il me semble que ce sont les deux côtés qui vérifient la validité de leurs caches ARP; ces deux échanges sont allés dans des directions opposées, et leurs entrées seraient essentiellement du même âge, et donc expirent et sont vérifiées en même temps.
stolenmoment
-1

Juste une supposition .. mais cela pourrait être une «fonctionnalité» pour enregistrer l'adresse MAC du client chaque fois que la machine répond à une série de ping ou à un certain nombre de pings. Il peut s'agir d'informations utiles pour retrouver le spam ping.

Chris Nava
la source
Mais cette «fonctionnalité» ne nécessiterait pas l'envoi d'une demande ARP, car la machine spammée aurait déjà pu extraire l'adresse MAC de la demande ping ICMP.
Rabarberski