टोकन असूनही OpenVPN अजूनही खाजगी की फाइल का मागतो
प्रोफाइलने कदाचित टोकनचे नाव कधीच घेतले नाही. प्रदात्याच्या लायब्ररीला प्रमाणपत्राच्या क्रमबद्ध ओळखीपासून वेगळे करा, नंतर जोडणी करणाऱ्या प्रक्रियेतून चाचणी करा.
तुम्ही टोकन लावता, प्रदात्याचे स्वतःचे साधन ते पाहते, आणि VPN क्लायंट अजूनही खाजगी की फाइल मागतो. ती विनंती टोकन समर्थित नाही याचा पुरावा नाही. सामान्यतः याचा अर्थ प्रोफाइलने क्लायंटला टोकन वापरण्यास कधीच सांगितले नाही, म्हणून ते डीफॉल्टने अपेक्षित प्रमाणपत्र आणि की इनपुटकडे परत गेले.
ती परती थांबण्यापूर्वी दोन वेगळी मूल्ये बरोबर असावीत: टोकन उघड करणारा प्रदाता, आणि त्यातील प्रमाणपत्राची ओळख. ही वेगवेगळ्या पर्यायांनी दिली जातात आणि त्यांचा गोंधळ करणे सोपे आहे.
प्रोफाइल असे सांगत असल्याने क्लायंट फाइल मागतो
डीफॉल्ट प्रोफाइल प्रमाणपत्र फाइल आणि खाजगी की फाइल, किंवा एकच PKCS#12 बंडल अपेक्षित करते. ती इनपुट नसल्यास क्लायंटकडे लोड करण्यास काहीच नसते आणि फाइल नसल्यासारखेच वागते, म्हणून लक्षण गहाळ यंत्रणा नव्हे तर तुटलेला मार्ग म्हणून वाचले जाते. PKCS#11 मार्ग ती इनपुट पूरक करण्याऐवजी बदलतो, म्हणून की फाइल अजूनही नामनिर्देशित करणारे प्रोफाइल फाइल वापरत राहील. फाइल इनपुट जाणीवपूर्वक काढा आणि टोकनला दोन्ही अर्धे पुरवू द्या.
प्रदाता पर्याय मिडलवेअर लायब्ररीचे नाव देतो, उपकरणाचे नाही आणि प्रमाणपत्राचे नाही. पॅकेज केलेला क्लायंट ती लायब्ररी लोड करू शकतो का हे ते कसे तयार झाले यावर अवलंबून आहे, ज्यात काही बिल्ड सक्षम करतात आणि इतर वगळतात अशा ऐच्छिक p11-kit समर्थनाचा समावेश आहे. सामान्य ट्युटोरियल तुमच्या पॅकेजमध्ये कोणती रचना आहे हे सांगू शकत नाही.
क्रमबद्ध ओळख हे वेगळे मूल्य आहे
प्रमाणपत्राची ओळख शोध प्रक्रियेने तयार केलेली लांब क्रमबद्ध शृंखला आहे, आणि ती लायब्ररीचा मार्ग नाही, टोकनचा PIN नाही किंवा VPN खात्याचे नाव नाही. त्यात बऱ्याचदा अवतरणे आवश्यक असलेली अक्षरे असतात, आणि अवतरणांशिवाय मूल्य स्पष्ट त्रुटीशिवाय कापले जाऊ शकते किंवा चुकीचे वाचले जाऊ शकते. टोकन काय उघड करते हे सूचीबद्ध करण्यासाठी क्लायंटच्या स्वतःच्या ओळख शोध पर्यायाचा वापर करा, नंतर इच्छित नोंद अगदी तशीच कॉपी करा. सूचीतील पहिली वस्तू निवडणे हा तो मार्ग आहे ज्याने उपकरण शेवटी चुकीचे प्रमाणपत्र सादर करते.
शोधाचे आउटपुट पूर्वीच्या प्रश्नाचेही उत्तर देते: टोकन त्या प्रदात्यामार्फत अजिबात दिसते का. जर ते काहीही सूचीबद्ध करत नसेल, तर समस्या VPN क्लायंटच्या वर आहे आणि मिडलवेअरची आहे.
जोडणी करणाऱ्या प्रक्रियेने टोकनपर्यंत पोहोचले पाहिजे
तुमच्या डेस्कटॉप सत्रात काम करणारे टोकन ऑपरेशन सिस्टम सेवेबद्दल काहीही सिद्ध करत नाही. सेवा दुसऱ्या वापरकर्त्याप्रमाणे, वेगळ्या माउंट नामस्थानात, प्रदात्याची लायब्ररी वगळणाऱ्या मॉड्यूल मार्गासह, किंवा उपकरण नोड उघडण्याच्या परवानगीशिवाय चालू शकते. प्रत्यक्षात कोणती प्रक्रिया कनेक्शन धरून आहे ते ओळखा आणि त्याच संदर्भातून चाचणी करा.
PIN हाताळणी स्वतःच्या निर्णयास पात्र आहे. संदर्भ अंमलबजावणी PIN कॅश आणि संरक्षित प्रमाणीकरण मार्ग देते, आणि दोन्ही यासाठी आहेत की ऑपरेटरने नवीन कार्यप्रवाह शोधण्याऐवजी एक निवडावा. देखरेख नसलेल्या गरजेचे सामायिक प्रोफाइलमधील साध्या मजकुराच्या PIN मध्ये रूपांतर करू नका, कारण ते सोयीसाठी टोकनच्या संरक्षणाची देवाणघेवाण करते. जिथे टोकन की निर्यात प्रतिबंधित करते तिथे स्वाक्षरी उपकरणावरच होते आणि PIN हेच एकमेव स्थानिक रहस्य असते. त्याला त्या काळजीने हाताळा जी ते अपेक्षित करते.
टोकन कशाची जागा घेत नाही
टोकन तैनात धोरणानुसार क्लायंटचे प्रमाणीकरण करते, आणि ते सर्व्हरवरील क्लायंटच्या तपासण्यांची जागा घेत नाही. यशस्वीरित्या निवडलेले प्रमाणपत्र अनपेक्षित गेटवे प्रमाणपत्र स्वीकारण्याची परवानगी नाही, आणि दोन्ही पडताळण्या विरुद्ध दिशांचे संरक्षण करतात.
नोंदणी अजूनही जारीकर्त्याकडे व्हायला हवी, आणि गेटवेने अजूनही ओळख अधिकृत करायला हवी.
स्वीकृतीसाठी टप्पे वेगळे करा: प्रदाता लोड होतो, इच्छित प्रमाणपत्र सापडते, खाजगी की स्थानिक अधिकृततेसह वापरली जाते, VPN प्रमाणीकरण करते, आणि संसाधन क्रिया यशस्वी होते. संकेतशब्दांमध्ये फिरून क्रिप्टो स्टॅक पुन्हा स्थापित करण्याऐवजी अयशस्वी होणाऱ्या पहिल्या टप्प्यावर थांबा.
आवृत्त्या, मॉड्यूल मालकी, निवडलेला सार्वजनिक ओळखकर्ता आणि स्वच्छ केलेल्या त्रुटी नोंदवा, आणि PIN व क्रेडेन्शियल बंडल त्या नोंदीबाहेर ठेवा.