L2TP/IPsec त्रुटि 789, 720 या 691: पहले सही चरण ठीक करें

Windows 11 L2TP/IPsec के हर चरण के लिए अलग संख्या बताता है, और वह संख्या विफलता को आँकने के बजाय चरण को दर्शाती है। 789 PPP लिंक होने से पहले विफल होता है, 720 लिंक उठते समय विफल होता है, और 691 लिंक उठने तथा क्रेडेंशियल अस्वीकार होने के बाद विफल होता है। उपयोगी निर्णय यह नहीं कि कौन-सा सुधार सबसे लोकप्रिय है; यह है कि कौन-सा चरण कोड साबित करता है कि आपने पहुँच लिया है। पहले वही पढ़ें, फिर हर प्रयास में एक परत बदलें ताकि अगला कोड आपको कुछ और बता सके।

कोड को चरण की तरह पढ़ें, खराबियों की सूची की तरह नहीं

L2TP कनेक्शन तय क्रम में तीन सीमाएँ पार करता है। IKE UDP 500 पर सुरक्षा संबंधों पर बातचीत करता है, NAT ट्रैवर्सल उस ट्रैफ़िक को UDP 4500 पर ले जाता है, और तभी L2TP सुरंग PPP सत्र ले जाती है जो उपयोगकर्ता को प्रमाणित करता है और पता सौंपता है।

यही क्रम बदलते त्रुटि कोड को उपयोगी प्रमाण बनाता है। 789 से 720 पर जाने का अर्थ है कि IPsec अब बातचीत कर रहा है और विफलता लिंक स्थापना पर चली गई है। 720 से 691 पर जाने का अर्थ है कि लिंक उठ गया और गेटवे ने पहचान अस्वीकार कर दी। यदि आप पाँच सुधार एक साथ लागू करते हैं, तो वह संकेत खो जाता है और आप नहीं बता सकते कि कौन-सा बदलाव काम कर गया।

789: पथ और स्थानीय नीति में से चुनें

कोड 789 प्रारंभिक सुरक्षा वार्ता के दौरान प्रसंस्करण त्रुटि है। IPsec ने कभी कोई उपयोगी संबंध नहीं बनाया, इसलिए खाते का अभी परीक्षण नहीं हुआ है। पथ और साझा कुंजी से शुरू करें, खाते से नहीं।

पुष्टि करें कि UDP 500 और UDP 4500 सर्वर तक पहुँचते हैं और पूर्व-साझा कुंजी बाइट दर बाइट मेल खाती है, जिसमें अक्षरों का आकार और अंत में रिक्त स्थान शामिल हैं। यदि सर्वर NAT के पीछे है, तो Windows को दस्तावेज़ित रजिस्ट्री मान भी चाहिए हो सकता है। जब सर्वर NAT के पीछे हो तो 1 और जब दोनों सिरे हों तो 2 उपयोग करें, फिर पुनः आरंभ करें क्योंकि नीति एजेंट मान को प्रारंभ पर पढ़ता है:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

अडैप्टर की भारी मरम्मत दूसरी शाखा की है। Wi-Fi उपकरण और WAN मिनीपोर्ट हटाकर फिर हार्डवेयर के लिए स्कैन करना तब उचित है जब स्थानीय IPsec स्टैक स्वयं क्षतिग्रस्त हो और अन्य VPN प्रकार भी उसी तरह विफल हों। जब केवल एक L2TP सर्वर विफल हो और हर अन्य नेटवर्क पथ काम करे तो यह व्यर्थ प्रयास है।

720: इस अडैप्टर और सर्वर पूल में से चुनें

त्रुटि 720 बताती है कि दूरस्थ कंप्यूटर से कनेक्शन स्थापित नहीं हो सका, और यह IPsec सफल होने के बाद दिखाई देती है। सुरंग इंटरफ़ेस उठाने या पता पाने के बिंदु तक पहुँची और फिर रुक गई। इससे यह स्थानीय अडैप्टर का प्रश्न या सर्वर क्षमता का प्रश्न बन जाता है।

