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

कई प्रमाणपत्र, एक प्रस्तुत

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

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

प्रोफ़ाइल संपादित करने से पहले संग्रह जाँचें

उम्मीदवारों और उनके गुणों को उस संग्रह में सूचीबद्ध करें जिसका प्रोफ़ाइल वास्तव में उपयोग करता है। यहाँ कुछ भी निजी कुंजी निर्यात नहीं करता, और किसी प्रमाणपत्र को मशीन छोड़ने की आवश्यकता नहीं है:

Get-VpnConnection -Name 'Office' | Select-Object Name, TunnelType, AuthenticationMethod
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Issuer, Thumbprint, NotAfter, HasPrivateKey, EnhancedKeyUsageList

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

संपादन से पहले प्रोफ़ाइल और उसके दायरे की पुष्टि करें, क्योंकि LocalMachine में मौजूद मशीन प्रमाणपत्र, उपयोगकर्ता का EAP-TLS प्रमाणपत्र और किसी एप्लिकेशन का अपना निजी कुंजी संग्रह तीन अलग संदर्भ हैं। जब प्रबंधित प्रोफ़ाइल वहीं रहता है तो सभी-उपयोगकर्ता दायरा और प्रशासनिक संदर्भ उपयोग करें। मिलते-जुलते नाम वाली दूसरी प्रोफ़ाइल बनाना यह छिपा देता है कि कनेक्शन वास्तव में कौन-सा कॉन्फ़िगरेशन उपयोग करता है।

जारीकर्ता फ़िल्टर को ऑब्जेक्ट चाहिए

जारीकर्ता पैरामीटर प्रमाणपत्र ऑब्जेक्ट की अपेक्षा करता है, प्रदर्शित नाम की नहीं और खाली थंबप्रिंट स्ट्रिंग की भी नहीं। स्वीकृत प्राधिकरण का प्रमाणपत्र उस पथ से दें जिसकी आपने समीक्षा की है, उस संग्रह में जिसमें वह रहता है:

$issuerPath = Read-Host 'Certificate-provider path for the approved issuer CA'
$issuer = Get-Item -LiteralPath $issuerPath
Set-VpnConnection -Name 'Office' -MachineCertificateIssuerFilter $issuer

क्लाइंट के अपने लीफ प्रमाणपत्र, समान विषय वाले किसी दूसरे प्राधिकरण, या नए बनाए गए रूट को केवल इसलिए न बदलें कि पैरामीटर का प्रकार उसे स्वीकार करता है। दो प्राधिकरण एक ही विषय स्ट्रिंग साझा कर सकते हैं, और इसीलिए टेक्स्ट से अधिक ऑब्जेक्ट मायने रखता है। Microsoft cmdlet संदर्भ दोनों इनपुट प्रकारों का दस्तावेज़ीकरण करता है, और असफल प्रयास के बाद नहीं, पहले संपादन से पहले इसे पढ़ना उचित है।

उपयोग फ़िल्टर को OID स्ट्रिंग चाहिए

विस्तारित-कुंजी-उपयोग पैरामीटर OID स्ट्रिंग लेता है, और क्लाइंट प्रमाणीकरण का उद्देश्य है 1.3.6.1.5.5.7.3.2। इसे लागू करने से उम्मीदवार उन प्रमाणपत्रों तक सीमित हो जाते हैं जो यह उद्देश्य रखते हैं, जो क्लाइंट-प्रमाणीकरण परिनियोजन चाहता है:

Set-VpnConnection -Name 'Office' -MachineCertificateEKUFilter '1.3.6.1.5.5.7.3.2'

मान एक सरणी है, इसलिए जिस परिनियोजन को कई उद्देश्य चाहिए वह उन्हें सूची के रूप में देता है। फ़िल्टर जो नहीं कर सकता वह है प्रमाणपत्र में उद्देश्य जोड़ना: यह एक चयन अभिव्यक्ति है जिसका मूल्यांकन हस्ताक्षरित एक्सटेंशन के विरुद्ध होता है, और कोई फ़िल्टर उन्हें फिर से नहीं लिखता, इसलिए जिस प्रमाणपत्र में उद्देश्य नहीं है उसे फिर से नोंदणी से गुज़रना होगा।

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

सिद्ध करें कि क्लाइंट ने कौन-सा प्रमाणपत्र प्रस्तुत किया

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

सफल कमांड सफल प्रमाणीकरण नहीं है। दर्ज करने योग्य परिणाम यह है कि इच्छित प्रमाणपत्र प्रबंधित नीति के अंतर्गत प्रमाणीकृत हो रहा है जबकि हर असंबंधित प्रमाणपत्र उस पर निर्भर सेवाओं के लिए उपलब्ध रहता है। यदि विफलता दोनों फ़िल्टरों के बाद भी बनी रहती है, तो अगली जगह पूरी प्रोफ़ाइल नहीं बल्कि शेष उम्मीदवार हैं।

संबंधित लेख