IKEEXT सेवा बंद असताना L2TP/IPsec अयशस्वी होते
IKEEXT नाही तर IPsec नाही: इतर प्रकार अजूनही जोडत असताना L2TP आणि IKEv2 अयशस्वी होतात. सेवा तपासा आणि नंतर प्रोफाइल संपादित करण्यापूर्वी ती कशामुळे बंद झाली ते शोधा.
एक लॅपटॉप IKEv2 गेटवेपर्यंत पोहोचतो पण L2TP/IPsec गेटवेवर अयशस्वी होतो, आणि कोणतेही वापरकर्तानाव पाठवण्यापूर्वी त्रुटी येते। प्रोफाइल सहसा पहिला संशयित असतो आणि सहसा चुकीचा असतो. Windows IPsec की-देवाणघेवाण एका सेवेत चालवते, आणि ती सेवा बंद असताना अंगभूत क्लायंटकडे बोलणी करण्यासाठी स्टॅक नसतो. प्रोफाइलच्या एकाही फील्डला स्पर्श करण्यापूर्वी सेवा तपासा, आणि नंतर ती कशामुळे बंद झाली ते शोधा.
अयशस्वीतेमागील सेवा
सेवा सूचीत IKEEXT म्हणून दिसणारी IKE and AuthIP IPsec Keying Modules की-देवाणघेवाण करते आणि 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 स्टॅक शिल्लक राहत नाही.
- की किंवा प्रमाणपत्र साखळी गेटवे कॉन्फिगरेशनशी जुळते.
- अयशस्वी टप्पा प्रोफाइल संपादित होण्यापूर्वी नोंदवला गेला.