Windows मा OpenVPN 3 र Connect मा cryptoapicert किन असफल हुन्छ

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

त्यो प्रतिवेदनमा तीन तह मिसाइन्छ: Community क्लाइन्ट, मुख्य पुस्तकालय र कसैले स्थापना गरेको फ्रन्टएन्ड। तीमध्ये एउटाले मात्र कहिल्यै यो निर्देशन बुझ्यो।

यो विकल्प जहाँ छ त्यहाँ यसको अर्थ के हो

Windows मा Community OpenVPN 2 क्लाइन्टमा, cryptoapicert त्यस्तो प्रमाणपत्र नाम दिन्छ जुन क्लाइन्टले फाइलमा होइन, Windows प्रमाणपत्र भण्डारमा खोज्नुपर्छ। यो Windows-विशेष सुविधा हो, र यो काम गर्छ किनकि त्यो क्लाइन्टले भण्डार सूचीबद्ध गर्न र परिणामस्वरूप प्राप्त कुञ्जी आफ्नै TLS स्ट्याकलाई दिन जान्दछ। त्यसैले निर्देशन त्यो क्लाइन्टको कन्फिगरेसन भाषाको भाग हो, OpenVPN प्रोटोकलको गुण होइन। सञ्चार ढाँचामा यसलाई बोक्ने केही छैन।

त्यही लाइन अर्को अनुप्रयोगमा प्रतिलिपि गर्नुहोस् र नयाँ कार्यक्रमले पार्स गर्न, बेवास्ता गर्न वा अस्वीकार गर्न सक्ने शब्द प्रतिलिपि गर्नुभयो। निर्देशन प्रोटोकलको विशेषता होइन, र यो OpenVPN बोल्ने हरेक क्लाइन्टको विशेषता पनि होइन।

त्यसको सट्टा मुख्य पुस्तकालयले के दिन्छ

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

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

त्यसको सट्टा Windows फ्रन्टएन्डले के गर्छ

OpenVPN Connect फरक मार्ग लिन्छ: अपरेटरले PKCS#12 फाइल आयात गर्छ जसमा प्रमाणपत्र र त्यसको निजी कुञ्जी हुन्छ, त्यसलाई यही उद्देश्यका लागि बनाइएको OpenVPN Certificate Store मा राख्छ, त्यसपछि बाह्य प्रमाणपत्र प्रोफाइलमा तोक्छ। यो जानाजान गरिएको आयात चरण हो, व्यक्तिगत भण्डारमा भएको कुराको स्वचालित खोज होइन। अर्को प्रयोजनका लागि स्थापना गरिएको प्रमाणपत्र क्लाइन्टको सूचीमा सजिलै देखिनेछ भनी कसैले ठान्दा यो भिन्नता महत्त्वपूर्ण हुन्छ।

आयातले कुञ्जी नीतिमा पनि परिणाम पार्छ, किनकि कुञ्जीलाई P12 फाइलमा निर्यात गर्नु भनेको निर्यात गर्न नसकिने कुञ्जीले रोक्नका लागि बनाइएको कुरा नै हो। यो कन्फिगरेसनको होइन, नीतिको प्रश्न हो, र कसैले आयात प्रयास गर्नुअघि यसको उत्तर पाउनुपर्छ।

कुञ्जीको नीतिसँग मिल्ने मार्ग छान्नुहोस्

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

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

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