योजनेशिवाय मल्टिकास्ट 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 मधील नाव ज्यांना गरज आहे अशा प्रत्येक साइटवरून पोहोचण्यायोग्य आहे आणि ज्यांना गरज नाही त्यांना काहीही घोषित करत नाही, आणि उपकरण वेगळ्या पत्त्याच्या उपकरणाने बदलले तरी काम करत राहते।

प्रोटोकॉलला खरोखर मल्टिकास्ट हवा असेल तर तो गट आणि गरज असलेल्या साइट्सपर्यंत मर्यादित करा, का ते नोंदवा, आणि अनुप्रयोग बदलल्यावर निर्णय पुन्हा तपासा। शोध सर्वत्र पसरवणे एकदा सोपे आहे, आणि वर्षभर शांतपणे त्यावर अवलंबून असलेल्या उपकरणांनंतर तो मागे घेणे कठीण आहे।