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 प्रेषक निवडते, आणि निवड त्या प्रेषकाचे प्रमाणीकरण नाही, किंवा इतर मल्टिकास्ट रहदारीला तेच धोरण ओलांडण्याची परवानगी नाही।