टोकन हुँदा पनि OpenVPN ले अझै निजी कुञ्जी फाइल किन माग्छ

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

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

प्रोफाइलले भनेकै कारण क्लाइन्टले फाइल माग्छ

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

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

क्रमबद्ध पहिचान फरक मान हो

प्रमाणपत्रको पहिचान खोज प्रक्रियाले उत्पादन गर्ने लामो क्रमबद्ध शृंखला हो, र त्यो पुस्तकालयको मार्ग होइन, टोकनको PIN होइन र VPN खाताको नाम पनि होइन। यसमा प्रायः उद्धरण चाहिने अक्षरहरू हुन्छन्, र उद्धरण नभएको मान स्पष्ट त्रुटि बिना काटिन वा गलत पढिन सक्छ। टोकनले के प्रस्तुत गर्छ सूचीबद्ध गर्न क्लाइन्टकै पहिचान खोज विकल्प प्रयोग गर्नुहोस्, त्यसपछि चाहिएको प्रविष्टि ठ्याक्कै प्रतिलिपि गर्नुहोस्। सूचीको पहिलो वस्तु छान्नु भनेको उपकरणले अन्ततः गलत प्रमाणपत्र प्रस्तुत गर्ने बाटो हो।

खोजको नतिजाले अघिल्लो प्रश्नको पनि जवाफ दिन्छ: टोकन त्यो प्रदायकमार्फत देखिन्छ कि देखिँदैन। यदि यसले केही सूचीबद्ध गर्दैन भने समस्या VPN क्लाइन्टभन्दा माथि छ र मिडलवेयरको हो।

जडान गर्ने प्रक्रियाले टोकनसम्म पुग्नुपर्छ

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

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

टोकनले के प्रतिस्थापन गर्दैन

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

दर्ता अझै जारीकर्तासँग हुनुपर्छ, र गेटवेले अझै पहिचान अधिकृत गर्नुपर्छ।

स्वीकृतिका लागि चरणहरू अलग गर्नुहोस्: प्रदायक लोड हुन्छ, इच्छित प्रमाणपत्र भेटिन्छ, निजी कुञ्जी स्थानीय अधिकारसहित प्रयोग हुन्छ, VPN प्रमाणीकरण गर्छ, र स्रोत सञ्चालन सफल हुन्छ। पासवर्डभरि घुम्ने र क्रिप्टो स्ट्याक पुनःस्थापना गर्ने सट्टा असफल हुने पहिलो चरणमा रोकिनुहोस्।

संस्करण, मोड्युल स्वामित्व, छानिएको सार्वजनिक पहिचानकर्ता र सफा गरिएका त्रुटि अभिलेख गर्नुहोस्, र PIN तथा प्रमाण-पत्र बन्डल त्यो अभिलेखबाहिर राख्नुहोस्।