OpenVPN Access Server बनाम Community: वास्तवमा के स्थानान्तरण हुन्छ

प्रोफाइलहरू सर्छन्; प्रयोगकर्ता सूचीहरू पछाडि रहन्छन्। Access Server र Community Edition बीच परिवर्तन गर्ने टोलीले कटओभरको एक घण्टामा त्यो खाडल भेट्छ, जब उसको पहिलो क्लाइन्ट प्रमाणित हुन्छ र त्यसपछि समूह नीति, प्रयोगकर्ता-अनुसार मार्ग र स्व-सेवा पासवर्ड रिसेट केही हुँदैन। दुवै उत्पादनले एउटै प्रोटोकल बोल्छन् र एउटै क्लाइन्ट स्वीकार गर्छन्, र यही कारण योजनाको क्रममा त्यो खाडल अदृश्य रहन्छ। तपाईंले वास्तवमा व्यवस्थापन तह र त्यसको स्वामित्व लिने मानिसहरू छानिरहनुभएको छ।

निर्णयलाई सुविधा तालिका नभई मालसामानको प्रश्नका रूपमा लिनुहोस्। कसले प्रयोगकर्ता बनाउँछ, कसले प्रमाणपत्र रद्द गर्छ र 02:00 बजे कसले फोन उठाउँछ भनी सोध्नुहोस्।

.ovpn फाइलले सेटअप किन बोक्दैन

एउटा .ovpn प्रोफाइलले एउटा क्लाइन्टको एउटा सर्भरसँगको सम्बन्ध वर्णन गर्छ: टाढाको होस्ट, प्रोटोकल, CA, क्लाइन्ट प्रमाणपत्र र कुञ्जी, र कुनै पनि इनलाइन tls-crypt सामग्री। त्यो फाइल नयाँ बिल्डमा राख्नुहोस्, क्लाइन्ट तैपनि ह्यान्डशेक पूरा गर्छ, त्यसैले स्थानान्तरण सकिएको देखिन्छ। त्यसमा प्रयोगकर्ता, तिनका समूह, तिनका स्थिर मार्ग वा कसलाई जोडिन अनुमति छ भनी निर्धारण गर्ने नीति केही पनि सूचीबद्ध छैन। ती अभिलेख सर्भरको आफ्नै भण्डारणमा बस्छन्, र दुवै उत्पादनले तिनलाई फरक रूपमा राख्छन्।

Community Edition मा समानार्थी तपाईंले राख्ने फाइलहरू हुन्: प्रत्येक क्लाइन्टका लागि ifconfig-push र iroute जस्ता विकल्प भएका client-config-dir प्रविष्टिहरू, रद्दीकरणका लागि CRL, र tls-crypt कुञ्जी। Access Server ती अवधारणाहरू आफ्नै डेटाबेसमा राख्छ र वेब कन्सोल तथा sacli कमाण्ड-लाइन उपकरणमार्फत देखाउँछ। अवधारणाहरू एक-एक मिल्छन्; कलाकृतिहरू बिल्कुल सर्दैनन्।

प्रोफाइलहरूले बदलिनुअघि कसैले नदेख्ने व्यवहार पनि चोरी-छिपी ल्याउँछन्। redirect-gateway def1 भएको क्लाइन्टले सबै ब्राउजिङ सर्भरमार्फत पठाउँछ; त्यसलाई त्यो लाइन नभएको बिल्डमा सार्नुहोस् र गुनासो इन्टरनेट बिग्रियो भन्ने हुन्छ। CA नमिल्नु वा गलत remote-cert-tls सेटिङ ठूलो स्वरमा असफल हुन्छ, जो राम्रो परिणाम हो। हराएको tls-crypt कुञ्जी शान्त टाइमआउटका रूपमा असफल हुन्छ, जो राम्रो होइन।

व्यवस्थापन तहले के ओगट्छ

प्रोटोकल नभएको कुरा गन्नुहोस्: खाता सिर्जना, पासवर्ड रिसेट, समूह तोक्ने, MFA दर्ता, जडान अधिकार, र कसले कहिले जोडियो भन्ने जवाफ दिने अडिट ट्रेल। Community Edition यीमध्ये केही पनि सिधै दिँदैन। तपाईं प्रमाणीकरण ब्याकएन्ड छान्नुहुन्छ, प्लगइन वा auth-user-pass-verify मार्फत PAM, LDAP वा RADIUS जोड्नुहुन्छ, र बाँकी आफैं मर्मत गर्नुहुन्छ। Access Server प्रयोगकर्ता पोर्टल, प्रशासन कन्सोल र सामान्य पहिचान प्रदायकसँगको एकीकरण दिन्छ। दुवै व्यवस्था पूर्वनिर्धारित रूपमा सुरक्षित छैनन्, किनकि नीति अझै नेटवर्क जान्ने व्यक्तिले लेख्नुपर्छ।

