पुढील पुन्हा जोडणीवर पूल कोणता पत्ता देईल?
पूलचे पत्ते अशा क्रमाचे पालन करतात जो यादृच्छिक नाही: प्रथम लक्षात ठेवलेला पत्ता, नंतर सर्वात जास्त काळ न वापरलेला मोकळा पत्ता. नियम ठरवण्यापूर्वी तो वाचा.
काल जुळणारा नियम आज जुळत नाही, कारण ग्राहक दुसऱ्या टनेल पत्त्यावर परत आला। वाटपकर्ता तथापि यादृच्छिक नाही, आणि त्याचा क्रम जाणून घेणे ते आश्चर्य अपेक्षित घटनेत बदलते। तो त्याच ग्राहकाकडे पूर्वी असलेला पत्ता पसंत करतो, सर्वात जास्त काळ निष्क्रिय मोकळ्या पत्त्यावर परत जातो, आणि तुम्ही त्याला आठवण्यासाठी जागा दिली नाही तर सर्व विसरतो। भाड्यावर आधारित नियम त्या दिवसापर्यंत जुळत राहतात जेव्हा ते शांतपणे तसे करणे थांबवतात।
वाटपकर्ता जो क्रम पाळतो
प्रति common name एक सत्र असल्यास वाटपकर्ता प्रथम तो पत्ता शोधतो जो त्याच ग्राहकाने पूर्वी वापरला होता आणि जो आता मोकळा आहे। जर तो पत्ता नसेल तर तो सर्वात जास्त काळ निष्क्रिय राहिलेला मोकळा पत्ता घेतो। जेव्हा त्याच नावासाठी एकाचवेळी सत्रे सुरू असतात तेव्हा पूर्वीच्या पत्त्याला प्राधान्य लागू होत नाही आणि त्याऐवजी पहिला मोकळा पत्ता वापरला जातो, कारण सत्रे स्वतंत्र समकक्ष नोड म्हणून हाताळली जातात।
| Situation | Address chosen | Practical effect |
|---|---|---|
| Reconnect, old address still free | The remembered address | Rules appear stable for days |
| Old address taken by another client | Least recently used free address | A working rule silently stops matching |
| Concurrent sessions, same name | First free address, per session | One identity can hold several leases |
यावरून लगेच दोन परिणाम येतात। लवकर पुन्हा जोडणारा ग्राहक सहसा आपला पत्ता टिकवतो, म्हणूनच कोणीही यंत्रणा बदलण्यापर्यंत ती पाहत नाही। आणि त्या लहान खिडकीत जोडणारे दुसरे उपकरण पत्ता तो थोडा वेळ मोकळा असताना घेऊ शकते, त्यानंतर पहिल्या ग्राहकाला काहीतरी वेगळे मिळते आणि जुन्या क्रमांकावर आधारित प्रत्येक नियम चुकीचा ठरतो। या दोन्ही घटनांपैकी कोणतीही बिघाडासारखी लॉग ओळ तयार करत नाही।
भाडे स्थिर का दिसते आणि मग सरकते
स्थिरता ही येथे पुन्हा जोडण्यांची उदयोन्मुख गुणधर्म आहे जी दुसऱ्याने पत्ता मागण्यापूर्वी येतात। हे वचन नाही, आणि ग्राहक डिस्कनेक्ट असताना ते लागू होत नाही। पत्ता बदलेल अशी योजना करा, त्याने चकित होण्याऐवजी। उपकरणांच्या संख्येपेक्षा फारच मोठा नसलेला पूल टकरी नित्याच्या करतो, कारण सर्वात जास्त काळ न वापरलेल्या पत्त्याकडे परत जाण्याकडे निवडायला जवळपास काहीच नसते।
शिखर एकाचवेळीपणा ही संख्या आहे ज्यावर आकार ठरवावा, वापरकर्त्यांची संख्या नाही। एकाच वेळी दोन उपकरणांवरून चाचणी करणारा कोणी, किंवा जुने सत्र संपण्यापूर्वी पुन्हा जोडणारा ग्राहक, थोडा वेळ दोन भाडी राखतो। केवळ व्यक्तींच्या संख्येवर आधारित पूल नेमकी तीच अदलाबदल निर्माण करेल ज्याचा दोष लोक सर्व्हरवर टाकतात।
टिकाऊपणा फाइल लक्षात ठेवते, आरक्षित करत नाही
सेवेच्या पुनःप्रारंभातून टिकणाऱ्या पत्त्याला टिकाऊपणा फाइल लागते। ती बंद करताना ग्राहकाचे नाव आणि पत्ता साठवते आणि सेवा सुरू होताना ते पुन्हा वाचते, म्हणूनच नियोजित पुनःप्रारंभ आता तुम्ही लिहिलेले सर्व नियम ढवळत नाही।
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0ती जे करत नाही ते म्हणजे ग्राहक गैरहजर असताना पत्ता राखून ठेवत नाही। त्या अंतरात वाटपकर्ता क्रमांक दुसऱ्याला देण्यास मोकळा आहे, आणि फाइल मग अशी जुनी प्राधान्यता नोंदवते जी पुढील जोडणी पूर्ण करू शकत नाही। तिला पुनःप्रारंभाचे वर्तन सुधारणारा सुगावा म्हणून घ्या, स्थिर पत्तापद्धती म्हणून नाही।
तुम्ही फाइलमध्ये असताना पूल प्रत्येक मार्गित सबनेटविरुद्ध तपासा। आच्छादित परास असे पत्ते वाटते ज्यांना सर्व्हर मार्ग करू शकत नाही, आणि लक्षण असे आहे की ग्राहक जोडतो, पत्ता मिळवतो आणि कुठेही पोहोचत नाही।
पत्ता योग्यरितीने स्थिर करणे
जेव्हा फायरवॉल नियम किंवा DNS रेकॉर्डला खरोखर स्थिर पत्ता लागतो, तेव्हा आशा करण्याऐवजी तो नेमून द्या। प्रति ग्राहक संरचना नोंद थेट पत्ता आणि मास्क पाठवू शकते, आणि ती नोंद प्रभावी ग्राहक नावावर की केलेली असते।
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0स्थिर पत्ते गतिमान पूलबाहेर ठेवा जेणेकरून वाटपकर्ता कधीही तोच क्रमांक दुसऱ्या सत्राला देणार नाही। नंतर टनेलची रचना तपासा, कारण ती बदलते की प्रत्येक ग्राहक किती पूल पत्ते खर्च करतो: जुनी बिंदू-ते-बिंदू रचना प्रति ग्राहक एक छोटा खंड खर्च करते, तर सबनेट रचना प्रत्येकावर एक पत्ता वापरते। जो पूल एका रचनेत उदार दिसतो तो दुसऱ्यात संपू शकतो।
निकाल ग्राहकावर पुष्टी करा, सर्व्हरच्या हिशोबावर विश्वास ठेवण्याऐवजी। सत्र परत आल्यावर इंटरफेसचा पत्ता आणि पाठवलेला मार्ग पाहा, कारण सर्व्हरवरील लॉग मागितलेला पत्ता सांगू शकतो जेव्हा इंटरफेस स्वतः दुसरा धरतो।
दूरचा पत्ता वेगळा प्रश्न आहे
ग्राहकाच्या remote ओळीतील पत्ता कोणत्याही टनेलच्या अस्तित्वापूर्वी पोहोचण्यायोग्य असावा। तिथे पूलचा पत्ता ठेवणे, उदाहरणार्थ स्वतः सर्व्हरचा टनेल अंतिम बिंदू, म्हणजे ग्राहकाने अजून न बांधलेल्या टनेलमधून अंतिम बिंदूपर्यंत पोहोचण्याचा प्रयत्न करतो, आणि निकाल छोट्या मार्गाऐवजी वळण किंवा शांत प्रतीक्षा असतो।
ऑपरेटरने दिलेला सार्वजनिक अंतिम बिंदू वापरा, आणि पूल ज्यासाठी बनवला त्या साठी ठेवा: टनेलमधील पत्ते। पूलची परास, स्थिर वाटप आणि टिकाऊपणा मार्ग एकाच ठिकाणी लिहून ठेवल्यास पुढच्या व्यक्तीला प्रत्येक भाडे मनमाने मानण्यापासून वाचवते।