แปลก: ทำไมลินุกซ์ตอบสนองต่อการ ping ด้วยการร้องขอ ARP หลังจากตอบ ping ครั้งสุดท้าย?

ฉัน (และเพื่อนร่วมงาน) เพิ่งสังเกตเห็นและทดสอบว่าเมื่อเครื่อง Linux ถูก ping หลังจาก ping ล่าสุดมันเริ่มต้นการร้องขอ ARP แบบ unicastไปยังเครื่องที่เริ่มต้นการ ICMP ping เมื่อส่งสัญญาณไปยังเครื่อง Windows เครื่อง Windows จะไม่ส่งคำขอ ARP ในตอนท้าย

ใครบ้างทราบว่าจุดประสงค์ของคำขอ ARP แบบ Unicast นี้คืออะไรและเหตุใดจึงเกิดขึ้นบน 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

อัปเดต:ฉันเพิ่งจะเพิ่มการร้องขอ ARP แบบ unicastและการอ้างอิงที่มีประโยชน์เพียงอย่างเดียวที่ฉันพบคือRFC 4436ซึ่งเกี่ยวกับ "การตรวจจับไฟล์แนบเครือข่าย" (จากปี 2549) เทคนิคนี้ใช้ unicast ARPs เพื่อให้โฮสต์ตรวจสอบว่ามีการเชื่อมต่อใหม่กับเครือข่ายที่รู้จักก่อนหน้านี้หรือไม่ แต่ฉันไม่เห็นว่าสิ่งนี้นำไปใช้กับคำขอ ARP เนื่องจากการทำ ping ดังนั้นความลึกลับยังคงอยู่ ...

Linux ส่งคำขอ ARP แบบยูนิคาสต์ต่างๆเพื่ออัปเดตแคช ARP นี่คือการป้องกันรายการแคช ARP เก่า (และอาจเป็นอันตราย)

มีบางสถานการณ์ที่ใช้ unicast ARP โดยทั่วไปจะตรวจสอบแคช ARP หากรายการค้างแล้วทางเลือกคือการออกอากาศ ARP

สิ่งนี้ถูกกล่าวถึงในRFC1122 2.3.2.1

ฉันคิดว่านั่นคือสิ่งที่มันกำลังทำอยู่เพราะเหตุใดการเดาครั้งแรกของฉันจะเป็นมาตรการต่อต้านการปลอมแปลง แพ็คเก็ต ARP นั้นไม่เคยถูกกำหนดเส้นทางดังนั้นฉันคิดว่าคุณกำลังทำสิ่งนี้ใน LAN ท้องถิ่น สถานการณ์นี้เกิดขึ้นอย่างสม่ำเสมอทุกครั้งที่คุณทำการปิงโฮสต์หรือตรวจสอบเพียงครั้งเดียว? ในกรณีนี้แคช ARP สำหรับโฮสต์นั้นอาจหมดเวลาโดยบังเอิญ

ระบบปฏิบัติการใดที่ทำงานอยู่บนโฮสต์ที่คุณกำลังกระตุกเครื่อง

ฉันคิดว่ามันเป็นข้อผิดพลาด การติดตามต่อไปนี้มาจากการ ping ไปยังที่อยู่ที่อยู่ในแคช ARP แต่เก่า ฉันไม่สามารถนึกถึงเหตุผลที่ดีในการunicast 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 ของไคลเอนต์เมื่อใดก็ตามที่เครื่องตอบรับชุดปิงหรือจำนวนปิงที่แน่นอน มันอาจเป็นข้อมูลที่มีประโยชน์สำหรับการติดตามปิงสแปม