Windows IKEv2 में PSK फ़ील्ड बिल्कुल क्यों नहीं है

गेटवे का दस्तावेज़ कहता है कि पहले से साझा की गई कुंजी क्लाइंट में डाली जाती है, पर Windows प्रोफ़ाइल में उसके लिए कोई फ़ील्ड नहीं है। यह अंतराल ऐसी बग नहीं है जिसे पासवर्ड बॉक्स में कुंजी लिखकर टाला जाए। यह प्रोटोकॉल जो कर सकता है और कोई विशेष कार्यान्वयन जो देता है, उनके बीच का अंतर है।

प्रोटोकॉल क्षमता क्लाइंट समर्थन नहीं है

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

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

प्रमाणपत्र, EAP या L2TP में से चुनें

यदि गेटवे ऑपरेटर प्रमाणपत्र प्रमाणीकरण स्वीकार करे, तो वही आमतौर पर सबसे स्वच्छ गंतव्य है: क्लाइंट प्रमाणपत्र प्रस्तुत करता है, गेटवे उसे विश्वसनीय जारीकर्ता के सामने सत्यापित करता है, और प्रोफ़ाइल में कोई साझा रहस्य नहीं बचता जिसे कोई कॉपी करे। इसके लिए नामांकन, विश्वसनीय श्रृंखला और ऐसा गेटवे कॉन्फ़िगरेशन चाहिए जो प्रमाणपत्र को प्राधिकरण निर्णय से जोड़े।

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

जाँचें कि गेटवे क्या स्वीकार करेगा

ऑपरेटर से पूछें कि रिमोट-एक्सेस सेवा आज कौन-सी प्रमाणीकरण विधियाँ देती है, यह नहीं कि उत्पाद सामान्य रूप से किन्हें समर्थन देता है। केवल PSK के लिए कॉन्फ़िगर की गई IKEv2 सेवा यह कहकर प्रमाणपत्र स्वीकार नहीं करेगी कि क्लाइंट को वह पसंद है।

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

प्रोफ़ाइल की प्रमाणीकरण विधि और प्रमाणपत्र भंडार साथ पढ़ें। पीछे कोई उपयोगी प्रमाणपत्र न होने पर EAP पर सेट प्रोफ़ाइल ऐसे विफल होती है जो सर्वर समस्या जैसा दिखता है।

यदि उत्तर यह है कि केवल PSK उपलब्ध है, तो ईमानदार विकल्प हैं इसे समर्थन देने वाला स्वीकृत क्लाइंट या गेटवे के प्रमाणीकरण डिज़ाइन में बदलाव। इनमें से कोई स्थानीय समाधान नहीं है, और विपरीत दिखावा ऐसा कनेक्शन बनाता है जिसे केवल वही व्यक्ति दोहरा सकता है जिसने इसे कॉन्फ़िगर किया।

निर्णय और रहस्य दर्ज करें

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

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