이상한 : 왜 리눅스가 마지막 핑 응답 후 ARP 요청으로 핑에 응답합니까?

나는 (그리고 동료) 리눅스 머신이 핑될 때, 마지막 핑 이후 에 ICMP 핑을 시작한 머신에 대한 유니 캐스트 ARP 요청을 시작한다는 것을 알아 차리고 테스트했다 . Windows 시스템에 핑할 때 Windows 시스템은 마지막에 ARP 요청을 발행하지 않습니다.

아무도이 유니 캐스트 ARP 요청의 목적이 무엇인지, 왜 Windows가 아닌 Linux에서 발생하는지 알고 있습니까?

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

업데이트 : 나는 유니 캐스트 ARP 요청에 대해 더 많이 검색했으며 , 찾은 유일한 유용한 참조는 RFC 4436 에서 "Network Attachment 감지"(2006 년)에 관한 것입니다. 이 기술은 유니 캐스트 ARP를 사용하여 호스트가 이전에 알려진 네트워크에 다시 연결되었는지 확인할 수 있습니다. 그러나 핑을 수행 한 결과 이것이 ARP 요청에 어떻게 적용되는지 알 수 없습니다. 그래서 미스터리는 남아 있습니다 ...

Linux는 다양한 유니 캐스트 ARP 요청을 보내 ARP 캐시를 업데이트합니다. 이는 오래된 (및 잠재적으로 악의적 인) ARP 캐시 항목을 방지하기위한 것입니다.

기본적으로 ARP 캐시를 확인하기 위해 유니 캐스트 ARP가 사용되는 상황이 몇 가지 있습니다. 항목이 오래되면 대체는 ARP를 브로드 캐스트하는 것입니다.

이것은 RFC1122 2.3.2.1 에서 논의됩니다.

나는 그것이 왜 내 첫 번째 추측이 일종의 반 스푸핑 대책이 될 것이라고 생각합니다. ARP 패킷은 항상 라우팅되지 않으므로 로컬 LAN 에서이 작업을 수행한다고 가정합니다. 호스트를 ping하거나 한 번만 추적 할 때마다이 상황이 일관되게 발생합니까? 이 경우 해당 호스트의 ARP 캐시가 동시에 시간 초과되었을 수 있습니다.

머신을 핑하는 호스트에서 어떤 OS가 실행되고 있습니까?

나는 그것이 버그라고 생각한다. 다음 추적은 Ping에서 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 주소를 기록하는 '기능'일 수 있습니다. 핑 스팸을 추적하는 데 유용한 정보가 될 수 있습니다.