OpenVPN सर्वर हेल्पर: नेटवर्क और नेटमास्क, कभी CIDR नहीं

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

हेल्पर जो दो आर्ग्युमेंट स्वीकार करता है

पहले नेटवर्क लिखें और फिर मास्क, पते से कुछ भी जोड़े बिना:

server 10.72.16.0 255.255.240.0

यह /20 का रूप है। नीचे की लाइन गलती है, और यह रनटाइम में नहीं, विकल्प पार्सिंग में विफल होती है:

server 10.72.16.0/20 255.255.240.0

इसे डीबग करते समय दोनों विचार अलग रखें। प्रीफ़िक्स लंबाई और बिंदुयुक्त मास्क एक ही स्पैन बताते हैं, पर हेल्पर दोनों एक साथ नहीं लेता, और अस्वीकृत लाइन एक विकल्प त्रुटि देती है जो गणित का नहीं, निर्देश का नाम लेती है।

मास्क लिखने से पहले नेटवर्क संरेखित करें

पहला पता रेंज का नेटवर्क पता है, उसके भीतर का सुविधाजनक क्लाइंट पता नहीं। /20 के लिए स्पैन 10.72.16.0 से 10.72.31.255 तक चलता है, और इनमें से केवल पहला ही वैध नेटवर्क आर्ग्युमेंट है। /21 255.255.248.0 का उपयोग करता है और 10.72.16.0 से 10.72.23.255 तक फैलता है, इसलिए उसकी लाइन server 10.72.16.0 255.255.248.0 है।

प्रीफ़िक्स बदलने से स्पैन बदलता है और कुछ नहीं। इससे यह नहीं बदलता कि एक क्लाइंट को कितने पते मिलते हैं, क्योंकि वह टोपोलॉजी का गुण है, इस लाइन के मास्क का नहीं।

सर्वर की ओर से पूल की पुष्टि करें

इंस्टेंस को फ़ोरग्राउंड में विस्तृत लॉगिंग के साथ शुरू करें और हेल्पर जो लाइनें छोड़ता है उन्हें पढ़ें। उसने जो पूल बनाया वह स्टार्टअप पर छपता है, जो हाथ से गणित करने से अधिक भरोसेमंद है:

openvpn --config /etc/openvpn/server.conf --verb 4 --dev tun9 --port 1195

आउटपुट के ऊपरी हिस्से के पास पूल सारांश खोजें। यह वह रेंज सूचीबद्ध करता है जो हेल्पर ने आरक्षित की, और अगर वह रेंज आपके इरादे से मेल नहीं खाती, तो लाइन के आर्ग्युमेंट गलत हैं, मास्क का गणित जो भी कहे।

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

टोपोलॉजी को ध्यान में रखकर क्लाइंट का मास्क पढ़ें

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

निष्कर्ष निकालने से पहले कॉन्फ़िगर की गई टोपोलॉजी और आवंटित पता एक साथ जाँचें:

ip -4 addr show tun0

अगर पता पूल के भीतर है और मास्क पूल से संकरा है, तो यह टोपोलॉजी अपना काम कर रही है। अगर पता पूल के बाहर है, तो पूल गलत है, और क्लाइंट पक्ष का कोई भी निरीक्षण इसे ठीक नहीं करेगा।

चालू पूल बदलना

ऐसी रेंज चुनें जो मौजूदा पूल, LAN या क्लाइंट को पहले से भेजे गए किसी भी रूट से ओवरलैप न हो। ओवरलैप वह विफलता है जो रीस्टार्ट को पार कर जाती है और फिर कुछ दिन बाद एक साइट के रूप में सामने आती है जो एक दिशा से अगम्य है।

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

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