नए पाठ्यक्रम की शुरुआत होने में अब कुछ ही दिन बचे हैं ओटीयूएस से। इस संबंध में, हम आपके साथ इस विषय पर उपयोगी सामग्री का अनुवाद साझा करना चाहेंगे।
IPv6 पिंग (ICMPv6 इको रिक्वेस्ट/इको रिप्लाई) समस्या निवारण टिप्स और ट्रिक्स पर ब्लॉग पोस्ट की एक श्रृंखला
कृपया ध्यान दें कि मैं लिनक्स (विशेष रूप से फेडोरा 31) का उपयोग कर रहा हूं, हालांकि अन्य ऑपरेटिंग सिस्टम के लिए पिंग कमांड सिंटैक्स बहुत समान होना चाहिए।
एक चैनल पर सभी IPv6 नोड्स को पिंग करें
पहला और सबसे आसान सुझाव यह है कि चैनल पर सभी IPv6 नोड्स को पिंग करें।
IPv6 सभी प्रकार के एक-से-कई संचार के लिए मल्टीकास्ट पतों का उपयोग करता है। कोई प्रसारण IPv6 पते नहीं हैं। यह IPv6 के विपरीत है, जहाँ कई प्रकार के प्रसारण पते हैं, जैसे कि "सीमित प्रसारण" पता 4 [RFC255.255.255.255]।
हालाँकि, एक “ऑल-नोड्स मल्टीकास्ट” IPv6 पता है, इसलिए हम लिंक पर सभी IPv6 नोड्स को पिंग करने के लिए इसका उपयोग करेंगे। (“ब्रॉडकास्ट” पता वास्तव में सिर्फ़ एक विशेष रूप से नामित मल्टीकास्ट पता है, जो एक मल्टीकास्ट समूह है जिसमें सभी नोड्स शामिल हैं। ध्यान दें कि, उदाहरण के लिए, “समूह” या मल्टीकास्ट पता बिट डेटा लिंक परत पर ईथरनेट ब्रॉडकास्ट पतों पर सक्षम है।)
चैनल के लिए सभी-नोड्स मल्टीकास्ट IPv6 पता: ff02::1. ff मल्टीकास्ट IPv6 पता दर्शाता है। इसके बाद 0 फ्लैग का वह भाग है जिसमें बिट्स सेट नहीं हैं।
अगला 2 मल्टीकास्ट समूह के दायरे को परिभाषित करता है। IPv4 मल्टीकास्ट पतों के विपरीत, IPv6 मल्टीकास्ट पतों का एक दायरा होता है। दायरा मान नेटवर्क के उस हिस्से को निर्दिष्ट करता है जिस पर मल्टीकास्ट पैकेट को अग्रेषित करने की अनुमति है। एक बार जब पैकेट निर्दिष्ट दायरे की सीमा तक पहुँच जाता है, तो पैकेट को त्याग दिया जाना चाहिए, भले ही उसका हॉप काउंट फ़ील्ड गैर-शून्य हो। बेशक, अगर हॉप काउंट निर्दिष्ट मल्टीकास्ट समूह सीमा तक पहुँचने से पहले शून्य पर पहुँच जाता है, तो इसे भी तुरंत त्याग दिया जाता है। यहाँ IPv6 मल्टीकास्ट स्कोप की पूरी सूची दी गई है।
अंत में, ::1 सभी-नोड्स मल्टीकास्ट समूह निर्दिष्ट करता है.
पते के बारे में ff02::1 यह ध्यान दिया जाना चाहिए कि यह अस्पष्ट है। एकाधिक इंटरफेस वाले IPv6 नोड पर, जैसे कि राउटर या मल्टीहोम होस्ट, पता ff02::1 इसमें यह निर्दिष्ट करने के लिए कुछ भी नहीं है कि ICMPv6 इको अनुरोध किस इंटरफ़ेस पर भेजे जाएं या जब वे पहुंचें तो ICMPv6 इको प्रत्युत्तर की अपेक्षा की जाए। ff02::1 मान्य है और इसका उपयोग बहु-इंटरफ़ेस नोड से जुड़े किसी भी इंटरफेस और चैनल पर किया जा सकता है।
इसलिए जब हम चैनल पर सभी IPv6 नोड्स को पिंग करते हैं, तो हमें किसी तरह उपयोगिता को भी बताना होगा ping IPv6 के लिए कौन सा इंटरफ़ेस उपयोग करना है।
इंटरफेस परिभाषित करना - कमांड लाइन विकल्प
जैसा कि हम पहले ही देख चुके हैं, हम जिस ऑल-नोड्स मल्टीकास्ट एड्रेस का उपयोग करना चाहते हैं वह है 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 IPv6 नोड्स से प्रतिक्रियाएँ प्राप्त हुईं। प्रतिक्रियाएँ नोड के लिंक-लोकल IPv6 पतों से आईं, जो प्रीफ़िक्स से शुरू होती हैं fe80::/10.
कि ping पिंग को अनिश्चित काल तक ICMPv6 इको अनुरोध भेजने से रोकने के लिए जब तक कि हम इसे बाधित न करें, हम आम तौर पर -c विकल्प के माध्यम से भेजे जाने वाले पैकेटों की संख्या निर्दिष्ट करते हैं। हालाँकि, यह पिंग को ICMPv6 इको अनुरोध मल्टीकास्ट भेजते समय एक से अधिक ICMPv6 इको उत्तर प्राप्त करने और प्रदर्शित करने से भी रोकता है। इसके बजाय, हमने यह निर्दिष्ट करने के लिए -w विकल्प का उपयोग किया कि पिंग को 1 सेकंड के बाद समाप्त कर देना चाहिए, चाहे कितने भी ICMPv6 इको अनुरोध या इको उत्तर भेजे या प्राप्त किए गए हों।
एक और बात ध्यान देने योग्य है (DUP!) दूसरे और बाद की प्रतिक्रियाओं पर आउटपुट। इन पैकेटों को डुप्लिकेट प्रतिक्रियाओं के रूप में पहचाना जाता है क्योंकि उनके पास पहले स्थान पर भेजे गए व्यक्तिगत ICMPv6 इको अनुरोधों के समान ICMP अनुक्रम मान होता है। वे इसलिए होते हैं क्योंकि मल्टीकास्ट 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 अद्वितीय प्रतिक्रियाएं प्राप्त हुईं।
ये प्रतिक्रियाएँ IPv6 नोड्स के यूनिकास्ट लिंक-लोकल पतों से आईं। उदाहरण के लिए, यहाँ पहली प्रतिक्रिया है:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msसभी IPv6-सक्षम इंटरफेस पर यूनिकास्ट लिंक-लोकल IPv6 पते आवश्यक हैं [RFC4291], "IP संस्करण 6 एड्रेसिंग आर्किटेक्चर"। इसका कारण यह है कि IPv6 नोड में हमेशा स्वचालित रूप से एक यूनिकास्ट IPv6 पता होता है जिसका उपयोग वह कम से कम अपने सीधे जुड़े लिंक पर अन्य नोड्स के साथ संचार करने के लिए कर सकता है। इसमें होस्ट के लिंक-लोकल पतों के माध्यम से अन्य होस्ट पर अनुप्रयोगों के साथ संचार करना शामिल है।
यह IPv6 नेबर डिस्कवरी और OSPFv3 जैसे प्रोटोकॉल के डिजाइन और कार्यान्वयन को सरल बनाता है। यह होस्ट पर एंड-यूज़र एप्लिकेशन को लिंक पर किसी अन्य IPv6-सक्षम इंफ्रास्ट्रक्चर की आवश्यकता के बिना लिंक पर संचार करने की अनुमति देता है। कनेक्टेड IPv6 होस्ट के बीच सीधे संचार के लिए कनेक्शन में IPv6 राउटर या DHCPv6 सर्वर की आवश्यकता नहीं होती है।
लिंक-लोकल पते 10-बिट उपसर्ग से शुरू होते हैं fe80, उसके बाद 54 शून्य बिट्स, और फिर 64-बिट इंटरफ़ेस पहचानकर्ता (IID)। ऊपर दिए गए पहले उत्तर में, 2392:6213:a15b:66ff — एक 64-बिट आईआईडी है.
लूप्ड मल्टीकास्ट
डिफ़ॉल्ट रूप से, मल्टीकास्ट पैकेट आंतरिक रूप से उस नोड को वापस कर दिए जाते हैं जो उन्हें भेजता है। यह 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,106ms की तुलना में 0,453ms) इंटरफ़ेस पर ही कॉन्फ़िगर किए गए लिंक-लोकल पते से आती है 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 पतों को पिंग करें?
इस लेख में, हमने देखा कि ऑल-नोड्स मल्टीकास्ट IPv6 एड्रेस का उपयोग करके किसी चैनल पर सभी IPv6 नोड्स को कैसे पिंग किया जाए। ff02::1हमने यह भी देखा कि ऑल-नोड्स मल्टीकास्ट IPv6 एड्रेस के साथ किस इंटरफ़ेस का उपयोग करना है, यह कैसे निर्दिष्ट किया जाए, क्योंकि एड्रेस स्वयं यह जानकारी प्रदान नहीं कर सकता है। हमने या तो कमांड लाइन विकल्प का उपयोग किया ping, या प्रत्यय के माध्यम से इंटरफ़ेस निर्दिष्ट किया %<zone_id>.
इसके बाद हमने यूनिकास्ट लिंक-लोकल एड्रेस के बारे में सीखा, जो ICMPv6 ऑल-नोड्स मल्टीकास्ट इको अनुरोधों का जवाब देने के लिए उपयोग किए जाने वाले एड्रेस हैं।
हमने यह भी देखा कि मल्टीकास्ट पैकेट्स को डिफ़ॉल्ट रूप से भेजने वाले नोड पर कैसे लौटाया जाता है और उपयोगिता के लिए इसे कैसे अक्षम किया जाता है। ping.
अंत में, हमने प्रत्यय का उपयोग करके एक एकल लिंक-स्थानीय पता पिंग किया %<zone_id>, क्योंकि लिंक-लोकल पते स्वयं भी आउटगोइंग इंटरफ़ेस के बारे में जानकारी प्रदान नहीं करते हैं।
तो फिर बाकी सभी नोड्स को पिंग करके उनके ग्लोबल यूनिकास्ट एड्रेस (GUAs) (यानी इंटरनेट पर उनके सार्वजनिक रूप से सुलभ पते) या उनके अद्वितीय स्थानीय यूनिकास्ट एड्रेस (ULAs) प्राप्त करने के बारे में क्या ख्याल है? हम अगले ब्लॉग पोस्ट में इस पर चर्चा करेंगे।
बस इतना ही।
आप हमारे पाठ्यक्रम के बारे में अधिक जानकारी प्राप्त कर सकते हैं.
स्रोत: www.habr.com
