मल्टीकास्ट बिना योजना के VPN क्यों नहीं पार करता

दो साइटें यूनिकास्ट से एक-दूसरे तक पूरी तरह पहुँच सकती हैं और फिर भी ऐसे व्यवहार कर सकती हैं जैसे उनमें से एक प्रिंटर की खोज घोषणा, IPTV स्ट्रीम या क्लस्टर की हृदयगति नहीं देख पा रही हो। यह टूटी हुई टनल नहीं है; यह गंतव्य और समूह के बीच का अंतर है। मल्टीकास्ट वितरण के लिए सदस्यता मॉडल, मार्ग पर फ़ॉरवर्डिंग स्थिति और ट्रैफ़िक ढोने को तैयार इंटरफ़ेस चाहिए, और इनमें से कोई भी यूनिकास्ट मार्ग से नहीं आता। ऐप्लिकेशन के समूह से एक काम करने वाले रिसीवर तक जाना उत्तर का सबसे छोटा रास्ता है।

समूह और ऐप्लिकेशन से शुरू करें

पूछें कि ऐप्लिकेशन कौन-सा समूह पता इस्तेमाल करता है और ट्रैफ़िक किसलिए है। सेवाओं की घोषणा करने वाला खोज प्रोटोकॉल, स्ट्रीमिंग फ़ीड और राउटिंग प्रोटोकॉल के हैलो पैकेट तीन अलग समस्याएँ हैं जिनके तीन अलग स्वीकार्य उत्तर हैं। समूह पता स्वयं दायरा बताता है: लोकल नेटवर्क नियंत्रण ब्लॉक के पते सामान्य राउटिंग द्वारा लिंक से बाहर फ़ॉरवर्ड करने के लिए नहीं हैं, और उन्हें इस्तेमाल करने वाले ऐप्लिकेशन आम तौर पर एक ही ब्रॉडकास्ट डोमेन मानते हैं। वैश्विक दायरे के समूह पर स्ट्रीमिंग फ़ीड उस खोज प्रोटोकॉल से अलग डिज़ाइन है जो अपेक्षा करता है कि हर डिवाइस हर क्वेरी सुने, और केवल दूसरा ही ब्रॉडकास्ट डोमेन के आकार की परवाह करता है।

तय करें कि आवश्यकता सेवा है या खोज तंत्र, क्योंकि इन दोनों उत्तरों में लागत का अंतर एक कोटि का है। एक न बदलने वाला पता माँगता है; दूसरा विस्तृत क्षेत्र लिंक पर फैला ब्रॉडकास्ट डोमेन माँगता है और उससे जो कुछ भी निकलता है।

लिंक-लोकल खोज को रुकना ही है

RFC 6762 में वर्णित मल्टीकास्ट DNS एक ही लिंक के इर्द-गिर्द बनाया गया है: क्वेरी एक निश्चित समूह तक जाती हैं, उत्तर उसी समूह को भेजे जाते हैं, और प्रोटोकॉल इस पर निर्भर है कि हर भागीदार सबको सुने। राउटर उस ट्रैफ़िक को डिफ़ॉल्ट रूप से फ़ॉरवर्ड नहीं करते, और यह भूल नहीं बल्कि डिज़ाइन निर्णय है। सीमा इसलिए है कि एक इमारत का डिवाइस दूसरी इमारत में सहजता से अपनी घोषणा न कर सके। जो टनल समूह को हर जगह ढोकर खोज सुधारती दिखती है, उसने वह सीमा हर ऐप्लिकेशन से हटा दी है, केवल उसी से नहीं जिसे मदद चाहिए थी।

रिपीटर और रिफ़्लेक्टर मौजूद हैं, और वे वास्तविक परिणामों वाली वास्तविक सेवाएँ हैं: एक साइट पर घोषित हर नाम दूसरी साइट पर दिखाई देने लगता है, जिनमें लोगों या उपकरणों की पहचान कराने वाले डिवाइस नाम भी शामिल हैं। यदि वास्तविक आवश्यकता यह है कि कोई विशिष्ट सेवा खोजी जा सके, तो 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 का एक नाम हर उस साइट से पहुँच योग्य है जिसे ज़रूरत है, जिन्हें ज़रूरत नहीं उन्हें कुछ भी घोषित नहीं करता, और डिवाइस के अलग पते वाले डिवाइस से बदलने पर भी काम करता रहता है।

जब किसी प्रोटोकॉल को सचमुच मल्टीकास्ट चाहिए, तो उसे समूह और ज़रूरत वाली साइटों तक सीमित करें, कारण दर्ज करें, और ऐप्लिकेशन बदलने पर निर्णय फिर देखें। खोज को हर जगह फैलाना एक बार आसान है, और एक साल तक चुपचाप उस पर निर्भर डिवाइसों के बाद उसे वापस लेना कठिन है।