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

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