OpenVPN पर SSM: एक स्रोत और समूह को शुरू से अंत तक ट्रैक करना

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

पहले स्रोत, समूह और प्राप्तकर्ता तय करें

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