OpenVPN प्रोफाइलमा प्रमाणपत्रका तीन ब्लक हुन्छन्: कुन गोप्य हो?

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

एउटा फाइल, तीन ब्लक, फरक काम

सामान्य प्रोफाइलले BEGIN र END चिन्हहरूबीच ca ब्लक, cert ब्लक र key ब्लक राख्छ, वा तीनैलाई छुट्टाछुट्टै फाइलका रूपमा संकेत गर्छ। केही प्रोफाइलले tls-auth वा tls-crypt कुञ्जीका लागि चौथो ब्लक थप्छन्, जो प्रमाणपत्र होइन, साझा रहस्य हो। क्लाइन्टले प्रत्येक ब्लकलाई त्यसलाई नाम दिने निर्देशनअनुसार पढ्छ, त्यसैले लेबलहरू तिनीहरू देखिने क्रमभन्दा महत्त्वपूर्ण छन्।

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

ब्लकवरिपरिका निर्देशनहरूले तिनीहरू कसरी प्रयोग हुन्छन् भन्ने निर्धारण गर्छन्। ca बदल्नुहोस् र क्लाइन्ट अर्को अधिकारीलाई विश्वास गर्छ; key नबदली cert बदल्नुहोस् र विश्वाससँग कुनै सम्बन्ध नभएको अमेलका कारण ह्यान्डसेक असफल हुन्छ।

CA ब्लक सार्वजनिक छ, CA कुञ्जी कहिल्यै होइन

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

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

अधिकारीलाई विश्वास गर्नु पनि सुनिँदाजति फराकिलो हुँदैन। CA ले हस्ताक्षर गरेको जुनसुकै प्रमाणपत्र स्वीकार गर्ने क्लाइन्टले त्यही CA मा अर्को सेवाका लागि जारी गरिएको प्रमाणपत्र पनि स्वीकार गर्नेछ। अपेक्षित सर्भर भूमिका वा नाम पिन गर्ने विकल्पहरूले त्यो खाडल बन्द गर्छन्, र TLS विकल्प सन्दर्भ ले त्यसो गर्ने प्रमाणीकरण निर्देशनहरू सूचीबद्ध गर्छ।

सर्भर र क्लाइन्ट प्रमाणपत्रहरू विपरीत दिशामा संकेत गर्छन्

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

ठेगाना पहिचान होइन। सही IP मा पुग्नुले कसले जवाफ दियो भन्ने कुरा केही प्रमाणित गर्दैन, त्यसैले होस्टनाम वा प्रमाणपत्र नामको जाँच अझै पनि प्रोफाइलमै पर्छ। खाता पासवर्डले पनि आवश्यक क्लाइन्ट प्रमाणपत्रलाई चुपचाप प्रतिस्थापन गर्दैन, किनकि दुवै फरक चरणमा जाँचिन्छन् र तैनाथीले दुवै माग्न सक्छ।

क्लाइन्टको निजी कुञ्जी त्यो भाग हो जो निजी रहनैपर्छ। यो खुलासा भएको हुन सक्छ भने, तपाईंको ल्यापटपबाट फाइल मेटाउँदा सर्भरमा केही बदलिँदैन, जसले सम्बन्धित प्रमाणपत्रलाई अपरेटरले रद्द नगरेसम्म स्वीकार गरिरहनेछ। अपरेटरलाई त्यो पहिचान बदल्न वा रद्द गर्न भन्नु नै तपाईंसँगै यात्रा गर्ने एकमात्र उपाय हो।

उस्तै देखिने तर नहुने दुई अनुरोध

इन्क्रिप्टेड रूपमा राखिएको कुञ्जीले क्लाइन्टले प्रयोग गर्नुअघि पासफ्रेज माग्छ। VPN सेवाले छुट्टै खाता पासवर्ड माग्न सक्छ, र दुवै अनुरोध लगभग एउटै शब्दमा केही सेकेन्डको फरकमा आउन सक्छन्। पासफ्रेजले तपाईंको डिस्कको फाइल जोगाउँछ; पासवर्डले सर्भरसामु खाता प्रमाणित गर्छ। दुवैलाई गलाउनु मानिसहरूलाई सहयोग गर्नै नसक्ने पासवर्ड रिसेटतिर पठाउँछ।

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

प्रमाणपत्र साँच्चै म्याद सकिएको भए, प्रतिस्थापन त्यो जारी गर्नेबाटै आउनुपर्छ। अरू कसैको कुञ्जी नवीकरणको बाटो होइन, र सहकर्मीबाट चल्ने प्रोफाइल उधारो लिनु पनि होइन।

सफा ह्यान्डसेकले के प्रमाणित गर्छ र के गर्दैन

पूरा भएको TLS ह्यान्डसेकसम्म पुग्नुको अर्थ कन्फिगर गरिएको पहिचान सम्बन्ध टिक्यो भन्ने हो: सर्भरको प्रमाणपत्र तपाईंको CA सँग शृंखलाबद्ध भयो र तपाईंको प्रमाणपत्र स्वीकार भयो। यसले अपरेटरको लगिङ नीतिबारे केही भन्दैन, र सुरुङ उभिएपछि तपाईंका अनुप्रयोगहरू चल्नेछन् कि भन्ने पनि भन्दैन।

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