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

यसअघि जोडिएको नभएको क्लाइन्ट जोड्नुहोस् र ठेगाना घोषित दायराभित्र र आरक्षित समूहबाहिर पर्छ भनी पुष्टि गर्नुहोस्। त्यसपछि फर्कने बाटो पुष्टि गर्नुहोस्: नीतिले अनुमति दिएकोसम्म क्लाइन्ट पुग्नुपर्छ, त्यसभन्दा बढी होइन। योजनासँग मिल्ने तर काम गर्ने रुट नभएको ठेगाना सफल परिवर्तन होइन।

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

दायरा परिवर्तन फिर्ता लिनु

तपाईंको परिवर्तन-अभिलेखमा अघिल्ला तीन लाइन राख्नुहोस्, अघिल्लो फाइल मात्र होइन। तिनलाई पुनर्स्थापित गरी पुनःसुरु गर्दा बाँडफाँट पुरानो व्यवहारमा फर्कन्छ, र त्यसपछि फेरि जोडिने क्लाइन्टले त्यसबाट ठेगाना पाउनेछन्।

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

नयाँ क्लाइन्टले दायराभित्रको ठेगाना पाएपछि, आरक्षित ठेगाना कहिल्यै नदिइएपछि, र ती ठेगाना प्रयोग गर्ने रुट र नियमहरू इच्छित रूपमै व्यवहार गरिरहेपछि पूल परिवर्तन पूरा हुन्छ। त्यसभन्दा कम केही भए अर्को व्यक्तिलाई तीनमध्ये कुन सत्य होइन भनी पत्ता लगाउन छाडिन्छ।