IKEEXT सेवा बंद होने पर L2TP/IPsec विफल होता है

एक लैपटॉप IKEv2 गेटवे तक पहुँचता है पर L2TP/IPsec गेटवे पर विफल हो जाता है, और त्रुटि कोई भी उपयोगकर्ता नाम भेजे जाने से पहले आती है। प्रोफ़ाइल आमतौर पर पहला संदिग्ध होता है और आमतौर पर गलत। Windows IPsec कुंजी-विनिमय को एक सेवा में चलाता है, और जब तक वह सेवा बंद है, अंतर्निहित क्लाइंट के पास बातचीत करने के लिए कोई स्टैक नहीं होता। प्रोफ़ाइल के एक भी फ़ील्ड को छूने से पहले सेवा की पुष्टि करें, फिर पता लगाएँ कि इसे किसने बंद किया।

विफलता के पीछे की सेवा

IKE and AuthIP IPsec Keying Modules, जो सेवा सूची में IKEEXT के रूप में दिखती है, कुंजी-विनिमय करती है और Windows में UDP 500 और 4500 सॉकेट रखती है। इसे बंद करें तो L2TP/IPsec और IKEv2 दोनों अपना वार्ताकार खो देते हैं, जबकि PPTP और SSTP काम करते रह सकते हैं क्योंकि वे इस पर निर्भर नहीं हैं। यही विभाजन बताता है कि उपयोगकर्ता क्यों बता सकता है कि एक VPN प्रकार काम करता है और दूसरा उसी मशीन पर मृत है। सेवा ऑपरेटिंग सिस्टम का हिस्सा है, इसलिए कोई प्रोफ़ाइल सेटिंग उसका स्थान नहीं ले सकती।

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

सेवा को बिना अनुमान लगाए वापस लाएँ

सेवा प्रबंधक से दो प्रश्न पूछें: स्टार्टअप प्रकार क्या है, और वर्तमान स्थिति क्या है। पहला बताता है कि सेवा पुनः आरंभ के बाद लौटेगी या नहीं; दूसरा बताता है कि वह अभी चल रही है या नहीं। दोनों क्वेरी उन्नत कमांड प्रॉम्प्ट से चलाएँ ताकि वही शेल बाद में सेटिंग बदल सके।

sc qc ikeext
sc query ikeext

स्टार्टअप प्रकार Disabled पूरे लक्षण की व्याख्या करता है, और समाधान यह है कि इसे वापस Automatic पर रखें और सेवा शुरू करें। Services कंसोल में प्रविष्टि अपने प्रदर्शित नाम, IKE and AuthIP IPsec Keying Modules, के साथ दिखती है, इसलिए उस सूची में IKEEXT खोजने से कुछ नहीं मिलता। यदि सेवा तभी शुरू हुई जब एक विफल कनेक्शन पहले ही चल चुका था तो पुनः आरंभ करें, क्योंकि उस क्रम में आरंभ किया गया स्टैक ऐसे तरीकों से विफल हो सकता है जो असंबंधित लगते हैं।

sc config ikeext start= auto
net start ikeext

इसे फिर क्या बंद करता है

कुछ तृतीय-पक्ष VPN सुइट अपना IPsec कार्यान्वयन लाते हैं और इंस्टॉलेशन के दौरान IKEEXT बंद कर देते हैं, जिसके बाद Windows क्लाइंट काम करना बंद कर देता है। दूसरा उत्पाद हटाने से उन मशीनों पर L2TP/IPsec बहाल हुआ जहाँ प्रोफ़ाइल संपादन से कुछ नहीं मिला था, और टकराव वाले घटक के बिना पुनः इंस्टॉल करने से भी वही हुआ। सेवा इंस्टॉलेशन के समय बंद की गई थी, उपयोगकर्ता ने उसे बदला नहीं।

ग्रुप पॉलिसी भी स्टार्टअप प्रकार को स्थिर कर सकती है; ऐसे में स्थानीय परिवर्तन अगली रीफ़्रेश पर वापस ले लिया जाता है और पॉलिसी का स्वामी प्रशासक ही उसे बदल सकता है। स्टार्टअप प्रकार पुनः आरंभ से पहले, बाद में और दूसरे उत्पाद के अपडेट के बाद हर बार तिथि के साथ दर्ज करें। जो मान बार-बार Disabled पर लौटता है वह अपने स्वामी को अनुमान से नहीं बल्कि पैटर्न से प्रकट करता है।

पहले चरण पढ़ें, फिर लॉग

जब सेवा चल रही हो, विफलता का चरण तय करता है कि आगे कहाँ देखना है। IKE के दौरान रुकना आमतौर पर इसका अर्थ है कि UDP 500 या 4500 कभी सर्वर तक नहीं पहुँचा, या सर्वर मेल खाती एनकैप्सुलेशन सेटिंग के बिना NAT के पीछे है। क्रेडेंशियल प्रॉम्प्ट तक पहुँचकर वहीं विफल होना PPP प्रमाणीकरण की समस्या है, IPsec की नहीं। ऐसा टनल जो ऊपर आए और कहीं न पहुँचे, रूटिंग या विभाजित टनल की खराबी है, और उन तीन में से केवल पहला VPN प्रोफ़ाइल में रहता है।

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

हर प्रयास के लिए विफल चरण, त्रुटि पाठ और समय-टिकट दर्ज करें। ये तीन फ़ील्ड पहुँच की समस्या को प्रमाणीकरण की समस्या और रूटिंग की समस्या से अलग करते हैं, और अगले परिवर्तन को अनुमान के बजाय निर्णय बना देते हैं।

स्थानीय मरम्मत क्या सिद्ध नहीं कर सकती

सेवा बहाल करना रास्ते का वह आधा हिस्सा ठीक करता है जो लैपटॉप पर है। काम करती सेवा केवल स्थानीय आधा सिद्ध करती है: दूर का सिरा अभी भी चुना गया प्रस्ताव, दिए गए क्रेडेंशियल और वह स्रोत पता स्वीकार करेगा जहाँ से पैकेट आता है। लैपटॉप पर किया गया कुछ भी ऐसी फ़ायरवॉल की भरपाई नहीं करता जो UDP 500 को साथी तक पहुँचने से पहले फेंक देती है। सफल सेवा स्थिति एक पूर्वशर्त है, टनल के ऊपर आने का प्रमाण नहीं।

पोर्ट मुक्त करने के लिए IKEEXT बंद करना केवल तभी उचित है जब आप स्वीकार करें कि Windows के IPsec VPN काम करना बंद कर देंगे। यह पोर्ट के टकराव को उस सुविधा को हटाकर हल करता है जिसे पोर्ट चाहिए था, और यह शायद ही वह अदला-बदली हो जो उपयोगकर्ता का इरादा था। कुछ भी बदलने से पहले पुष्टि करें कि सेवा मौजूद है, Automatic पर सेट है और चल रही है, दूसरा IPsec स्टैक स्थापित नहीं है, और पूर्व-साझित कुंजी या प्रमाणपत्र श्रृंखला गेटवे से मेल खाती है।

• IKEEXT मौजूद है, Automatic पर सेट है और क्लाइंट के जुड़ने से पहले चल रही है।
• कोई और चीज़ UDP 500 या 4500 को नहीं रोकती।
• पुराने क्लाइंट से दूसरा IPsec स्टैक नहीं बचता।
• कुंजी या प्रमाणपत्र श्रृंखला गेटवे कॉन्फ़िगरेशन से मेल खाती है।
• विफल चरण प्रोफ़ाइल संपादित होने से पहले दर्ज किया गया।