🍻 📘 🛂 चैनल पर सभी IPv6 होस्ट पिंग करें 🚧 🤘🏾 🕜

OTUS से पाठ्यक्रम "नेटवर्क इंजीनियर" पर एक नई धारा शुरू होने तक कुछ दिन शेष हैं । इस संबंध में, हम आपके साथ विषय पर उपयोगी सामग्री का अनुवाद करना चाहते हैं।

IPv6 पिंग समस्या निवारण टिप्स और ट्रिक्स के बारे में ब्लॉग लेखों की एक श्रृंखला (ICMPv6 इको अनुरोध / इको रिप्लाई)

कृपया ध्यान दें कि मैं लिनक्स (विशेष रूप से फेडोरा 31) का उपयोग करता हूं, हालांकि अन्य ऑपरेटिंग सिस्टम के लिए पिंग कमांड सिंटैक्स, मुझे आशा है कि बहुत समान होना चाहिए।

चैनल पर सभी IPv6 होस्ट पिंग करें

पहला और सबसे आसान टिप चैनल पर सभी IPv6 होस्ट को पिंग करना है।

IPv6 सभी प्रकार के एक से कई संचार के लिए मल्टीकास्ट पतों का उपयोग करता है। कोई प्रसारण (या प्रसारण) IPv6 पते नहीं हैं। यह IPv4 से IPv6 को अलग करता है, जहां कई प्रकार के प्रसारण पते हैं, उदाहरण के लिए, "सीमित प्रसारण" पता 255.255.255.255 [RFC1122]।

हालाँकि, एक "ऑल-नोड्स मल्टिकास्ट" IPv6 एड्रेस है, इसलिए हम इसका उपयोग चैनल के सभी IPv6 नोड्स को पिंग करने के लिए करेंगे। (एक "प्रसारण" पता वास्तव में सिर्फ एक विशेष रूप से नामित मल्टीकास्ट पता है, जो एक बहुस्त्र्पीय समूह है जिसमें सभी नोड शामिल हैं। ध्यान दें कि, उदाहरण के लिए, "समूह" या मल्टीकास्ट पता बिट लिंक स्तर पर ईथरनेट प्रसारण पते में शामिल है)।

चैनल के लिए सभी नोड्स मल्टीकास्ट IPv6 एड्रेस: ff02::1. ffएक मल्टीकास्ट IPv6 एड्रेस को दर्शाता है। अगले 0 झंडे का हिस्सा परेशान बिट्स के साथ है।

आगे 2मल्टीकास्ट समूह के क्षेत्र को परिभाषित करता है। IPv4 मल्टीकास्ट पतों के विपरीत, IPv6 मल्टीकास्ट पतों में गुंजाइश है। स्कोप मान नेटवर्क के उस हिस्से को इंगित करता है जिस पर मल्टीकास्ट पैकेट की अनुमति है। एक बार जब पैकेट निर्दिष्ट दायरे की सीमा तक पहुंच जाता है, तो पैकेट को छोड़ दिया जाना चाहिए, भले ही इसका हॉप काउंट फ़ील्ड नॉनजरो हो। बेशक, यदि रूपांतरण काउंटर मल्टीकास्ट समूह की निर्दिष्ट सीमा तक पहुंचने से पहले शून्य तक पहुंचता है, तो यह भी तुरंत रीसेट हो जाता है। यहां मल्टीकास्ट स्कोप की पूरी सूची IPv6 है।

अंत में, ::1सभी नोड्स मल्टीकास्ट समूह को इंगित करता है।

पते के बारे में ff02::1यह ध्यान दिया जाना चाहिए कि यह अस्पष्ट है। IPv6 होस्ट पर कई इंटरफेस के साथ, जैसे राउटर या मल्टीहोमेड होस्ट, पते में ff02::1कुछ भी नहीं है जहां आप निर्दिष्ट कर सकते हैं कि कौन सा इंटरफ़ेस ICMPv6 पिंग्स भेजने के लिए या ICMPv6 पिंग्स के आने का इंतजार करें। ff02::1मान्य और मल्टी इंटरफेस नोड से जुड़े किसी भी इंटरफेस और चैनल पर उपयोग किया जा सकता है।

