OpenVPN /24 में क्लायंट अपेक्षा से जल्दी क्यों खत्म हो जाते हैं

/24 पर बने पूल जब साठ के आसपास क्लायंट लेना बंद कर देते हैं, तब वे डिज़ाइन के अनुसार ही व्यवहार कर रहे होते हैं, किसी लाइसेंस सीमा से नहीं टकराते। net30 में हर क्लायंट को एक वर्चुअल पॉइंट-टू-पॉइंट लिंक दिया जाता है जो चार पते खर्च करता है, इसलिए 256 पतों का एक सबनेट प्रीफ़िक्स जो संकेत देता है उसका लगभग एक चौथाई सँभालता है। मायने रखने वाली संख्या आवंटन है, पते नहीं। प्रीफ़िक्स को क्लायंट संख्या के रूप में पढ़ना वह गलती है जो छिपी हुई उपयोगकर्ता सीमा की खोज पैदा करती है।

दो टोपोलॉजी, दो गणितीय मॉडल, और उनमें से केवल एक ही उस प्रीफ़िक्स से मेल खाता है जो लोग मानते हैं।

net30 प्रति क्लायंट चार पते खर्च करता है

net30 प्रति क्लायंट एक /30 ब्लॉक आवंटित करता है, क्योंकि हर सत्र को दोनों सिरों पर पते वाला पॉइंट-टू-पॉइंट लिंक मानकर मॉडल किया जाता है। उस ब्लॉक में चार पते जाते हैं और दो उपयोगी होते हैं, इसलिए प्रभावी क्लायंट संख्या सबनेट का एक चौथाई है। /24 पर यह सर्वर के अपने ब्लॉक और किसी भी स्थिर आवंटन के बाहर निकलने से पहले 64 ब्लॉक छोड़ता है। 63 के आसपास बताई गई सीमा झलकती हुई गणित है, कोई कॉन्फ़िगर किया गया अधिकतम नहीं।

सर्वर को भी अपना आवंटन चाहिए, और स्थिर क्लायंट प्रविष्टियाँ वे क्लायंट जुड़ें या न जुड़ें, ब्लॉक खर्च करती हैं। दोनों उस प्रीफ़िक्स को बदले बिना गतिशील सीमा घटाते हैं जिससे आपने शुरू किया था।

पूल की सीमाएँ प्रीफ़िक्स से ज़्यादा मायने रखती हैं

सर्वर निर्देश उस सबनेट से संकरा पूल परिभाषित कर सकता है जिसका वह नाम लेता है, और कोई सहायक स्क्रिप्ट उन अतिरिक्त सेटिंग्स तक फैल सकती है जो आपकी खोली प्रोफ़ाइल में दिखाई नहीं देतीं। client-config डायरेक्टरी से स्थिर पते उसी सीमा के भीतर रहते हैं और दो बार नहीं दिए जा सकते। प्रीफ़िक्स अधिकतम संभव जगह बताता है; प्रभावी पूल वही है जो चल रहा कॉन्फ़िगरेशन वास्तव में देता है।

क्षमता के बारे में कुछ भी निष्कर्ष निकालने से पहले दोनों की तुलना करें, क्योंकि छोटी कॉन्फ़िगर की गई सीमा उतनी ही अच्छी तरह सीमा को समझाती है जितनी टोपोलॉजी।

वह सीमा खोजें जिसने वास्तव में क्लायंट को इंकार किया

पहले टोपोलॉजी और प्रभावी पूल पढ़ें, फिर स्थिर आवंटन और आरक्षित पतों का हिसाब करें। यह भी देखें max-clients और OpenVPN के बाहर का कोई भी प्रवेश नियंत्रण, पता स्थान को दोष देने से पहले। अंत में, इंकार के क्षण में सर्वर का अपना संदेश उन उम्मीदवारों से मिलाएँ। संदेश बाधा का नाम लेता है; संख्या केवल क्षेत्र सँकरा करती है।

एक साथ होने की त्रुटि के साथ आने वाला इंकार और आवंटन त्रुटि के साथ आने वाला इंकार अलग-अलग सुधार माँगते हैं, और उनके बीच अनुमान लगाना रखरखाव की खिड़की बर्बाद करता है।

टोपोलॉजी बदलने से पता योजना बदलती है

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

यह बदलाव पुराने कॉन्फ़िगरेशन का पर्याय नहीं है। इसे अपनी समीक्षा वाला पता-योजना परिवर्तन मानें, और उम्मीद करें कि कम से कम एक क्लायंट पिछली योजना का पता रखेगा।

पूल का आकार योजना से लें, मास्क से नहीं

आकार एक साथ जुड़ने वाले क्लायंट की संख्या में फिर से जुड़ने और परीक्षण के लिए जगह जोड़कर चुनें, फिर चुनी गई टोपोलॉजी के तहत उसे ढकने वाला सबसे छोटा प्रीफ़िक्स लें। साठ क्लायंट की सीमा हल करने के लिए /16 तक चौड़ा करना क्षमता की समस्या को रूटिंग और ओवरलैप की समस्या से बदल देता है, क्योंकि बड़ी निजी सीमा का क्लायंट की पहले से पहुँच वाली किसी चीज़ से टकराने का ज़्यादा खतरा होता है।

टोपोलॉजी, पूल, स्थिर आवंटन और उससे बनने वाली क्लायंट सीमा को साथ में दस्तावेज़ करें। अगला क्षमता प्रश्न तब जाँच के बजाय गणित होगा।