अगली बार पुनः कनेक्ट होने पर पूल कौन-सा पता देगा?
पूल के पते ऐसे क्रम का पालन करते हैं जो यादृच्छिक नहीं है: पहले याद रखा गया पता, फिर वह खाली पता जो सबसे लंबे समय से अप्रयुक्त है। नियम तय करने से पहले इसे पढ़ें।
जो नियम कल मेल खाता था वह आज नहीं खाता, क्योंकि क्लाइंट किसी दूसरे टनल पते पर लौटा। आवंटक फिर भी यादृच्छिक नहीं है, और उसका क्रम जानना उस आश्चर्य को पूर्वानुमेय घटना बना देता है। वह उसी क्लाइंट का पहले वाला पता पसंद करता है, सबसे लंबे समय से निष्क्रिय खाली पते पर लौटता है, और अगर आप उसे याद रखने की जगह नहीं देते तो सब कुछ भूल जाता है। पट्टे पर आधारित नियम उस दिन तक मेल खाते रहते हैं जब वे चुपचाप ऐसा करना बंद कर देते हैं।
वह क्रम जिसका आवंटक पालन करता है
प्रति 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 पंक्ति में पता किसी भी टनल के होने से पहले पहुँचने योग्य होना चाहिए। वहाँ पूल का पता रखना, जैसे स्वयं सर्वर का टनल अंतिम बिंदु, इसका अर्थ है कि क्लाइंट ऐसी टनल से अंतिम बिंदु तक पहुँचने की कोशिश करता है जो उसने अभी बनाई नहीं है, और परिणाम छोटे रास्ते के बजाय लूप या खामोश प्रतीक्षा होता है।
वह सार्वजनिक अंतिम बिंदु इस्तेमाल करें जो ऑपरेटर ने दिया, और पूल को उसी के लिए रखें जिसके लिए वह बनाया गया: टनल के भीतर के पते। पूल की परास, स्थिर आवंटन और स्थायित्व पथ को एक ही जगह लिख लेना अगले व्यक्ति को हर पट्टे को मनमाना मानने से बचाता है।