Access Server से Community OpenVPN तक: क्या दोबारा बनाना पड़ेगा

Access Server और Community OpenVPN एक ही प्रोटोकॉल बोलते हैं और बाकी लगभग कुछ भी एक जैसा नहीं। हैंडशेक, सिफ़र वार्ता और टनल का डेटा प्लेन संगत हैं, इसलिए क्लाइंट अक्सर अपनी प्रोफ़ाइल बदले बिना किसी भी एक से जुड़ सकता है। फ़र्क यह है कि कॉन्फ़िगरेशन का मालिक कौन है: एक उत्पाद ऐसी प्रबंधन परत देता है जो नीति लिखती और लागू करती है, दूसरा आपको एक कॉन्फ़िग फ़ाइल और हुक का समूह देता है और अपेक्षा करता है कि आप निर्णय लें।

यही भेद माइग्रेशन योजना है। पुराने उत्पाद ने आपकी ओर से जो कुछ तय किया, उसे नई तैनाती में कहीं स्पष्ट निर्णय बनना होगा।

जहाँ दोनों तैनातियाँ आपस में बदली जाने योग्य नहीं रहतीं

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

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

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

पहचान प्रमाणपत्र फ़ाइलों के साथ स्थानांतरित नहीं होती

पुराने प्राधिकरण के प्रमाणपत्र नई सेवा में सही ढंग से पार्स हो सकते हैं और फिर भी गलत पहचान हो सकते हैं, क्योंकि पुराने उत्पाद ने उन्हें ऐसी खाता स्थिति से जोड़ा था जो नई सेवा नहीं देख सकती। पहले तय करें कि नई तैनाती केवल प्रमाणपत्र से, PAM या RADIUS तक पहुँचने वाले प्लगइन से, या किसी संयोजन से प्रमाणीकरण करती है, फिर जाँचें कि हर विकल्प वे गुण बनाए रखता है जिनकी आपको आवश्यकता है। प्रति-उपयोगकर्ता पहचान के बिना साझा प्रमाणपत्र उसके सभी धारकों के लिए एक ही क्रेडेंशियल है। निरस्तीकरण भी पहले दिन से काम करना चाहिए, जिसका Community OpenVPN में अर्थ है crl-verify द्वारा संदर्भित CRL फ़ाइल और उसे दोबारा बनाने वाली प्रक्रिया।

कटओवर से पहले नामांकन की योजना बनाएं, बाद में नहीं। नए प्रमाणपत्र, परीक्षित निरस्तीकरण पथ और एक व्यक्ति को अक्षम करने का प्रलेखित तरीका पूर्वापेक्षाएँ हैं, बाद का काम नहीं। यदि बहु-कारक प्रमाणीकरण पुराने उत्पाद के एकीकरण से आया था, तो प्रतिस्थापन का स्पष्ट नाम दें, क्योंकि स्थापित न किया गया प्लगइन सबसे बुरे समय पर बंद होकर विफल होता है।

रूटिंग और नाम विश्लेषण कॉन्फ़िग लिखने वाले का अनुसरण करते हैं

रूट, DNS सेटिंग्स और पूर्ण-टनल व्यवहार दोनों उत्पादों में पुश किए गए विकल्प हैं, पर उन्हें आपके लिए केवल एक ही गणना करता है। Community OpenVPN में आप पुश निर्देश स्वयं लिखते हैं, तय करते हैं कि redirect-gateway सर्वर पर रहे या क्लाइंट पर, और पुष्टि करते हैं कि होस्ट पर फ़ॉरवर्डिंग और NAT मौजूद हैं। पूरा हुआ हैंडशेक आपको फ़ॉरवर्डिंग, पता अनुवाद या उन रूटों के बारे में कुछ नहीं बताता जो क्लाइंट को वास्तव में मिले।

प्रति-क्लाइंट व्यवहार के लिए client-config-dir और क्लाइंट के प्रमाणपत्र के common name पर नामित फ़ाइल चाहिए, और साइट-से-साइट पीयर के लिए उसके पीछे के प्रीफ़िक्स के लिए iroute प्रविष्टियाँ चाहिए। नाम गलत हुआ तो विकल्प बिना किसी त्रुटि के अनदेखा कर दिए जाते हैं। अपने ही पता पूल में एक ग़ैर-उत्पादन क्लाइंट के साथ परीक्षण करें, फिर उसे दिया गया पता, उसे मिले रूट और जिन रिज़ॉल्वर सेटिंग्स पर वह पहुँचा, उन्हें पढ़ें।

कटओवर को ऐसे क्रम दें कि पुरानी सेवा लौट सके

नया लिसनर किसी दूसरे पोर्ट या पते पर चलाएँ, और प्रतिस्थापन सिद्ध करते समय पुराने को ट्रैफ़िक देते रहें। एक ही सॉकेट पर दो डेमन रोलबैक योजना नहीं है।

एक बार में एक समूह ले जाएँ, उसके अपने प्रमाणपत्र, अपना पूल और अपने रूट के साथ, और लौटने के रास्ते का अभ्यास करें, घटना के दौरान उसे खोजें नहीं। जो रोलबैक केवल तब काम करता है जब नई सेवा पहले रोकी जाए, वह भी रोलबैक है, पर उसका परीक्षण तब होना चाहिए जब कुछ जल न रहा हो।

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

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