تبقى بضعة أيام حتى بدء التدفق الجديد بالمعدل من أوتوس. وفي هذا الصدد، نود أن نشارككم ترجمة لمواد مفيدة حول هذا الموضوع.
سلسلة من منشورات المدونة حول النصائح والحيل لاستكشاف مشكلات اختبار اتصال IPv6 وإصلاحها (طلب صدى ICMPv6/رد الارتداد)
يرجى ملاحظة أنني أستخدم Linux (على وجه التحديد Fedora 31)، ولكن نأمل أن يكون بناء جملة أمر ping لأنظمة التشغيل الأخرى مشابهًا جدًا.
اختبار اتصال كافة عقد IPv6 على القناة
النصيحة الأولى والأبسط هي اختبار اتصال جميع عقد IPv6 على الرابط.
يستخدم IPv6 عناوين البث المتعدد لجميع أنواع الاتصالات من طرف إلى طرف. لا توجد عناوين بث (أو بث) IPv6. وهذا ما يميز IPv6 عن IPv4، حيث توجد عدة أنواع من عناوين البث، على سبيل المثال، عنوان "البث المحدود" 255.255.255.255 [RFC1122].
ومع ذلك، يوجد عنوان IPv6 "للبث المتعدد لجميع العقد"، لذلك سنستخدمه لإجراء اختبار اتصال جميع عقد IPv6 على الرابط. (عنوان "البث" هو في الواقع مجرد عنوان بث متعدد مسمى خصيصًا، وهو عبارة عن مجموعة بث متعدد تتضمن جميع العقد. لاحظ أنه، على سبيل المثال، يتم تشغيل "المجموعة" أو بت عنوان البث المتعدد في عناوين بث Ethernet في طبقة الارتباط ).
عنوان IPv6 للبث المتعدد لجميع العقد للقناة: ff02::1. ff يشير إلى عنوان IPv6 متعدد البث. الصفر التالي هو جزء العلم الذي يحتوي على وحدات بت غير محددة.
إضافي 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 ~]$باستخدام اختبار ping للبث المتعدد لجميع العقد، تلقينا استجابات من 6 عقد IPv6. جاءت الاستجابات من عناوين عقدة Link-Local IPv6، بدءًا من البادئة fe80::/10.
أن ping لا يستمر في إرسال طلبات صدى ICMPv6 إلى أجل غير مسمى حتى نقوم بمقاطعتها، فنحن عادةً ما نحدد عدد الحزم المراد إرسالها عبر الخيار -c. ومع ذلك، يمنع هذا أيضًا ping من قبول وعرض أكثر من رد صدى ICMPv6 عند إرسال طلب صدى ICMPv6 متعدد البث. بدلاً من ذلك، استخدمنا الخيار -w لتحديد أن اختبار الاتصال يجب أن يكتمل بعد ثانية واحدة، بغض النظر عن عدد طلبات صدى ICMPv1 أو ردود الارتداد التي تم إرسالها أو تلقيها.
شيء آخر يجب الانتباه إليه هو (DUP!) الإخراج على الإجابات الثانية واللاحقة. يتم تعريف هذه الحزم على أنها استجابات مكررة لأنها تحتوي على نفس قيمة تسلسل ICMP مثل طلبات صدى ICMPv6 الفردية التي تم إرسالها في المقام الأول. وهي تظهر لأن طلب صدى البث المتعدد لـ ICMPv6 يؤدي إلى استجابات فردية متعددة للبث الأحادي. ويشار أيضًا إلى عدد التكرارات في ملخص الإحصائيات.
تعريف الواجهات - معرف المنطقة
هناك طريقة أخرى لعرض واجهة للاستخدام وهي كجزء من معلمة عنوان IPv6.
يمكننا أن نرى مثالاً على ذلك في مخرجات ping، حيث تحتوي عناوين مضيفي 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 مختلفة متصلة بنفس القناة. هذه الواجهات أعضاء في نفس المنطقة.
يجب أن يكون من الممكن تجميع واجهات متعددة داخل منطقة واحدة ضمن نظام التشغيل؛ لا أعرف حاليًا ما إذا كان هذا ممكنًا في نظام Linux أو كيفية القيام بذلك.
باستخدام اللاحقة %<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 استجابات فريدة.
جاءت هذه الاستجابات من عناوين مضيف 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 [RFC4291]، "بنية العنونة للإصدار 6 من IP". والسبب في ذلك هو أن عقدة IPv6 تحتوي دائمًا تلقائيًا على عنوان IPv6 أحادي البث، والذي يمكنها استخدامه على الأقل للتواصل مع العقد الأخرى على روابطها المتصلة مباشرة. يتضمن ذلك التواصل مع التطبيقات الموجودة على المضيفين الآخرين عبر عناوين مضيف Link-Local.
وهذا يبسط تصميم وتنفيذ البروتوكولات مثل IPv6 Neighbor Discovery وOSPFv3. كما يسمح أيضًا لتطبيقات المستخدم النهائي على الأجهزة المضيفة بالتواصل عبر القناة دون الحاجة إلى أي بنية أساسية أخرى داعمة لـ IPv6 على القناة. لا يتطلب الاتصال المباشر بين مضيفي IPv6 المتصلين وجود جهاز توجيه IPv6 أو خادم DHCPv6 على الاتصال.
تبدأ عناوين الارتباط المحلي ببادئة 10 بت fe80، متبوعًا بـ 54 بت صفر ثم معرف واجهة 64 بت (IID). في الرد الأول أعلاه 2392:6213:a15b:66ff هو معرف 64 بت.
حلقات البث المتعدد
افتراضيًا، يتم إرجاع حزم البث المتعدد داخليًا إلى العقدة التي أرسلتها. يحدث هذا لكل من عناوين IPv6 وIPv4.
سبب هذا السلوك الافتراضي هو أنه عند إرسال حزم البث المتعدد، قد يكون هناك أيضًا تطبيق بث متعدد محلي للاستماع يعمل على المضيف المرسل نفسه، وكذلك في مكان ما على الشبكة. يجب أن يتلقى هذا التطبيق المحلي أيضًا حزم البث المتعدد.
يمكننا أن نرى هذه الحلقة المحلية متعددة البث في مخرجات 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!)
...الاستجابة الأولى والأسرع (0,106 مللي ثانية مقارنة بـ 0,453 مللي ثانية) تأتي من عنوان 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. إذا أرسلنا اختبار اتصال متعدد البث لجميع العقد باستخدام هذه العلامة، فستقتصر الاستجابات على العقد البعيدة. لا نتلقى ردًا من عنوان Link-Local لواجهة الإرسال.
[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 Link-العناوين المحلية
كما قد تتخيل، فإن عناوين Link-Local أحادية البث في حد ذاتها لا توفر أيضًا معلومات كافية للإشارة إلى الواجهة التي سيتم استخدامها للوصول إليها. كما هو الحال مع اختبار ping للبث المتعدد لجميع العقد، نحتاج أيضًا إلى تحديد الواجهة كمعلمة لسطر الأوامر ping أو معرف المنطقة مع العنوان عند اختبار اتصال عناوين الارتباط المحلية.
هذه المرة يمكننا استخدامها -cللحد من عدد الحزم والاستجابات المرسلة والمستلمة ping، نظرًا لأننا نقوم بإجراء اختبار 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>، نظرًا لأن عناوين Link-Local نفسها لا توفر أيضًا معلومات حول الواجهة الصادرة.
فماذا عن اختبار اتصال جميع العقد الأخرى والحصول على عناوين البث الأحادي العالمية الخاصة بها (GUAs) (أي عناوينها العامة على الإنترنت) أو عناوين البث الأحادي المحلية الفريدة الخاصة بها (ULAs)؟ سننظر في هذا في منشور المدونة التالي.
هذا كل شئ
يمكنك معرفة المزيد عن دورتنا في.
المصدر: www.habr.com