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 उपलब्ध आहे असे असल्यास, प्रामाणिक पर्याय म्हणजे त्याला समर्थन देणारा मंजूर क्लायंट किंवा गेटवेच्या प्रमाणीकरण रचनेत बदल। दोन्हीपैकी कोणतेही स्थानिक उपाय नाही, आणि उलट दाखवल्यास केवळ संरचना करणाऱ्या व्यक्तीलाच पुन्हा तयार करता येईल असे कनेक्शन तयार होते।

निर्णय आणि रहस्ये नोंदवा

निवडलेली पद्धत, विश्वासाचा अँकर, तिच्याशी जुळणारी ओळख आणि बदल मंजूर करणारी व्यक्ती लिहा। ती नोंद घटना आढाव्याला हवी असते, आणि तीच पुढील अभियंत्याला तोच बंद मार्ग पुन्हा शोधण्यापासून रोखते।

तुमच्या टिपांमध्ये रहस्ये वेगळी ठेवा: खाते पासवर्ड, खाजगी कीचा पासफ्रेज आणि गेटवेची पूर्व-सामायिक की या तीन वेगळ्या गोष्टी आहेत, सेटिंग्ज स्क्रीन सर्वांना पासवर्ड म्हणत असली तरीही। त्या एकत्र करणे हाच की तिकिटात पोहोचण्याचा मार्ग आहे। तयार झालेले प्रोफाइल नवीन कनेक्शन आणि खाजगी संसाधनासाठी एका अनुप्रयोग विनंतीसह तपासा। पोहोचण्यायोग्य सेवेशिवाय यशस्वी टनेल हा अर्धवट निकाल आहे, आणि संसाधनही काम करेपर्यंत प्रोफाइल पूर्ण म्हणू नये।