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 पुनः स्थापना गर्दा यो नक्सा मेटिन्छ र गेटवेमा बस्ने विफलता विरलै सुधार्छ।

कोड परिवर्तन हुन छोडेपछि, कुरा परिवर्तन गर्न छोड्नुहोस्। हालको कोड, सर्भर ठेगाना, प्रमाणीकरण विधि र प्रयासको समय रेकर्ड गर्नुहोस्, त्यसपछि त्यो रेकर्डलाई चलिरहेको क्लाइन्टसँग तुलना गर्नुहोस्। दुई रेकर्डबीचको फरक सामान्यतया मानिसहरूले पूर्वनिर्धारित रूपमा प्रयास गर्ने सुधारहरूको सूचीभन्दा सानो हुन्छ।