Я (и мой коллега) только что заметили и проверили, что когда машина Linux проверяется, после последней проверки связи она инициирует одноадресная передача Запрос ARP к компьютеру, который инициировал проверку связи ICMP. При проверке связи с машиной Windows машина Windows не выдает в конце запрос ARP.
Кто-нибудь знает, какова цель этого одноадресного запроса ARP и почему он происходит в Linux, а не в Windows?
Трассировка Wireshark (10.20.30.45 - это 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
Обновить: Я только что погуглил одноадресный запрос ARPs, и единственная полезная ссылка, которую я нашел, находится в RFC 4436 который посвящен "Обнаружению сетевых подключений" (с 2006 г.). Этот метод использует одноадресные ARP, чтобы позволить хосту определить, подключен ли он к ранее известной сети. Но я не понимаю, как это применимо к запросу ARP в результате проверки связи. Так что загадка остается ...
Linux отправляет различные одноадресные запросы ARP для обновления своего кеша ARP. Это сделано для предотвращения устаревших (и потенциально вредоносных) записей кэша ARP.
Есть несколько ситуаций, когда одноадресный ARP используется, в основном, для проверки кеша ARP. Если запись устарела, тогда откроется широковещательная передача ARP.
Это обсуждается в RFC1122 2.3.2.1
Я думаю, что это то, что он делает, и почему, мое первое предположение было бы какой-то мерой против спуфинга. Пакеты ARP никогда не маршрутизируются, поэтому я предполагаю, что вы делаете это в своей локальной сети? Эта ситуация происходит постоянно каждый раз, когда вы проверяете связь с хостом, или вы отслеживали только один раз? В этом случае тайм-аут кэша ARP для этого хоста мог быть истек случайно.
Какая ОС работает на хосте, с которого вы отправляете эхо-запрос?
Думаю, это ошибка. Следующая трассировка - от эхо-запроса до адреса, который находится в кэше ARP, но устарел. Я не могу придумать ни одной веской причины одноадресная передача ARP дважды за такое короткое время. Это с 4.14.15, но я видел такое поведение во многих версиях ядра.
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
Просто предположение ... но это может быть «функция» для регистрации MAC-адреса клиента всякий раз, когда машина отвечает на серию ping или определенное количество ping. Это может быть полезная информация для отслеживания спама ping.