न्येटिभ 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 उपलब्ध छ भन्ने भएमा, इमानदार विकल्पहरू त्यसलाई समर्थन गर्ने स्वीकृत क्लाइन्ट वा गेटवेको प्रमाणीकरण डिजाइनमा परिवर्तन हुन्। दुवै स्थानीय उपाय होइनन्, र विपरीत देखाउँदा कन्फिगर गर्ने व्यक्तिले मात्र पुनः उत्पादन गर्न सक्ने जडान बन्छ।

निर्णय र रहस्यहरू लेख्नुहोस्

छानिएको विधि, विश्वास एङ्कर, त्यससँग मिल्ने पहिचान र परिवर्तन स्वीकृत गर्ने व्यक्ति लेख्नुहोस्। त्यही अभिलेख घटना समीक्षालाई चाहिन्छ, र त्यहीले अर्को इन्जिनियरलाई त्यही बन्द बाटो फेरि पत्ता लगाउनबाट रोक्छ।

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