निर्णय के लिए प्रभाव-त्रिज्या का उपयोग करें। एक Windows मशीन का विफल होना खराब WAN मिनीपोर्ट, रुकी हुई Remote Access सेवा या खराब कनेक्शन प्रोफ़ाइल की ओर इशारा करता है। कई क्लाइंट का एक साथ विफल होना सर्वर की ओर इशारा करता है: समाप्त पता पूल, रुकी हुई RRAS सेवा या ऐसा पूल जो अब क्लाइंट सबनेट से मेल नहीं खाता। दूसरी ओर बदलने से पहले उस ओर को ठीक करें जिसकी ओर पैटर्न इशारा करता है।

एक-क्लाइंट शाखा में, WAN मिनीपोर्ट एक बार हटाएँ और हार्डवेयर परिवर्तनों के लिए स्कैन करें, फिर पुनः आरंभ करें और दोबारा प्रयास करें। सर्वर शाखा में, क्लाइंट के बजाय पूल और सेवा की स्थिति जाँचें, क्योंकि काम करने वाला अडैप्टर फिर से इंस्टॉल करने से ऐसा पता नहीं बन सकता जो सर्वर के पास न हो।

691: क्रेडेंशियल और रुके हुए सहायक में से चुनें

कोड 691 प्रमाणीकरण का अस्वीकार है, और यह वह कोड है जिसे सबसे अधिक गलत पासवर्ड के रूप में गलत पढ़ा जाता है। सुरंग ऊपर है, गेटवे ने पहचान देखी और उस पहचान को अस्वीकार कर दिया। कारण अब भी पासवर्ड फ़ील्ड के बाहर हो सकता है।

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

जो शाखा लोग चूकते हैं वह रुकी हुई सहायक सेवा है। जब किसी विक्रेता का क्लाइंट गेटवे तक क्रेडेंशियल भेजने के लिए अपनी सेवा पर निर्भर करता है, तो अक्षम या क्रैश हुई सेवा पासवर्ड सही होने पर भी 691 पैदा करती है। खाता रीसेट करने से पहले विक्रेता सेवा की स्थिति जाँचें, विशेषकर पुनः आरंभ या अपडेट के बाद।

शाखाओं को अलग करने के लिए, वही उपयोगकर्ता नाम किसी दूसरी काम करने वाली VPN प्रोफ़ाइल या RADIUS परीक्षण खाते पर आज़माएँ। यदि वह सफल हो, तो क्रेडेंशियल ठीक है और स्थानीय क्लाइंट पथ संदिग्ध है। यदि वह उसी तरह विफल हो, तो समस्या खाता या गेटवे नीति है।

हर प्रयास में एक परत बदलें

बाहर से अंदर काम करें: पहुँच और NAT ट्रैवर्सल, फिर पूर्व-साझा कुंजी, फिर स्थानीय अडैप्टर स्टैक, फिर क्रेडेंशियल, फिर सर्वर पूल और सेवाएँ। यह क्रम उन चरणों का पालन करता है जिन्हें कोड वर्णित करते हैं और हर परिणाम को एक बदलाव के लिए जिम्मेदार रखता है।

हर प्रयास से पहले और बाद के कोड, क्लाइंट बिल्ड, और सर्वर या क्लाइंट बदला गया या नहीं, का छोटा लॉग रखें। 789, फिर 720, फिर 691 जैसा क्रम प्रगति का नक्शा है; वही कोड दो बार आने का अर्थ है कि अंतिम बदलाव ने उस चरण को संबोधित नहीं किया। Windows को फिर से इंस्टॉल करने से यह नक्शा मिट जाता है और गेटवे पर रहने वाली विफलता शायद ही ठीक होती है।

जब कोड बदलना बंद कर दे, तो चीज़ें बदलना बंद कर दें। वर्तमान कोड, सर्वर पता, प्रमाणीकरण विधि और प्रयास का समय दर्ज करें, फिर उस रिकॉर्ड की तुलना काम करने वाले क्लाइंट से करें। दोनों रिकॉर्ड के बीच अंतर आमतौर पर उन सुधारों की सूची से छोटा होता है जिन्हें लोग डिफ़ॉल्ट रूप से आज़माते हैं।