टोकन होने पर भी OpenVPN अब भी निजी कुंजी फ़ाइल क्यों माँगता है

आप टोकन लगाते हैं, प्रदाता का अपना उपकरण उसे देखता है, और VPN क्लाइंट अब भी निजी कुंजी फ़ाइल माँगता है। यह अनुरोध इस बात का प्रमाण नहीं है कि टोकन समर्थित नहीं है। आमतौर पर इसका अर्थ है कि प्रोफ़ाइल ने क्लाइंट को कभी टोकन के उपयोग के लिए नहीं कहा, इसलिए वह डिफ़ॉल्ट रूप से अपेक्षित प्रमाणपत्र और कुंजी इनपुट पर लौट गया।

उस वापसी के रुकने से पहले दो अलग मान सही होने चाहिए: टोकन को प्रस्तुत करने वाला प्रदाता, और उसके भीतर प्रमाणपत्र की पहचान। ये अलग-अलग विकल्पों से दिए जाते हैं और इन्हें मिलाना आसान है।

क्लाइंट फ़ाइल माँगता है क्योंकि प्रोफ़ाइल ऐसा कहती है

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

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

क्रमबद्ध पहचान एक अलग मान है

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

खोज का आउटपुट एक पूर्व प्रश्न का भी उत्तर देता है: क्या टोकन उस प्रदाता के माध्यम से बिल्कुल दिखाई देता है। यदि वह कुछ भी सूचीबद्ध नहीं करता, तो समस्या VPN क्लाइंट से ऊपर है और मिडलवेयर की है।

जोड़ने वाली प्रक्रिया को टोकन तक पहुँचना चाहिए

आपके डेस्कटॉप सत्र में काम करने वाला टोकन संचालन सिस्टम सेवा के बारे में कुछ भी सिद्ध नहीं करता। सेवा किसी अन्य उपयोगकर्ता के रूप में, किसी भिन्न माउंट नामस्थान में, ऐसे मॉड्यूल पथ के साथ जो प्रदाता की लाइब्रेरी छोड़ देता है, या उपकरण नोड खोलने की अनुमति के बिना चल सकती है। पहचानें कि वास्तव में कौन-सी प्रक्रिया कनेक्शन रखती है और उसी संदर्भ से परीक्षण करें।

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

टोकन किसका स्थान नहीं लेता

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

नामांकन अब भी जारीकर्ता के पास होना चाहिए, और गेटवे को अब भी पहचान को अधिकृत करना चाहिए।

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

संस्करण, मॉड्यूल स्वामित्व, चुना गया सार्वजनिक पहचानकर्ता और साफ़ किए गए त्रुटियाँ दर्ज करें, और PIN तथा क्रेडेंशियल बंडल उस रिकॉर्ड से बाहर रखें।