OpenVPN सर्वर nopool के साथ: एक स्पष्ट पूल सीमा घोषित करें

सर्वर हेल्पर एक सबनेट कॉन्फ़िगर करते हैं और फिर उसे अपनी पसंद के गतिशील पूल से भर देते हैं। वह डिफ़ॉल्ट तब तक सुविधाजनक है जब तक कुछ पते आवंटन से बाहर न रहने पड़ें — चाहे वे स्थिर आवंटनों के लिए आरक्षित हों या किसी भविष्य के खंड के लिए रोके गए हों। स्वचालित पूल को दबाना और सीमा स्वयं घोषित करना दो पंक्तियाँ और एक सोचा-समझा निर्णय माँगता है कि कौन-से पते आवंटन के लिए नहीं हैं। बाकी परिचालन अनुशासन है: सूची, लागू करना, सत्यापन, वापसी।

यह चालू सेवा में बदलाव है, इसलिए इसे परिचालन कार्य मानें: पहले सूची, सामान्य जीवनचक्र से लागू करना, नए क्लाइंट से सत्यापन और एक तैयार वापसी।

उसी सबनेट से शुरू करें जो आपके पास पहले से है

मौजूदा सर्वर कॉन्फ़िगरेशन और वे पते पढ़ें जो क्लाइंट वास्तव में रखते हैं। पूल बदलाव केवल उसी आधार के सामने अर्थ रखता है, और आधार हमेशा वही नहीं होता जो फ़ाइल सुझाती है, क्योंकि कोई प्रबंधित उत्पाद या कॉन्फ़िगरेशन जनरेटर उस फ़ाइल का स्वामी हो सकता है जिसे आप पढ़ रहे हैं।

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

प्रभावी टोपोलॉजी की पुष्टि करें। सबनेट टोपोलॉजी में हर क्लाइंट पूल से एक पता लेता है; पुराने net30 लेआउट हर क्लाइंट को एक छोटा ब्लॉक देते हैं और गणित बिल्कुल अलग है। अगर सर्वर अभी भी net30 पर है, तो यह पृष्ठ गलत माइग्रेशन मार्गदर्शिका है और पूल के आँकड़े वह अर्थ नहीं देंगे जिसकी आप अपेक्षा करते हैं। कहीं और से पता-गणित की नकल करने से पहले उस पंक्ति की जाँच करें।

सर्वर का अपना पता, क्लाइंट-कॉन्फ़िग निर्देशिका में हर स्थिर आवंटन, और वह हर पता लिख लें जिस पर कोई रूट या प्रवेश नियम निर्भर है। यही वे पते हैं जिन्हें गतिशील सीमा से बाहर रहना चाहिए। पहले उन्हें लिख लेना ही सीमा को अनुमान के बजाय निर्णय बनाता है। यह वापसी को पुनर्स्थापित करने के लिए कुछ ठोस भी देता है।

nopool जोड़ें और सीमा घोषित करें

हेल्पर कीवर्ड nopool स्वीकार करता है, जो सबनेट कॉन्फ़िगरेशन रखता है और स्वचालित गतिशील पूल को दबा देता है, जैसा OpenVPN 2.6 मैनुअल बताता है। फिर स्पष्ट ifconfig-pool पंक्ति वह समावेशी सीमा देती है जिसका आप इरादा रखते हैं, और उसका नेटमास्क सबनेट से मेल खाता है। दोनों पंक्तियाँ एक ही सर्वर ब्लॉक में आती हैं, क्योंकि अपने सबनेट के बिना पूल का कोई अर्थ नहीं है। उनके बीच क्रम केवल पठनीयता के लिए मायने रखता है, क्योंकि सेवा शुरू होने पर हेल्पर जोड़ी को फैला देता है।

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

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

सीमा का आकार और समवर्तीता अलग-अलग सीमाएँ हैं। max-clients अगर कुछ और कहता है तो सौ पते सौ समवर्ती क्लाइंट नहीं हैं, और समवर्तीता सीमा से बड़ा पूल बर्बादी नहीं बल्कि सामान्य है। मायने यह रखता है कि दोनों सीमाएँ डिफ़ॉल्ट से विरासत में लेने के बजाय सोच-समझकर चुनी जाएँ।

