OpenVPN मा SSM: एउटा स्रोत र समूहलाई सुरुदेखि अन्त्यसम्म पछ्याउने

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

पहिले स्रोत, समूह र प्राप्तकर्ता निश्चित गर्नुहोस्

कुनै पनि यन्त्र छुनुअघि तीन मान लेख्नुहोस्: पठाउने स्रोत ठेगाना, प्राप्तकर्ता सामेल हुने समूह ठेगाना र प्राप्तकर्ता रहने सबनेट। एउटा उदाहरण IPv4 स्ट्रिमका लागि, 10.50.0.10 स्रोत र 232.20.30.40 समूह स्रोत-विशेष डिजाइनमा मिल्ने जोडी हो। ती तीन मानभन्दा अस्पष्ट कुरा परीक्षण गर्न सकिँदैन।

232/8 दायरा स्रोत-विशेष multicast का लागि आरक्षित छ, र मोडेल RFC 4607 मा वर्णन गरिएको छ। तपाईं SSM चलाइरहेको विश्वास गर्दा तपाईंको समूह त्यो दायराबाहिर छ भने, रोक्नुहोस् र तैनातीले साँच्चै के चाहेको हो त्यो पुष्टि गर्नुहोस्, किनकि प्राप्तकर्ताको सामेल हुने क्रम र राउटरको फर्वार्डिङ निर्णय दुवै मोडेल सुसंगत हुनमा निर्भर छन्।

प्राप्तकर्ता स्रोतमा सामेल भएको छ कि जाँच्नुहोस्

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

Linux प्राप्तकर्तामा, सकेटले साँच्चै केको सदस्यता लियो र कर्नेलले के अभिलेख गर्यो जाँच्नुहोस्। अनुप्रयोगको कन्फिगरेसन फाइल प्रमाण होइन; सदस्यता तालिका प्रमाण हो। प्राप्तकर्ता साँच्चै चलिरहेको बेला पढ्नुहोस्, किनकि यो सिर्जना गर्ने प्रक्रिया बाहिरिएपछि पनि प्रविष्टि थोरै समय रहन सक्छ। अघिल्लो परीक्षणको पुरानो प्रविष्टि झुटो आत्मविश्वासको भरपर्दो स्रोत हो।

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

अपेक्षित स्रोतसँग सामेल हुनु उपस्थित छ भने, राउटरतिर जानुहोस्। छैन भने, कुनै पनि टनेल कन्फिगरेसनले सहयोग गर्दैन, किनकि फर्वार्ड गर्न केही छैन।

टनेल हेर्नुअघि फर्कने बाटो प्रमाणित गर्नुहोस्

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

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

त्यसपछि स्रोतको TTL तपाईंले डिजाइन गरेका रुट गरिएका हपहरू पार गर्न पर्याप्त ठूलो छ भनी पुष्टि गर्नुहोस्। पहिलो राउटरमा चल्ने र दोस्रोमा मर्ने स्ट्रिम प्रायः TTL प्रश्न हो, नीति प्रश्न होइन।

कन्फिगरेसनको सट्टा कर्नेलको multicast अवस्था पढ्नुहोस्

कन्फिगरेसनले तपाईंले के माग्नुभयो भन्छ; कर्नेलले के भइरहेको छ भन्छ। हरेक Linux हपमा, multicast रुटिङ प्रविष्टिहरू पढ्नुहोस् र स्रोत र समूहको ठ्याक्कै जोडीका लागि आउने र जाने इन्टरफेसको सूची अवस्थित छ भनी पुष्टि गर्नुहोस्। वाइल्डकार्ड स्रोत भएको समूहको प्रविष्टि अर्को वस्तु हो, र यसले स्रोत-विशेष प्रवाह व्याख्या गर्दैन।

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

रुटिङ डेमनहरूले त्यो अवस्थामाथि आफ्नै दृष्टिकोण राख्छन्, र यसलाई छाप्ने आदेश कुन कार्यान्वयन स्थापित छ भन्नेमा निर्भर छ। सिद्धान्त स्थिर छ: डेमनलाई जोडीका लागि यसको अपस्ट्रिम प्रविष्टि सोध्नुहोस्, त्यसपछि कर्नेललाई फर्वार्डिङ प्रविष्टि छ कि सोध्नुहोस्। कर्नेलसँग प्रविष्टि नहुँदा आफू फर्वार्ड गरिरहेको ठान्ने डेमन त्यो होस्टमा कन्फिगरेसन दायराको समस्या हो।

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

टनेलले साँच्चै कसरी प्रतिलिपि बनाउँछ भन्ने निर्णय गर्नुहोस्

यहीँ VPN माथिको multicast नियमित काम हुन छोड्छ। पोइन्ट-टु-पोइन्ट टनेलले प्याकेटलाई अर्को छेउको एउटै पियरसम्म पुर्याउँछ, त्यसैले प्रतिलिपि ठ्याक्कै एउटा क्लाइन्टसम्म पुग्छ। ब्रिज गरिएको खण्ड साझा लिंकजस्तै बढी व्यवहार गर्छ, किनकि टनेलले फ्रेम बोक्छ र ब्रिजले के बाढी लगाउने निर्णय गर्छ। यी फरक डेलिभरी मोडेल हुन्, र दोस्रोलाई मानेर पहिलो चलाउने डिजाइन एउटा प्राप्तकर्ताका लागि चल्ने देखिन्छ र अर्कोका लागि असफल हुन्छ।

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

अन्तमा, प्राप्तकर्तामा साँघुरो अवलोकनअन्तर्गत जाँच्नुहोस्: ठ्याक्कै स्रोत, समूह र पोर्ट, तपाईंले अपेक्षा गरेको इन्टरफेसमा, एक अधिकृत प्राप्तकर्ता सामेल हुँदा। SSM ले प्रेषक छान्छ, र छनोट त्यो प्रेषकको प्रमाणीकरण होइन, अरू multicast ट्राफिकले त्यही नीति पार गर्ने अनुमति पनि होइन।