OPNsense के पीछे OpenVPN क्लाइंट के स्थिर पते

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

OPNsense इन ओवरराइड को सर्वर की क्लाइंट-विशिष्ट सेटिंग्स में रखता है, प्रमाणपत्र के सामान्य नाम से कुंजीबद्ध, जिससे सामान्य नाम पता योजना का हिस्सा बन जाता है।

चिपचिपा लीज़ स्थिर पता नहीं है

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

गतिशील विकल्प, यानी client-connect स्क्रिप्ट और गतिशील अपडेट के ज़रिए VPN को DNS से जोड़ना, काम करता है और ऐसा रिज़ॉल्वर मांगता है जो अपडेट स्वीकार करे, साथ में हर कनेक्शन पर एक स्क्रिप्ट। उपकरण पर आप विक्रेता द्वारा भेजे गए पैकेजों तक सीमित हैं, और आमतौर पर वहीं यह योजना रुक जाती है।

वह /30 गणित जिसका कोई आनंद नहीं लेता

डिफ़ॉल्ट net30 टोपोलॉजी में हर क्लाइंट को अपना /30 मिलता है: पहला उपयोगी पता सर्वर पक्ष को जाता है, दूसरा क्लाइंट को। इसलिए ओवरराइड सर्वर के गतिशील टनल नेटवर्क से बाहर होने चाहिए, जिसका अर्थ है पहले उस नेटवर्क को चौड़ा करना। 10.8.0.0/24 पर स्थित सर्वर 10.8.0.0/23 पर जा सकता है, पुरानी श्रेणी का आधा हिस्सा गतिशील क्लाइंट के लिए और दूसरा आधा ओवरराइड के लिए छोड़कर। मूल /24 को अतिरिक्त IPv4 स्थानीय नेटवर्क के रूप में जोड़ें ताकि दोनों आधों का ट्रैफ़िक टनल में रूट हो।

हर ओवरराइड पते को /30 सीमा पर पड़ना चाहिए, इसलिए अंतिम ऑक्टेट चार का गुणज होता है। 10.8.1.0 पर /30 क्लाइंट को 10.8.1.2 देता है, और DNS रिकॉर्ड वही पता रखता है। इसके बजाय 10.8.1.3 चुनने से ऐसा क्लाइंट बनता है जो जुड़ता है पर ट्रैफ़िक नहीं भेज पाता, क्योंकि पता ऐसे सबनेट का है जो टोपोलॉजी ने उसे कभी नहीं दिया।

योजना रखना आसान होता है यदि ओवरराइड चौड़ी श्रेणी के शीर्ष से नीचे की ओर आवंटित हों, ताकि गतिशील पूल स्थिर द्वीपों के आसपास नहीं, खाली जगह में फैले।

स्थानीय नेटवर्क और वह ज़ोन जिसे क्लाइंट पूछते हैं

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

रिकॉर्ड उस ज़ोन में प्रकाशित करें जिसे दूरस्थ क्लाइंट वास्तव में पूछते हैं। केवल LAN रिज़ॉल्वर द्वारा परोसी जाने वाली ज़ोन का रिकॉर्ड ऐसे क्लाइंट के लिए अदृश्य है जिसका धकेला गया रिज़ॉल्वर कहीं और इशारा करता है, और गलत ज़ोन में और रिकॉर्ड जोड़ने से वह कभी ठीक नहीं होता। कुछ भी जोड़ने से पहले धकेले गए DNS विकल्प और खोज डोमेन की पुष्टि करें।

नए कनेक्शन पर क्या जाँचें

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

किसी दूसरे सामान्य नाम के तहत फिर से जारी प्रमाणपत्र अपने ओवरराइड से मेल खाना बंद कर देता है और क्लाइंट को गतिशील पूल में लौटा देता है। किसी भी पहचान परिवर्तन के बाद इसकी अपेक्षा करें।