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

दुई टोपोलोजी, दुई अंकगणितीय मोडेल, र तीमध्ये एउटा मात्र मानिसहरूले अनुमान गर्ने प्रिफिक्ससँग मिल्छ।

net30 प्रत्येक क्लाइन्टका लागि चार ठेगाना खर्च गर्छ

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

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

पूलका सीमाना प्रिफिक्सभन्दा बढी महत्त्वपूर्ण छन्

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

क्षमताबारे केही निष्कर्ष निकाल्नुअघि दुवैको तुलना गर्नुहोस्, किनकि सानो कन्फिगर गरिएको दायराले टोपोलोजीले जत्तिकै राम्ररी सीमा व्याख्या गर्छ।

क्लाइन्टलाई वास्तवमै अस्वीकार गर्ने सीमा पत्ता लगाउनुहोस्

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

एकै समयको त्रुटिसँग आउने अस्वीकृति र बाँडफाँट त्रुटिसँग आउने अस्वीकृतिका समाधान फरक हुन्छन्, र तीबीच अनुमान गर्दा मर्मत समय खेर जान्छ।

टोपोलोजी बदल्दा ठेगाना योजना बदलिन्छ

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

परिवर्तन पुरानो कन्फिगरेसनको समानार्थी होइन। यसलाई आफ्नै समीक्षासहितको ठेगाना योजना परिवर्तनका रूपमा लिनुहोस्, र कम्तीमा एउटा क्लाइन्टले अघिल्लो योजनाको ठेगाना राख्ने अपेक्षा गर्नुहोस्।

पूलको आकार मास्कबाट होइन, योजनाबाट निर्धारण गर्नुहोस्

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

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

सम्बन्धित लेखहरू