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