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 नोंदी लागतात. नाव चुकीचे असल्यास पर्याय त्रुटीशिवाय दुर्लक्षित होतात. उत्पादनात नसलेल्या एका ग्राहकासह त्याच्या स्वतःच्या पत्ता तलावात चाचणी करा, नंतर त्याला दिलेला पत्ता, मिळालेले मार्ग आणि तो ज्या रिझॉल्व्हर सेटिंग्जवर संपला त्या वाचा.

जुनी सेवा परत येऊ शकेल अशा क्रमाने बदल आखा

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

एका वेळी एक गट हलवा, त्याच्या प्रमाणपत्रांसह, त्याच्या तलावासह आणि त्याच्या मार्गांसह, आणि घटनेच्या मधे शोधण्याऐवजी परतीचा मार्ग सराव करा. नवीन सेवा आधी थांबवली तरच चालणारी परतीही परतीच आहे, पण काहीही जळत नसताना ती चाचणी करावी.

शेवटी, प्रत्यक्ष समतुल्य नसलेली वैशिष्ट्ये यादी करा आणि प्रत्येकीचे भवितव्य लेखी ठरवा: स्वयं-सेवा प्रोफाइल डाउनलोड, प्रत्येक वापरकर्त्याचे परवानगी ध्वज, प्रशासन इंटरफेस स्वतः, थेट कनेक्शन अहवाल. त्यांना दस्तऐवजीकृत हस्तक प्रक्रियेने बदलणे हे वैध उत्तर आहे. ओळ रिकामी सोडणे नाही.

जुनं पोर्टल कधीही न पाहिलेला वापरकर्ता नोंदणी करू शकेल, जोडला जाऊ शकेल, इच्छित अंतर्गत पत्त्यावर पोहोचू शकेल आणि स्वच्छपणे रद्द होऊ शकेल तेव्हा काम पूर्ण होते. त्यापूर्वीचे सर्व तयारी आहे.