इसलिए, जब हम चैनल पर सभी आईपीवी 6 नोड्स को पिंग करते हैं, तो हमें किसी तरह pingआईपीवी 6 की उपयोगिता को भी बताना होगा कि किस इंटरफेस का उपयोग करना है।

इंटरफ़ेस परिभाषा - कमांड लाइन विकल्प

जैसा कि हमने पहले ही देखा है, ऑल-नोड्स मल्टीकास्ट पता जिसे हम उपयोग करना चाहते हैं - ff02::1- कोई भी जानकारी प्रदान नहीं करता है कि किस इंटरफ़ेस को ICMPv6 इको अनुरोध और इको रिप्लाई पैकेट भेजना और प्राप्त करना है।

तो, हम उस इंटरफ़ेस को कैसे निर्दिष्ट करते हैं जो मल्टीकास्ट एड्रेस स्पेस या यूनिकस्ट लिंक-लोकल एड्रेस के लिए उपयोग किया जाएगा?

पहला और सबसे स्पष्ट तरीका यह है कि हम जिस एप्लिकेशन का उपयोग करते हैं, उसके लिए एक पैरामीटर के रूप में प्रदान करें।

उपयोगिता के लिए, pingहम इसे विकल्प के माध्यम से प्रदान करते हैं -I।

