لماذا لا يعبر البث المتعدد شبكة VPN من دون خطة

قد يتصل موقعان ببعضهما اتصالا تاما عبر البث الأحادي، ومع ذلك يتصرفان كأن أحدهما لا يرى إعلان الاكتشاف الخاص بالطابعة، أو بث IPTV، أو نبضة مجموعة الخوادم. هذا ليس نفقا معطلا؛ إنه الفرق بين وجهة ومجموعة. يحتاج تسليم البث المتعدد إلى نموذج عضوية، وحالة تمرير على طول المسار، وواجهة مستعدة لحمل الحركة، ولا يأتي أي منها من مسار بث أحادي. والانتقال من مجموعة التطبيق إلى مستقبل واحد يعمل هو أقصر طريق إلى جواب.

ابدأ بالمجموعة والتطبيق

اسأل عن عنوان المجموعة الذي يستخدمه التطبيق وعن الغرض من الحركة. بروتوكول اكتشاف يعلن الخدمات، وتدفق بث، وحزم الترحيب الخاصة ببروتوكول توجيه: هذه ثلاث مشكلات مختلفة لها ثلاثة أجوبة مقبولة مختلفة. عنوان المجموعة نفسه يخبرك بالنطاق: العناوين في كتلة التحكم بالشبكة المحلية ليس المقصود أن تمرر خارج الرابط عبر التوجيه العادي، والتطبيقات التي تستخدمها تفترض عادة نطاق بث واحدا. وتدفق البث على مجموعة ذات نطاق عالمي تصميم مختلف عن بروتوكول اكتشاف يتوقع أن يسمع كل جهاز كل استعلام، والثاني وحده يهتم بحجم نطاق البث.

قرر ما إذا كان المطلب هو الخدمة أم آلية الاكتشاف، لأن الجوابين يختلفان في الكلفة بفارق رتبة مقدار. أحدهما يطلب عنوانا لا يتغير؛ والآخر يطلب نطاق بث ممتدا عبر رابط شبكة واسعة مع كل ما يترتب على ذلك.

اكتشاف الرابط المحلي يفترض أن يتوقف

إن DNS المتعدد كما هو موصوف في RFC 6762 مصمم حول رابط واحد: تذهب الاستعلامات إلى مجموعة ثابتة، وترسل الاستجابات إلى المجموعة نفسها، ويعتمد البروتوكول على أن يسمع كل مشارك الجميع. ولا تمرر الموجهات تلك الحركة افتراضيا، وهذا قرار تصميم لا سهو. والحد موجود كي لا يعلن جهاز في مبنى نفسه عرضا داخل مبنى آخر. والنفق الذي يبدو أنه يصلح الاكتشاف بحمل المجموعة في كل مكان قد أزال ذلك الحد عن كل تطبيق، لا عن التطبيق الذي احتاج المساعدة فقط.

المكررات والعواكس موجودة، وهي خدمات حقيقية لها نتائج حقيقية: كل اسم يعلن في موقع يصبح ظاهرا في الموقع الآخر، بما في ذلك أسماء الأجهزة التي تحدد أشخاصا أو معدات. وإذا كان المطلب الفعلي هو أن تكون خدمة معينة قابلة للعثور عليها، فإن سجل خدمة منشورا في DNS هو عادة التغيير الأصغر، وهو يكشف اسما واحدا بدلا من سيل منها.

ثلاثة أشياء يحتاجها البث المتعدد الموجه

البث المتعدد الموجه يحتاج ثلاثة أشياء تعمل معا: مستقبلات تنضم إلى المجموعة، وموجهات تحتفظ بحالة تمرير لها، ونفق يتعامل مع عناوين المجموعة كحركة يحملها. النفق الذي تنص سياسته على الشبكات الفرعية أحادية البث فقط سيسقط حركة المجموعة عند حد التشفير، ولهذا تكون العارض الأول غالبا صمتا لا خطأ. أما الواجهة القائمة على التوجيه، مثل نفق GRE أو VTI، فتحمل ما ترسله جدول التوجيه إليها، وهذا يجعل المجموعة قابلة للوصول بمجرد وجود حالة البث المتعدد.

إمكانية الوصول إلى المصدر هي النصف الثاني. تبني بروتوكولات توجيه البث المتعدد مثل PIM أشجار التوزيع بالتحقق من أن المسار عائدا إلى المصدر هو المسار المتوقع، لذلك يكسر مسار البث الأحادي الذي يشير إلى مكان آخر الشجرة حتى عندما تكون عضوية المجموعة صحيحة. وتثبيت مسار للمستقبل لا يفعل شيئا لذلك التحقق، وهذا هو الخطأ الذي ينتج بينغ ناجحا وبثا فاشلا. تحقق أولا من مسار العودة إلى المصدر، ثم أضف العضوية، وبعد ذلك فقط انظر إلى التطبيق.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

يعرض السطران الأولان ما انضم إليه المضيف وما يمرره النواة، ويعرض الثالث عضوية التطبيق نفسه، ويعرض الأخير مسار البث الأحادي الذي سيستخدمه فحص المسار العكسي. وقراءتها معا تميز تطبيقا لم ينضم قط من شبكة لم تمرر قط.

أثبته بمصدر واحد ومستقبل واحد

قبل أن تلمس أي إعداد، تأكد من أن التطبيق يعمل على مقطع واحد. فإن فشل محليا، فليس توجيه البث المتعدد هو المشكلة ولن يساعد أي تغيير في النفق. ثم أعد التجربة بمستقبل واحد عبر النفق وراقب الحزم على جانبي حد التشفير.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

الحزم الظاهرة داخل النفق والغائبة خارجه تشير إلى التغليف أو السياسة؛ والحزم الظاهرة على الجانبين مع عدم تقدم التطبيق تشير إلى عضوية المستقبل أو ارتباط التطبيق. أبق عمليات الالتقاط قصيرة ومفلترة، لأن التقاط بث متعدد واسع على مقطع مزدحم ليس إلا ضجيجا في معظمه.

فضل عنوان خدمة عندما تحتاج الخدمة فقط

الاكتشاف موجود للعثور على شيء يتحرك. والخادم ذو الاسم الثابت لا يحتاج إلى اكتشاف، وعنوان موثق في DNS خاص يجيب عن سؤال المستخدم الحقيقي دون تمديد نطاق بث عبر رابط شبكة واسعة. والمنطق نفسه ينطبق على الطابعات والأجهزة والخدمات الشبكية الداخلية. والاسم في DNS يمكن الوصول إليه من كل موقع يحتاجه دون أن يعلن شيئا للمواقع التي لا تحتاجه، ويظل يعمل عندما يستبدل الجهاز بجهاز له عنوان مختلف.

حين يتطلب بروتوكول ما البث المتعدد حقا، احصره في المجموعة والمواقع التي تحتاجه، ووثق السبب، وأعد النظر في القرار عندما يتغير التطبيق. وتوسيع الاكتشاف في كل مكان سهل مرة واحدة، وصعب التراجع عنه بعد سنة من الأجهزة التي تعتمد عليه بهدوء.