OpenVPN चे /24 अपेक्षेपेक्षा लवकर क्लायंट संपवण्याचे कारण

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

दोन टोपोलॉजी, दोन अंकगणितीय प्रतिकृती, आणि त्यापैकी फक्त एक लोक गृहीत धरतात त्या उपसर्गाशी जुळते।

net30 प्रत्येक क्लायंटसाठी चार पत्ते खर्च करते

net30 प्रत्येक क्लायंटला /30 ब्लॉक वाटप करते, कारण प्रत्येक सत्र दोन्ही टोकांना पत्ता असलेला बिंदू-ते-बिंदू दुवा म्हणून प्रतिमाणित केले जाते। त्या ब्लॉकमध्ये चार पत्ते जातात आणि दोन वापरण्यायोग्य असतात, म्हणून प्रभावी क्लायंट संख्या सबनेटच्या एक चतुर्थांश आहे। /24 वर सर्व्हरचा स्वतःचा ब्लॉक आणि कोणतेही स्थिर वाटप बाहेर येण्यापूर्वी 64 ब्लॉक शिल्लक राहतात। 63 च्या आसपास नोंदवली जाणारी वरची मर्यादा संरचित कमाल नसून दिसून येणारे अंकगणित आहे।

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

उपसर्गापेक्षा पूलच्या सीमा अधिक महत्त्वाच्या

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

क्षमतेबद्दल काहीही ठरवण्यापूर्वी दोन्हींची तुलना करा, कारण लहान संरचित श्रेणी टोपोलॉजीइतकीच वरची मर्यादा स्पष्ट करते।

क्लायंटला प्रत्यक्षात नकार देणारी मर्यादा शोधा

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

एकाचवेळेच्या त्रुटीसह येणारा नकार आणि वाटप त्रुटीसह येणारा नकार यांचे उपाय वेगळे असतात, आणि त्यांच्यात अंदाज लावणे देखभाल खिडकी वाया घालवते।

टोपोलॉजी बदलल्याने पत्ता आराखडा बदलतो

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

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

पूलचा आकार मास्कवरून नाही, आराखड्यावरून ठरवा

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

टोपोलॉजी, पूल, स्थिर वाटप आणि त्यातून येणारी क्लायंट मर्यादा एकत्र नोंदवा। मग पुढील क्षमता प्रश्न तपास नाही तर अंकगणित होईल।