OpenVPN मल्टिकास्ट प्रत्येक क्लायंटकडे पाठवते, सदस्यांकडे नाही

"मल्टिकास्टला समर्थन आहे" हे प्रोटोकॉलच्या प्रश्नाचे उत्तर देते आणि क्षमतेचा प्रश्न अस्पर्शित ठेवते। ऑपरेशनलदृष्ट्या महत्त्वाचे हे आहे की सर्व्हर एका ग्रुप पॅकेटसाठी किती प्रती पाठवतो आणि कोणती टनेल त्या वाहतात। स्ट्रीम घेणारे एक सदस्यत्व घेतलेले ॲप्लिकेशन फक्त हे सिद्ध करते की वितरण कुठेतरी चालते। ते हे सिद्ध करत नाही की उत्सुकता नसलेल्या क्लायंटना बँडविड्थ वाचली गेली।

एका वैशिष्ट्याच्या दाव्यातील तीन प्रश्न

ग्रुप सदस्यत्व विचारते की प्राप्तकर्ता ग्रुपमध्ये सामील झाला का। टनेल वितरण विचारते की पॅकेट टनेलमधून गेलेच का। प्रतिकृती धोरण विचारते की सर्व्हरने किती प्रती बनवल्या आणि कोणासाठी। विक्रेत्याचे विधान पहिल्यासाठी खरे आणि तिसऱ्याबद्दल गप्प असू शकते, आणि खर्च तिथेच असतो।

लिंकचा आकार ठरवताना ते वेगळे ठेवा। सर्व्हरच्या बाजूला बाहेर जाणाऱ्या बजेटचा निर्धार केवळ तिसरा प्रश्न करतो।

यूजरस्पेस सर्व्हर ग्रुप पॅकेटचे काय करतो

पारंपरिक OpenVPN 2.6 यूजरस्पेस सर्व्हरमध्ये, येणारे ब्रॉडकास्ट किंवा मल्टिकास्ट पॅकेट TUN/TAP इनपुट मार्गात वर्गीकृत होते आणि ग्रुपनिहाय शोधाऐवजी ब्रॉडकास्ट फॅन-आउट रुटीनकडे दिले जाते। ते रुटीन क्लायंट इन्स्टन्समधून जाते, प्रेषक आणि थांबवलेला कोणताही इन्स्टन्स वगळते, VLAN कॉन्फिगर केलेल्या ठिकाणी तपासणी लागू करते, आणि उर्वरित प्रत्येक क्लायंटसाठी एक प्रत रांगेत ठेवते। त्या लूपमधील कोणतेही पाऊल सदस्यत्व तक्त्याला विचारत नाही। ही ब्रॉडकास्ट शैलीची प्रतिकृती आहे, आणि संपूर्ण यंत्रणा इतकीच आहे।

हे त्या कोड मार्गाचे गुणधर्म माना, सार्वत्रिक नियम नाही। वेगवर्धित डेटा मार्ग, इतर अंमलबजावणी आणि वेगवेगळ्या आवृत्त्या वेगळे वागू शकतात, आणि यापैकी काहीही TAP ला आवश्यकता किंवा दुरुस्ती बनवत नाही।

काहीही मोजण्यापूर्वी प्रतींचे बजेट करा

पेलोड दर घ्या आणि पात्र क्लायंटच्या संख्येने गुणा। सेकंदाला एक मेगाबिट वीस क्लायंटना पाठवणारी स्ट्रीम सेकंदाला वीस मेगाबिट पेलोड निर्माण करते जे सर्व्हर सोडते, एन्कॅप्स्युलेशन, पुनःप्रेषण आणि प्रत्येक क्लायंटच्या कोणत्याही ओव्हरहेडपूर्वी। ते गणित बजेट आहे, तुमच्या तैनातीचे मापन नाही।

ip -s link show tun0

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

काउंटरमध्ये तुमचा स्वतःचा टनेल रहदारीही येते, म्हणून चाचणीची खिडकी लहान आणि होस्ट उर्वरित वेळ शांत ठेवा। अचूकतेपेक्षा परिमाणाचा क्रम महत्त्वाचा, आणि एक प्रत वीसपासून वेगळी करण्यासाठी एवढेच पुरते।

व्याप्तीचा प्रश्न निकाली काढणारी दोन क्लायंटची चाचणी

स्ट्रीम मिळायला हवी अशी एक क्लायंट आणि मिळायला नको अशी दुसरी जोडा। प्रेषक सुरू करा, नंतर त्याच अंतरासाठी दुसऱ्या क्लायंटचे टनेल काउंटर पहा। दुसऱ्या क्लायंटवर वाढ हा विस्तृत प्रतिकृतीचा थेट पुरावा आहे, वैशिष्ट्यांची यादी काहीही म्हणो।

कॅप्चर ग्रुप पत्त्यावर फिल्टर करा जेणेकरून असंबंधित रहदारी वाचणार नाही, आणि ते टनेल इंटरफेसपुरते मर्यादित ठेवा। व्यस्त होस्टवर भौतिक इंटरफेस कॅप्चर केल्यास कोणालाही समजणार नाही अशी फाइल तयार होते आणि तुम्ही गोळा करण्याचा विचार न केलेला वापरकर्ता डेटा टिकून राहू शकतो।

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

मर्यादा काढून टाकण्याऐवजी मर्यादित डिझाइन निवडणे

फॅन-आउट खूप रुंद असेल तर उपाय म्हणजे समर्थित मर्यादित वितरण व्यवस्था, तुमची सर्व नियंत्रणे पुसून टाकणे नाही। पर्यायांमध्ये वितरण बिंदू प्राप्तकर्त्यांच्या जवळ आणणे, ग्रुपसोबत स्रोताची ओळखही वाहणारे स्रोत-विशिष्ट सदस्यत्व मॉडेल वापरणे, किंवा स्ट्रीम विभागणे यांचा समावेश आहे, जेणेकरून उत्सुकता नसलेली साइट्स कधीही एकाच वितरण सीमेवर बसणार नाहीत।

स्रोत आणि ग्रुपची ओळख गंतव्य मल्टिकास्ट आहे या नुसत्या तथ्यापासून वेगळी ठेवा। ग्रुप ओळखणारा पण स्रोत न ओळखणारा प्राप्तकर्ता विशिष्ट चॅनेल मागणाऱ्या सदस्यापेक्षा वेगळा सदस्य आहे। दोन्ही मिसळल्यास नंतरचे क्षमता नियोजन अंदाज बनते।

स्रोत-विशिष्ट मल्टिकास्ट चॅनेल मॉडेल हा त्या फरकाचा संदर्भ आहे। कोणतेही डिझाइन निवडा, पात्र सहकाऱ्यांचा संच, प्रतिकृतीचा मालक आणि पुढच्या वेळी वाचायचा काउंटर लिहून ठेवा; तेच नोंद बँडविड्थच्या आश्चर्याचे ज्ञात खर्चात रूपांतर करते।