[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
 
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$

इस सभी नोड्स मल्टीकास्ट पिंग का उपयोग करते हुए, हमें 6 आईपीवी 6 नोड्स से प्रतिक्रियाएं मिलीं। उपसर्ग से शुरू होने वाले मेजबान लिंक-स्थानीय IPv6 पतों से प्रतिक्रियाएं आईं fe80::/10।

करने के लिए pingबेहद जब तक हम इसे निरस्त करने के लिए जारी रखने से ICMPv6 गूंज अनुरोध को रोकने, हम आम तौर -c विकल्प के माध्यम से भेजने के लिए पैकेट की संख्या निर्दिष्ट करें। हालांकि, यह एक मल्टीकास्ट ICMPv6 इको अनुरोध भेजते समय पिंग को एक से अधिक ICMPv6 इको रिप्लाई प्राप्त करने और प्रदर्शित करने से रोकता है। इसके बजाय, हमने यह इंगित करने के लिए -w विकल्प का उपयोग किया कि पिंग 1 सेकंड के बाद पूरा होना चाहिए, चाहे कितने ICMPv6 पिंग या पिंग भेजे या प्राप्त किए गए हों।

एक और बात पर ध्यान देना है (DUP!) दूसरे और बाद के उत्तरों पर निष्कर्ष। इन पैकेटों को प्रतिक्रिया के डुप्लिकेट के रूप में पहचाना जाता है, क्योंकि उनके पास ICMP अनुक्रम मान वैसा ही है जैसा कि पहले ICMPv6 पिंग्स के लिए भेजा जाता था। वे प्रकट होते हैं क्योंकि ICMPv6 मल्टीकास्ट इको अनुरोध कई व्यक्तिगत यूनिकस्ट प्रतिक्रियाओं में परिणाम देता है। डुप्लिकेट की संख्या को आंकड़े सारांश में भी दर्शाया गया है।

इंटरफ़ेस परिभाषा - ज़ोन आईडी

उपयोग करने के लिए एक इंटरफ़ेस प्रदान करने का दूसरा तरीका IPv6 एड्रेस पैरामीटर का हिस्सा है।

हम इसका उदाहरण पिंग आउटपुट में देख सकते हैं, जहाँ प्रतिसाद देने वाले IPv6 नोड्स के पतों में एक प्रत्यय भी है %enp3s2, उदाहरण के लिए:

64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms

इंटरफेस निर्दिष्ट करने का यह तरीका औपचारिक रूप से [RFC4007], "IPv6 एड्रेस के साथ आर्किटेक्चर निर्दिष्ट" में वर्णित है। यद्यपि उन्हें आमतौर पर ऑपरेटिंग सिस्टम इंटरफ़ेस कहा जाता है, वे वास्तव में कुछ अधिक सामान्य परिभाषित करते हैं - एक "ज़ोन" या "स्कोप"।

अधिक सामान्य ज़ोन या स्कोप ज़ोन होने का कारण है, जैसा कि [RFC4007] में बताया गया है, एक IPv6 होस्ट में एक ही चैनल से जुड़े कई अलग-अलग IPv6 इंटरफेस हो सकते हैं। ये इंटरफेस उसी ज़ोन के सदस्य हैं।

ऑपरेटिंग सिस्टम के तहत ज़ोन के भीतर कई इंटरफेस को समूह बनाना संभव होना चाहिए; वर्तमान में, मुझे नहीं पता कि क्या लिनक्स के तहत यह संभव है और यह कैसे करना है।

प्रत्यय का उपयोग करके %<zone_id>, हम कमांड लाइन पैरामीटर को हटा सकते हैं -I ping।

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
 
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
 
[mark@opy ~]$

लिंक-स्थानीय पता प्रतिक्रियाएँ

इस सभी नोड्स मल्टीकास्ट पिंग से हमें कुल 6 अद्वितीय प्रतिक्रियाएँ मिलीं।

ये प्रतिक्रियाएं Unicast Link-Local IPv6 होस्ट पतों से आई हैं। उदाहरण के लिए, यहां पहला जवाब है:

64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms

सभी आईपीवी 6-सक्षम इंटरफेस [आरएफसी 4291], आईपी संस्करण 6 एड्रेसिंग आर्किटेक्चर पर आवश्यक लिंक-स्थानीय आईपीवी 6 पते। इसका कारण यह है कि IPv6 होस्ट के पास हमेशा एक यूनिकैस्ट IPv6 एड्रेस होता है, जिसे वह कम से कम अपने सीधे जुड़े हुए चैनलों के माध्यम से अन्य मेजबानों के साथ संवाद करने के लिए उपयोग कर सकता है। इसमें लिंक-स्थानीय होस्ट पतों के माध्यम से अन्य होस्ट के अनुप्रयोगों के साथ संचार शामिल है।

यह IPv6 नेबर डिस्कवरी और OSPFv3 जैसे प्रोटोकॉल के विकास और कार्यान्वयन को सरल बनाता है। यह चैनल पर किसी अन्य सहायक IPv6 बुनियादी ढांचे की आवश्यकता के बिना मेजबान पर संचार करने के लिए मेजबान पर अंतिम-उपयोगकर्ता अनुप्रयोगों की भी अनुमति देता है। कनेक्टेड IPv6 होस्ट्स के बीच सीधे संचार के लिए कनेक्शन में IPv6 राउटर या DHCPv6 सर्वर की आवश्यकता नहीं होती है।

लिंक-स्थानीय पते 10-बिट उपसर्ग से शुरू होते हैं fe80, इसके बाद 54 शून्य बिट्स, उसके बाद 64-बिट इंटरफ़ेस आइडेंटिफ़ायर (IID) होता है। उपरोक्त पहले उत्तर में 2392:6213:a15b:66ff, यह 64-बिट IID है।

लूप्ड मल्टीकास्ट

डिफ़ॉल्ट रूप से, मल्टीकास्ट पैकेट आंतरिक रूप से उस नोड पर लौटाए जाते हैं जो उन्हें भेजता है। यह IPv6 और IPv4 दोनों पतों के लिए होता है।

इस डिफ़ॉल्ट व्यवहार का कारण यह है कि मल्टीकास्ट पैकेट भेजते समय, सुनने वाले होस्ट मल्टीकास्ट एप्लिकेशन को स्वयं होस्ट करने के साथ-साथ नेटवर्क पर भी चल सकता है। इस स्थानीय एप्लिकेशन को मल्टीकास्ट पैकेट भी मिलना चाहिए।

हम इस मल्टीकास्ट लोकल लूप को अपने पिंग आउटपुट में देख सकते हैं:

[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...

इंटरफ़ेस पर कॉन्फ़िगर किए गए लिंक-स्थानीय पते से पहली और सबसे तेज़ प्रतिक्रिया (0.453 एमएस की तुलना में 0.106 एमएस) आती है enp3s2।

[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
    inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute 
[mark@opy ~]$

उपयोगिता pingएक पैरामीटर का उपयोग करके मल्टीकास्ट मेलिंग की स्थानीय प्रतिक्रिया को दबाने का एक तरीका प्रदान करती है -L। यदि हम इस ध्वज के साथ एक सभी नोड्स मल्टीकास्ट पिंग भेजते हैं, तो प्रतिक्रियाएं दूरस्थ नोड्स तक सीमित हैं। हमें प्रेषक इंटरफ़ेस के लिंक-स्थानीय पते से प्रतिक्रिया नहीं मिलती है।

[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
 
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...

पिंग लिंक-स्थानीय पते

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

इस बार हम -cभेजे गए और प्राप्त किए गए पैकेटों और प्रतिक्रियाओं की संख्या को सीमित करने के लिए उपयोग कर सकते हैं ping, क्योंकि हम एकतरफा पिंग करते हैं।

[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
 
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
 
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$

पिंग (सभी) अन्य IPv6 पते?

इस लेख में, हमने देखा कि कैसे एक चैनल पर सभी आईपीवी 6 नोड्स को सभी नोड्स मल्टीकास्ट आईपीवी 6 पते का उपयोग करके पिंग किया जाए ff02::1। हमने यह भी देखा कि ऑल-नोड्स मल्टीकास्ट IPv6 एड्रेस के साथ किस इंटरफ़ेस का उपयोग करना है, यह कैसे निर्दिष्ट किया जाए क्योंकि केवल एड्रेस ही यह जानकारी प्रदान नहीं कर सकता है। हमने या तो कमांड लाइन पैरामीटर का उपयोग किया या pingप्रत्यय के माध्यम से एक इंटरफ़ेस निर्दिष्ट किया %<zone_id>।

फिर हमने यूनिकैस्ट लिंक-लोकल एड्रेस के बारे में सीखा, जो सभी नोड्स मल्टीकास्ट ICMPv6 इको रिक्वेस्ट का जवाब देने के लिए उपयोग किए जाने वाले एड्रेस हैं।

हमने यह भी देखा कि मल्टीकास्ट पैकेट कैसे डिफ़ॉल्ट रूप से भेजने वाले मेजबान को लौटाते हैं और उपयोगिता के लिए इसे कैसे निष्क्रिय करते हैं ping।

अंत में, हमने प्रत्यय का उपयोग करके एक ही लिंक-स्थानीय पता पिंग किया%<zone_id>चूंकि लिंक-स्थानीय पते अकेले आउटगोइंग इंटरफ़ेस के बारे में जानकारी प्रदान नहीं करते हैं।

तो अन्य सभी नोड्स को पिंग करने और उनके वैश्विक यूनिकैस्ट एड्रेस (GUAs) (यानी उनके सार्वजनिक इंटरनेट पते) या उनके अनूठे स्थानीय यूनिकस्ट एड्रेस (ULAs) को पुनः प्राप्त करने के बारे में क्या? हम इसे अगले ब्लॉग पोस्ट में कवर करेंगे।

बस इतना ही।

आप खुले दिन की प्रविष्टि में हमारे पाठ्यक्रम के बारे में अधिक जानकारी प्राप्त कर सकते हैं ।

चैनल पर सभी IPv6 होस्ट पिंग करें