चॅनेलवर सर्व IPv6 नोड्स पिंग करा

दराने नवीन प्रवाह सुरू होण्यास काही दिवस शिल्लक आहेत "नेटवर्क अभियंता" OTUS कडून. या संदर्भात, आम्ही आपल्याशी या विषयावरील उपयुक्त सामग्रीचे भाषांतर सामायिक करू इच्छितो.

IPv6 पिंग समस्यांचे निवारण करण्यासाठी टिपा आणि युक्त्यांवरील ब्लॉग पोस्टची मालिका (ICMPv6 इको रिक्वेस्ट/इको रिप्लाय)

कृपया लक्षात घ्या की मी लिनक्स (विशेषतः Fedora 31) वापरत आहे, तथापि इतर ऑपरेटिंग सिस्टीमसाठी पिंग कमांड सिंटॅक्स खूप समान असावे.

चॅनेलवर सर्व IPv6 नोड्स पिंग करा

पहिली आणि सोपी टीप म्हणजे लिंकवर सर्व IPv6 नोड्स पिंग करणे.

IPv6 सर्व प्रकारच्या एक ते अनेक संप्रेषणांसाठी मल्टीकास्ट पत्ते वापरते. कोणतेही ब्रॉडकास्ट (किंवा ब्रॉडकास्ट) IPv6 पत्ते नाहीत. हे IPv6 ला IPv4 पासून वेगळे करते, जेथे अनेक प्रकारचे प्रसारण पत्ते आहेत, उदाहरणार्थ, “मर्यादित प्रसारण” पत्ता 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 वैध आहे आणि मल्टी-इंटरफेस नोडशी संलग्न कोणत्याही इंटरफेस आणि चॅनेलवर वापरले जाऊ शकते.

म्हणून जेव्हा आपण सर्व 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 नोड्सकडून प्रतिसाद मिळाला. प्रतिसाद Link-Local IPv6 नोड पत्त्यांकडून आले आहेत, उपसर्गापासून सुरू होणारे fe80::/10.

की ping ICMPv6 प्रतिध्वनी विनंत्या जोपर्यंत आम्ही त्यात व्यत्यय आणत नाही तोपर्यंत अनिश्चित काळासाठी पाठवणे सुरू ठेवत नाही, आम्ही सहसा -c पर्यायाद्वारे पाठवण्याच्या पॅकेटची संख्या निर्दिष्ट करतो. तथापि, हे मल्टिकास्ट ICMPv6 प्रतिध्वनी विनंती पाठवताना एकापेक्षा जास्त ICMPv6 प्रतिध्वनी प्रत्युत्तर स्वीकारण्यापासून आणि प्रदर्शित करण्यापासून पिंगला प्रतिबंधित करते. त्याऐवजी, कितीही ICMPv1 प्रतिध्वनी विनंत्या किंवा प्रतिध्वनी प्रत्युत्तरे पाठवली किंवा प्राप्त झाली तरीही पिंग 6 सेकंदानंतर पूर्ण झाले पाहिजे हे निर्दिष्ट करण्यासाठी आम्ही -w पर्याय वापरला.

लक्ष देण्यासारखी दुसरी गोष्ट म्हणजे (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 अद्वितीय प्रतिसाद मिळाले.

हे प्रतिसाद unicast Link-Local 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 Neighbour Discovery आणि 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!)
...

पहिला आणि जलद प्रतिसाद (०.४५३ एमएसच्या तुलनेत ०.१०६ एमएस) इंटरफेसवरच कॉन्फिगर केलेल्या लिंक-स्थानिक पत्त्यावरून येतो. 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