ایک چینل پر تمام IPv6 نوڈس پنگ کریں۔

شرح پر ایک نیا بہاؤ شروع ہونے میں کچھ دن باقی ہیں۔ "نیٹ ورک انجینئر" OTUS سے اس سلسلے میں، ہم آپ کے ساتھ اس موضوع پر مفید مواد کا ترجمہ شیئر کرنا چاہتے ہیں۔

ایک چینل پر تمام IPv6 نوڈس پنگ کریں۔

IPv6 پنگ کے مسائل کو حل کرنے کے لئے تجاویز اور چالوں پر بلاگ پوسٹس کا ایک سلسلہ (ICMPv6 ایکو درخواست/ایکو جواب)

براہ کرم نوٹ کریں کہ میں لینکس (خاص طور پر فیڈورا 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 echo درخواستوں کو بھیجنا ہے یا ان کے پہنچنے پر 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 echo درخواستوں کو غیر معینہ مدت تک بھیجنا جاری نہیں رکھتا جب تک کہ ہم اس میں خلل نہیں ڈالتے، ہم عام طور پر -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 Defined Address Architecture" میں بیان کیا گیا ہے۔ اگرچہ انہیں عام طور پر آپریٹنگ سسٹم انٹرفیس کہا جاتا ہے، لیکن وہ درحقیقت کچھ زیادہ عمومی یعنی "زون" یا "دائرہ کار" کی وضاحت کرتے ہیں۔

زیادہ عمومی زونز یا اسکوپ زونز ہونے کی وجہ یہ ہے کہ جیسا کہ [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

Unicast Link-Local IPv6 ایڈریس تمام IPv6-enabled انٹرفیس [RFC4291]، "IP ورژن 6 ایڈریسنگ آرکیٹیکچر" پر درکار ہیں۔ اس کی وجہ یہ ہے کہ ایک IPv6 نوڈ میں ہمیشہ خود بخود ایک unicast IPv6 پتہ ہوتا ہے، جسے وہ کم از کم اپنے براہ راست جڑے ہوئے لنکس پر دوسرے نوڈس کے ساتھ بات چیت کرنے کے لیے استعمال کر سکتا ہے۔ اس میں لنک-لوکل میزبان پتوں کے ذریعے دوسرے میزبانوں پر ایپلیکیشنز کے ساتھ بات چیت شامل ہے۔

یہ IPv6 Neighbor 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!)
...

پہلا اور تیز ترین جواب (0,106 ms کے مقابلے میں 0,453 ms) خود انٹرفیس پر کنفیگر کردہ Link-Local ایڈریس سے آتا ہے۔ 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 یا لنک-مقامی پتوں کو پنگ کرتے وقت ایڈریس کے ساتھ زون ID۔

اس بار ہم استعمال کر سکتے ہیں۔ -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

نیا تبصرہ شامل کریں