Access Server बाट Community OpenVPN सम्म: के पुनः निर्माण गर्नुपर्छ
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 मा तपाईं आफैं push निर्देश लेख्नुहुन्छ, redirect-gateway सर्भरको हो कि ग्राहकको भन्ने निर्णय गर्नुहुन्छ, र होस्टमा फर्वार्डिङ र NAT छन् भनी पुष्टि गर्नुहुन्छ। सकिएको ह्यान्डशेकले फर्वार्डिङ, ठेगाना अनुवाद वा ग्राहकले वास्तवमै पाएका मार्गबारे केही बताउँदैन।
प्रति-ग्राहक व्यवहारका लागि client-config-dir र ग्राहकको प्रमाणपत्रको common name बाट नाम राखिएको फाइल चाहिन्छ, र साइट-देखि-साइट जोडीका लागि पछाडिका प्रिफिक्सका लागि iroute प्रविष्टि चाहिन्छ। नाम गलत भएमा विकल्पहरू त्रुटिबिना बेवास्ता गरिन्छन्। उत्पादन नभएको एउटा ग्राहकसँग उसको आफ्नै ठेगाना पूलमा परीक्षण गर्नुहोस्, त्यसपछि उसलाई दिइएको ठेगाना, पाएका मार्ग र अन्त्य गरेको रिजोल्भर सेटिङ पढ्नुहोस्।
पुरानो सेवा फर्कन सक्ने गरी कटओभरको क्रम मिलाउनुहोस्
नयाँ सुन्नेलाई अर्को पोर्ट वा ठेगानामा चलाउनुहोस्, र प्रतिस्थापन प्रमाणित गर्दै गर्दा पुरानोलाई ट्राफिक सेवा गर्न दिनुहोस्। एउटै सकेटमा दुई डेमन फिर्ती योजना होइन।
एकै पटकमा एउटा समूह सार्नुहोस्, उसका प्रमाणपत्र, पूल र मार्गसहित, र घटनाको बीचमा पत्ता लगाउनुको सट्टा फर्कने बाटोको अभ्यास गर्नुहोस्। नयाँ सेवा पहिले रोक्नुपर्ने भएमा मात्र चल्ने फिर्ती पनि फिर्ती हो, तर केही नबल्दै परीक्षण गर्नुपर्छ।
अन्तमा, प्रत्यक्ष समानता नभएका सुविधाहरू सूचीबद्ध गर्नुहोस् र प्रत्येकको भाग्य लिखित रूपमा तय गर्नुहोस्: स्व-सेवा प्रोफाइल डाउनलोड, प्रति-प्रयोगकर्ता अनुमति झन्डा, प्रशासन इन्टरफेस आफैं, प्रत्यक्ष जडान प्रतिवेदन। तिनलाई कागजी म्यानुअल प्रक्रियाद्वारा प्रतिस्थापन गर्नु वैध उत्तर हो। पङ्क्ति खाली छोड्नु त्यो होइन।
पुरानो पोर्टल कहिल्यै नदेखेको प्रयोगकर्ताले दर्ता गर्न, जोडिन, इच्छित आन्तरिक ठेगानामा पुग्न र सफासँग रद्द हुन सक्दा काम सकिन्छ। त्यसअघिको सबै तयारी हो।