अधिकारहरू सबैभन्दा तीखो परिचालन भिन्नता हुन्। Access Server एकै समयका जडानको संख्याका आधारमा इजाजतपत्र पाउँछ र त्यो संख्या सफ्टवेयरमा लागू गर्छ। Community Edition मा विश्वव्यापी सीमा एउटै max-clients लाइन हो, जबकि प्रति प्रयोगकर्ता वा प्रति समूह जे पनि बढी client-config-dir काम र तपाईंको आफ्नै कार्यान्वयन हो। त्यो मर्मतमा रुचि नभएको टोलीले व्यावसायिक उत्पादनको शुल्क तिर्दा ठ्याक्कै त्यही किन्छ।

इजाजतपत्र र समर्थन: कसैले बजेटमा नराख्ने शीर्षक

Community Edition निःशुल्क र खुला स्रोतको हो। Access Server व्यावसायिक हो, र यसको निःशुल्क तहले ऐतिहासिक रूपमा थोरै एकै समयका जडान समेट्यो, त्यसभन्दा माथि सशुल्क इजाजतपत्र छ। पुरानो फोरम उत्तरमा उद्धृत कुनै पनि अंक अहिले पुरानो भइसकेको छ, त्यसैले परियोजनाको लागत गणना गर्नुअघि विक्रेताको हालको सर्त जाँच्नुहोस्। इमानदार तुलनाले समुदायतर्फ प्रयोगकर्ता व्यवस्थापन, MFA र अनुगमन बनाउन बिताएका घण्टा व्यावसायिकतर्फको इजाजतपत्र लाइनमा थप्छ।

समर्थनको स्वामित्व पनि त्यही विभाजन पछ्याउँछ। Community Edition सँग हरेक अनौठो क्लाइन्ट र हरेक कर्नेल अद्यावधिकका लागि एस्केलेसन मार्ग तपाईं नै हुनुहुन्छ। Access Server सँग फोन गर्न विक्रेता हुन्छ, र तपाईंको परिवर्तन विन्डोमा मिलोस् वा नमिलोस्, उसको प्रकाशन लय तपाईंले हात पार्नुहुन्छ।

कटओभर अघिका जाँचहरू

कुनै पनि दिशामा कटओभर गर्नुअघि चलिरहेको सर्भरले वास्तवमा के राख्छ त्यसको सूची बनाउनुहोस्। Access Server तर्फ प्रयोगकर्ता सूची र समूह तोकाइ निर्यात गर्नुहोस् र कुन खाता MFA मा निर्भर छन् नोट गर्नुहोस्। Community Edition तर्फ जारी गरिएका प्रमाणपत्र, CRL र client-config-dir मुनिका हरेक फाइल सूचीबद्ध गर्नुहोस्। दुवै सूची लाइन-दर-लाइन तुलना गर्नुहोस्, किनकि तिनीबीचको भिन्नता नै स्थानान्तरणको काम हो।

पुरानो सेवा अझै चलिरहेको बेला प्रतिनिधि क्लाइन्ट परीक्षण गर्नुहोस्। openvpn --config client.ovpn --verb 4 अग्रभागमा ह्यान्डशेक, पठाइएका मार्ग र DNS विकल्प छाप्छ, र openssl x509 -in client.crt -noout -subject -enddate क्लाइन्टले वास्तवमा कुन प्रमाणपत्र प्रस्तुत गर्छ देखाउँछ। जोडिने तर आन्तरिक होस्टमा पुग्न नसक्ने क्लाइन्टमा मार्ग वा iroute को खाडल हुन्छ, प्रमाणीकरण असफलता होइन।

पुरानो पुनःप्राप्ति मार्गलाई तबसम्म जीवित राख्नुहोस् जबसम्म प्रतिस्थापनले सफल परीक्षणसँगै अस्वीकृत-पहुँच परीक्षण पनि पास गर्दैन। अन्तिम नक्सा एउटै पृष्ठमा लेख्नुहोस्: हरेक आवश्यकता, आज त्यसलाई पूरा गर्ने कलाकृति, र पछि पूरा गर्ने कलाकृति।