SSM عبر OpenVPN: تتبع مصدر واحد ومجموعة حتى النهاية
تتبع تدفقًا واحدًا للبث المتعدد الخاص بالمصدر عبر عضوية المستقبل واختيار RPF ونموذج تسليم النفق، قبل إلقاء اللوم على الـ VPN.
اختر تدفقًا واحدًا ومستقبلًا واحدًا، ثم تتبع ذلك الزوج عبر كل قفزة بدلًا من اختبار البث المتعدد كفئة. يفشل التصميم الخاص بالمصدر في واحد بالضبط من أربعة مواضع: لم ينضم المستقبل أبدًا، أو رفض الموجه الحزمة على مسارها العكسي، أو ليست للنواة أي حالة، أو لم يسلم النفق أي نسخة. العمل بهذا الترتيب يكلف دقائق لكل قفزة ويخبرك أي الأربعة لديك فعلًا.
ثبت المصدر والمجموعة والمستقبل أولًا
اكتب ثلاث قيم قبل لمس أي جهاز: عنوان المصدر الذي سيرسل، وعنوان المجموعة التي سينضم إليها المستقبل، والشبكة الفرعية التي يقيم عليها المستقبل. لتدفق IPv4 توضيحي، فإن مصدرًا مثل 10.50.0.10 ومجموعة مثل 232.20.30.40 هو نوع الزوج الذي يناسب تصميمًا خاصًا بالمصدر. أي شيء أغموض من تلك القيم الثلاث لا يمكن اختباره.
النطاق 232/8 محجوز للبث المتعدد الخاص بالمصدر، والنموذج موصوف في RFC 4607. إذا كانت مجموعتك خارج ذلك النطاق بينما تعتقد أنك تشغل SSM، فتوقف وتأكد مما يقصده النشر فعلًا، لأن انضمام المستقبل وقرار التمرير لدى الموجه يعتمدان على اتساق النموذج.
تحقق من أن المستقبل انضم إلى المصدر
تقرير عضوية للمجموعة وحدها ليس انضمامًا خاصًا بالمصدر. اسأل المستقبل عن المصدر الذي طلبه، وانظر في موجه القفزة الأولى إلى حالة المجموعة لترى هل تظهر قائمة مصادر. إذا لم يحمل التقرير أي مصدر، فسيتعامل معه الموجه كانضمام من أي مصدر، وسيتدهور التصميم كله بصمت إلى شيء لم تخطط له.
على مستقبل Linux، تحقق مما اشترك فيه المقبس فعليًا ومما سجلته النواة. ملف إعداد التطبيق ليس دليلًا؛ جدول العضوية هو الدليل. اقرأه بينما يعمل المستقبل فعلًا، لأن المدخل قد يبقى لفترة قصيرة بعد خروج العملية التي أنشأته. المدخل القديم من اختبار سابق مصدر موثوق للثقة الزائفة.
ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'
إذا كان الانضمام موجودًا بالمصدر المتوقع، فانتقل إلى الموجهات. وإذا كان غائبًا، فلن يساعد أي قدر من إعداد النفق، لأنه لا يوجد شيء لتمريره.
تحقق من المسار العكسي قبل أن تنظر إلى النفق
يجري توجيه البث المتعدد فحصًا للمسار العكسي، وتُسقط الحزمة التي تصل على واجهة غير التي يشير إليها المسار أحادي البث. هذا هو السبب الأكثر شيوعًا لعدم وصول تدفق يُرسل بوضوح إلى القفزة التالية، وهو لا ينتج أي خطأ مفيد على مستوى التطبيق.
على الموجه المواجه للمصدر، قارن المسار نحو المصدر بالواجهة التي تصل عليها الحزم فعلًا. وعلى الموجه المواجه للمستقبل، افعل الشيء نفسه للشبكة الفرعية الخاصة بالمستقبل وتأكد من أن قائمة الواجهات الصادرة تتضمن الوصلة نحوه. أي عدم تطابق في أي اتجاه هو فشل RPF، لا فشل عضوية.
ثم تأكد من أن TTL الخاص بالمصدر كبير بما يكفي للبقاء عبر القفزات الموجهة التي صممتها. التدفق الذي يعمل على الموجه الأول ويموت عند الثاني هو في الغالب مسألة TTL لا مسألة سياسة.
اقرأ حالة البث المتعدد في النواة بدلًا من الإعداد
الإعداد يخبرك بما طلبته؛ والنواة تخبرك بما يحدث. على كل قفزة Linux، اقرأ مدخلات توجيه البث المتعدد وتأكد من وجود قائمة واجهات داخلة وصادرة للزوج الدقيق من المصدر والمجموعة. المدخل الخاص بالمجموعة مع مصدر بديل عام كائن مختلف، ولن يفسر تدفقًا خاصًا بالمصدر.
ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10
تحتفظ عفاريت التوجيه برأيها الخاص فوق تلك الحالة، والأمر الذي يطبعها يعتمد على التنفيذ المثبت. المبدأ ثابت: اسأل العفريت عن مدخله الأعلى للزوج، ثم اسأل النواة هل يوجد مدخل تمرير. العفريت الذي يظن أنه يمرر بينما النواة بلا مدخل هو مشكلة نطاق إعداد على ذلك المضيف.
حين يختلف الاثنان، أصلح المضيف لا الـ VPN. لا شيء في المصب يمكنه تعويض قفزة لا تمرر التدفق الذي سألت عنه. سجل الزوج والواجهة الداخلة والقائمة الصادرة لكل قفزة بينما يعمل التدفق. ذلك السجل يحول الفشل التالي إلى مقارنة بدل تحقيق جديد.
قرر كيف ينسخ النفق فعلًا
هنا يتوقف البث المتعدد عبر VPN عن كونه روتينيًا. نفق نقطة إلى نقطة يسلم الحزمة إلى النظير الوحيد في الطرف الآخر، فتصل النسخة إلى عميل واحد بالضبط. المقطع الجسري يتصرف أشبه بوصلة مشتركة، لأن النفق يحمل الإطار والجسر يقرر ما يغمره. هذان نموذجا تسليم مختلفان، والتصميم الذي يفترض الثاني بينما يشغل الأول سيبدو ناجحًا لمستقبل ويفشل مع التالي.
لأكثر من مستقبل عبر خادم متعدد النقاط، يجب تصميم النسخ صراحة. تثبيت مسار بث متعدد على البوابة لا يعلم خادم VPN أي النظائر يجب أن تتلقى نسخة، ولا مسار على جانب العميل يتخذ ذلك القرار بدلًا عنه. حيث يكون الشرط كثيرًا من المستقبلين، استخدم نسخًا مدعومًا أو بديلًا مختارًا عن قصد، واكتب أيهما اخترت.
أخيرًا، تحقق عند المستقبل بمراقبة ضيقة: المصدر والمجموعة والمنفذ الدقيق، على الواجهة التي تتوقعها، بينما يكون مستقبل واحد مخول منضمًا. تختار SSM مرسلًا، والاختيار ليس مصادقة على ذلك المرسل، ولا إذنًا لمرور بث متعدد آخر عبر السياسة نفسها.