स्थिर आवंटन गतिशील सीमा से बाहर रखें

क्लाइंट-विशिष्ट ifconfig-push पूल आवंटन से अलग तंत्र है, और उसे सक्रिय टोपोलॉजी के अनुरूप पैरामीटर इस्तेमाल करने चाहिए। सबनेट मोड में वह एक पता और नेटमास्क है; पुराने उदाहरण में दिखने के कारण net30 जोड़ी को आगे बढ़ाना आम भूल है।

आवंटन इतिहास एक संकेत है, अधिकार नहीं। persist फ़ाइल याद रखती है कि किस क्लाइंट के पास कौन-सा पता था, इसलिए दोबारा जुड़ने वाले क्लाइंट को आम तौर पर वही मिलता है, और वह पते आरक्षित नहीं करती, मुक्त नहीं करती और स्थिर आवंटन की जगह नहीं लेती। अगर किसी विशेष उपकरण के पास हमेशा विशेष पता रहना चाहिए, तो persist फ़ाइल पर भरोसा करने के बजाय स्थिर आवंटन इस्तेमाल करें।

फिर पतों पर निर्भर रास्तों की जाँच करें। क्लाइंट तक भेजा गया रूट, सबनेट को अनुमति देने वाला फ़ायरवॉल नियम, या किसी विशेष होस्ट की अपेक्षा करने वाली मॉनिटरिंग जाँच — सभी पुरानी सीमा मान सकते हैं। उन्हें पढ़े बिना पूल बदलने से विफलता ऐसी जगह चली जाती है जो असंबंधित दिखती है।

जीवनचक्र से लागू करें, फिर सत्यापित करें

बदलाव उसी तरह लागू करें जैसे सेवा सामान्यतः कॉन्फ़िगरेशन पाती है — सीधी फ़ाइल और पुनःआरंभ, या फ़ाइल को फिर से बनाने वाली प्रबंधन परत। जनरेट की गई फ़ाइल में हाथ से किया बदलाव अगली जनरेशन तक टिकता है, उससे अधिक नहीं। दर्ज करें कि फ़ाइल का स्वामी कौन-सा तंत्र है, क्योंकि अगले ऑपरेटर को जानना होगा कि वही बदलाव कहाँ करना है। फिर एक बार पुनःआरंभ करें और क्लाइंट को बुलाने से पहले लॉग पढ़ें।

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

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

उस क्लाइंट को दोबारा जोड़ें जिसके पास पुरानी सीमा का पता था। उसे नई सीमा से पता मिलना चाहिए, और पुराने पते से जुड़ी कोई भी सत्र-स्तरीय स्थिति चली जानी चाहिए। अगर वह पुराना पता रखता है, तो कुछ और उसे आवंटित कर रहा है और पूल वह स्वामी नहीं है जो आप सोचते हैं।

सीमा परिवर्तन वापस लेना

अपने बदलाव-रिकॉर्ड में पिछली तीन पंक्तियाँ रखें, केवल पिछली फ़ाइल नहीं। उन्हें पुनर्स्थापित कर पुनःआरंभ करने से आवंटन पुराने व्यवहार पर लौट आता है, और उसके बाद दोबारा जुड़ने वाले क्लाइंट उससे पते पाएँगे।

रिकॉर्ड में दो चेतावनियाँ होनी चाहिए। वापसी के समय पहले से जुड़े क्लाइंट दोबारा जुड़ने तक अपने वर्तमान पते रखते हैं, इसलिए वापसी पूरे बेड़े में तत्काल नहीं होती। और अगर पुरानी सीमा किसी स्थिर आवंटन से टकराती थी, तो उसे पुनर्स्थापित करने से टकराहट भी लौट आती है; वही टकराहट बदलाव का कारण थी, और उसे वापसी से अलग उपाय चाहिए।

पूल बदलाव तब पूरा होता है जब नए क्लाइंट को सीमा के भीतर पता मिले, आरक्षित पता कभी न दिया जाए, और उन पतों का उपयोग करने वाले रूट और नियम इच्छित रूप से व्यवहार करते रहें। इससे कम कुछ भी अगले व्यक्ति को यह खोजने पर छोड़ देता है कि तीनों में से कौन-सा सच नहीं है।