अजीब बात है: अंतिम पिंग उत्तर के बाद लाइनक्स एआरपी अनुरोध के साथ पिंग का जवाब क्यों देता है?

12

मैंने (एक सहकर्मी ने) बस ध्यान दिया है, और परीक्षण किया है, कि जब एक लिनक्स मशीन पिंग की जाती है, तो अंतिम पिंग के बाद यह ICMP पिंग शुरू करने वाली मशीन को एक यूनिकस्ट ARP अनुरोध देता है। विंडोज मशीन से पिंग करते समय, विंडोज मशीन अंत में एआरपी अनुरोध जारी नहीं करती है।

क्या किसी को पता है कि इस यूनिकस्ट एआरपी अनुरोध का क्या उद्देश्य है, और यह लिनक्स पर क्यों होता है और विंडोज पर नहीं?

Wireshark ट्रेस (10.20.30.45 लिनक्स बॉक्स होने के साथ):

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

अपडेट: मैंने यूनिकस्ट एआरपी अनुरोध एस के लिए अभी कुछ और जाना है , और मैंने जो एकमात्र उपयोगी संदर्भ पाया है वह आरएफसी 4436 में है जो "डिटेक्टिंग नेटवर्क अटैचमेंट" (2006 से) के बारे में है। यह तकनीक एक होस्ट को अनुमति देने के लिए यूनिकस्ट एआरपी का उपयोग करती है ताकि यह पता चल सके कि यह पहले से ज्ञात नेटवर्क से फिर से जुड़ गया है या नहीं। लेकिन मैं यह नहीं देखता कि पिंग करने के परिणामस्वरूप यह ARP अनुरोध पर कैसे लागू होता है। इसलिए रहस्य बना हुआ है ...

— Rabarberski
स्रोत

4

लिनक्स इसे एआरपी कैश अपडेट करने के लिए विभिन्न यूनिकस्ट एआरपी अनुरोध भेजता है। यह बासी (और संभावित रूप से दुर्भावनापूर्ण) एआरपी कैश प्रविष्टियों को रोकने के लिए है।

कुछ स्थितियाँ ऐसी हैं जहाँ यूनिकस्ट एआरपी का उपयोग किया जाता है, मूल रूप से एआरपी कैश को मान्य करने के लिए। यदि प्रविष्टि बासी है, तो गिरावट एआरपी प्रसारित करने के लिए है।

यह RFC1122 2.3.2.1 में चर्चा की गई है

मुझे लगता है कि यह वही कर रहा है, जैसा कि क्यों, मेरा पहला अनुमान किसी तरह का एंटी-स्पूफिंग उपाय होगा। ARP पैकेट हमेशा रूट नहीं किए जाते हैं, इसलिए मैं मान रहा हूं कि आप अपने स्थानीय LAN पर ऐसा कर रहे हैं? क्या यह स्थिति लगातार हर बार जब आप मेजबान को पिंग करते हैं या आपने केवल एक बार पता लगाया है? जिस स्थिति में, उस होस्ट के लिए ARP कैश संयोगवश समाप्त हो रहा होगा।

आप जिस मशीन से पिंग कर रहे हैं, उस पर OS क्या चल रहा है?

— फिलिप रेनॉल्ड्स
स्रोत

RFC लिंक के लिए धन्यवाद। मैंने सोचा था कि समय-समय पर पुरानी arp प्रविष्टियों से छुटकारा पाने और arp कैश आकार सीमित रखने का डिफ़ॉल्ट तरीका था। उत्तरार्द्ध यूनिकैस्ट एआरपी के प्रदर्शन से नहीं लगता है (लेकिन शायद एक टाइमआउट भी है)। हमने इसे 3 बार एक स्थानीय परीक्षित LAN पर (दो बार लिनक्स मशीन से और एक बार एक WinXP मशीन से) परीक्षण किया है। मैं भी अपने पीसी पर एक VMWare Ubuntu 9.04 के लिए अपने पीसी (WinXP) से पिंग द्वारा 'असली' लैन पर यह परीक्षण किया है। समान परिणाम, एक ही समय (2 सेकंड)।

— राबार्शस्की

क्या आपके पास 'लिनक्स विभिन्न यूनिकस्ट एआरपी अनुरोधों को भेजने का कोई लिंक है ...' का दावा है?

— राबार्शस्की

मुझे यकीन नहीं है, लेकिन यह एआरपी स्पूफिंग काउंटरमर्ज़ की तरह दिखता है। मुझे आश्चर्य है कि यह कितना प्रभावी है, मेरा मतलब है, मैक पते ईथरनेट फ्रेम स्विच करने के लिए उपयोग किए जाते हैं, यूनिकस्ट संदेश का उपयोग करके इसे अंतिम मशीन पर सीधे चलेगा, जिसमें गंतव्य मैक आया था ...

— Hubert Kario

1

मुझे लगता है कि यह एक बग है। निम्नलिखित ट्रेस एक पिंग से एक पते तक है जो एआरपी कैश में है लेकिन बासी है। मैं करने के लिए कोई अच्छा कारण नहीं सोच सकते हैं यूनिकास्ट इस तरह के एक कम समय में दो बार एआरपी। यह 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

— टोनी
स्रोत

मुझे ऐसा लगता है जैसे यह दोनों पक्ष अपने एआरपी कैश की वैधता की जांच कर रहे हैं; उन दो इंटरचेंज विपरीत दिशाओं में चले गए, और उनकी प्रविष्टियां अनिवार्य रूप से एक ही उम्र की होंगी, और इसलिए एक ही समय में और बाहर की जाँच की जाएगी।

— चोरीमहल

-1

बस एक अनुमान .. लेकिन जब भी मशीन पिंग श्रृंखला या पिंग की संख्या का जवाब देती है, तो क्लाइंट के मैक पते को लॉग करने के लिए यह एक 'सुविधा' हो सकती है। यह पिंग स्पैम को ट्रैक करने के लिए उपयोगी जानकारी हो सकती है।

— क्रिस नवा
स्रोत

लेकिन इस 'सुविधा' को ARP अनुरोध भेजने की आवश्यकता नहीं होगी, क्योंकि स्पैम मशीन पहले ही ICMP पिंग अनुरोध से MAC पता निकाल सकती है।

— राबार्शस्की 15