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

यापूर्वी जोडला न गेलेला क्लायंट जोडा आणि पत्ता जाहीर श्रेणीत तसेच राखीव संचाबाहेर पडतो याची खात्री करा। नंतर परतीचा मार्ग तपासा: धोरण परवानगी देते तेवढ्यापर्यंत क्लायंटने पोहोचावे, त्यापुढे नाही। योजनेशी जुळणारा पण कार्यरत मार्ग नसलेला पत्ता यशस्वी बदल नाही।

जुन्या श्रेणीतील पत्ता धारण करणाऱ्या क्लायंटला पुन्हा जोडा। त्याला नवीन श्रेणीतील पत्ता मिळावा, आणि जुन्या पत्त्याशी जोडलेली कोणतीही सत्र-स्तरीय स्थिती गेली पाहिजे। तो जुना पत्ता ठेवत असेल तर दुसरे काहीतरी तो देत आहे आणि पूल तुम्ही समजता तो मालक नाही।

श्रेणी बदल मागे घेणे

तुमच्या बदल-नोंदीत मागील तीन ओळी ठेवा, केवळ मागील फाइल नाही। त्या पुनर्संचयित करून पुन्हा सुरू केल्यास वाटप जुन्या वर्तनाकडे परते, आणि त्यानंतर पुन्हा जोडणाऱ्या क्लायंटना तिथून पत्ते मिळतील।

नोंदीत दोन इशारे असावेत। मागे घेताना आधीच जोडलेले क्लायंट पुन्हा जोडेपर्यंत त्यांचे सध्याचे पत्ते ठेवतात, त्यामुळे मागे घेणे संपूर्ण ताफ्यात तात्काळ नसते। आणि जुनी श्रेणी स्थिर नियुक्तीशी ओव्हरलॅप झाली असेल तर ती पुनर्संचयित केल्यास टक्करही पुनर्संचयित होते; तेच ओव्हरलॅप बदलाचे कारण होते आणि त्याला मागे घेण्यापेक्षा वेगळा उपाय लागतो।

पूल बदल तेव्हा पूर्ण होतो जेव्हा नवीन क्लायंटला श्रेणीतला पत्ता मिळतो, राखीव पत्ता कधीही दिला जात नाही, आणि ते पत्ते वापरणारे मार्ग व नियम हेतूप्रमाणे वागत राहतात। त्यापेक्षा कमी काहीही पुढच्या व्यक्तीला तीनपैकी काय खरे नाही हे शोधायला सोडते।