त्रुटी 720 क्रेडेन्शियल्स स्वीकारल्यानंतर दिसते, म्हणूनच ती लोकांना पासवर्ड फील्डकडे परत पाठवते. कनेक्शन त्या टप्प्यापर्यंत पोहोचले जिथे पत्त्यावर बोलणी होते आणि त्याला पत्ता मिळाला नाही. दोन पूर्णपणे वेगळ्या बिघाडी तोच डायलॉग तयार करतात: सर्व्हरकडे वाटण्यासाठी काही नव्हते, किंवा हाच क्लायंट बोलणी पूर्ण करू शकला नाही. काहीही हात लावण्यापूर्वी या दोन्ही वेगळे करणे हा दुरुस्तीचा मोठा भाग आहे, आणि हा फरक Microsoft च्या त्रुटी 720 समस्या-निवारण पानावर नोंदवलेला आहे.

डायलॉग काय सांगत नाही

संदेश PPP बोलणीतील बिघाड वर्णन करतो, आणि तो जाणूनबुजून अस्पष्ट आहे कारण सर्व्हरने का नकार दिला हे क्लायंटला दिसत नाही. ही क्रेडेन्शियल्सची त्रुटी नाही आणि टनेलच्या एन्क्रिप्शनबद्दलचे विधान नाही. याचा अर्थ पत्ता किंवा बोलणीचे पॅरामीटर पोहोचवले गेले नाहीत.

सर्व्हरच्या बाजूला नेहमीचे कारण वाटप आहे: रिकाम्या पत्त्यांशिवाय स्थिर RRAS पूल, किंवा ज्याची व्याप्ती संपली किंवा अगम्य आहे असे DHCP कॉन्फिगरेशन, प्रयत्न करणाऱ्या प्रत्येक क्लायंटमध्ये नेमके हेच लक्षण निर्माण करते. क्लायंटच्या बाजूला नेहमीचे कारण बाइंडिंग आहे. PPP वाहणारे WAN Miniport योग्य घटकांशी बांधलेले असले पाहिजे, आणि अक्षम बाइंडिंग किंवा आत घातलेला नेटवर्क फिल्टर कोणत्याही दिसणाऱ्या उपकरण समस्येशिवाय बोलणी थांबवू शकतो. या दोन्ही कुटुंबांना वेगळे पुरावे लागतात, आणि त्यांच्यात निवडण्याचा सर्वात वेगवान मार्ग म्हणजे किती क्लायंट प्रभावित आहेत हे मोजणे.

आधी लोकसंख्या वेगळी करा, मग पूल

कोणतेही कॉन्फिगरेशन वाचण्यापूर्वी प्रभावित क्लायंट मोजा. एकाच वेळी सर्वांना लागणारा बिघाड सर्व्हरची स्थिती आहे, आणि एका मशीनचा नेटवर्क्समधून मागोवा घेणारा बिघाड क्लायंटची स्थिती आहे. हे मोजणे चॅट चॅनेलमध्ये एका संदेशाच्या किमतीत होते आणि एक दुपार वाचवते.

ArtifactHow you get itWhat it rules outWhat it cannot rule out
Affected-client countOne message to the people who failed, or a search of today's ticketsA client-only fault, when every client failed within minutesWhich server-side component stopped allocating
RRAS event for one attemptGet-WinEvent on the System log, filtered to the allocation event idAn allocation failure, when no event matches that attemptA binding fault that appears later in the same negotiation
Hidden WAN Miniport bindingsGet-NetAdapter with hidden adapters, then the binding list on the returned nameA disabled ms_wanarp binding or an inserted filter on this clientPool exhaustion that would also have hit other clients
Free-address countThe RRAS pool view, or the DHCP scope statisticsA committed static range or an exhausted scopeWhy the address was not delivered to one specific client

मग एका अयशस्वी प्रयत्नाला सर्व्हरच्या स्वतःच्या नोंदीशी जोडा, कारण RRAS वाटप करू शकत नाही तेव्हा घटना नोंदवतो आणि ती घटना लक्षणाऐवजी बिघाडाचे नाव घेते. बिघाड विशिष्ट क्लायंटशी असेल तर सर्व्हर लॉग त्या प्रयत्नासाठी काहीही दाखवणार नाही, जे स्वतःच माहितीपूर्ण आहे. वाटप त्रुटी नसणे समस्या त्या क्लायंटच्या बोलणीपर्यंत मर्यादित करते आणि पुढे कोणते कमांड चालवायचे ते सांगते.

Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }

सर्व्हरची वाटप स्थिती वाचा

RRAS च्या बाजूला पुष्टी करा की प्रत्यक्षात कोणती वाटप पद्धत कॉन्फिगर आहे, आणि दस्तऐवज जी गृहीत धरतात ती नाही. स्थिर पूल आणि DHCP मार्फत पाठवलेले कॉन्फिगरेशन वेगवेगळ्या प्रकारे अयशस्वी होतात, आणि दुरुस्ती वापरात असलेल्याची आहे. स्थिर पूलमध्ये रिकामे पत्ते मोजा आणि प्रति वापरकर्ता वाटप शोधा जे अशी भाडेपट्टी ठेवतात जी कोणालाही आठवत नाही की कधी दिली, कारण मोठा दिसणारा पूल पूर्णपणे भरलेला असू शकतो. DHCP मध्ये तपासा की रिले सर्व्हरपर्यंत पोहोचतो आणि व्याप्तीत रिकाम्या भाडेपट्ट्या आहेत.

सामान्य क्लायंटनी संपवलेली व्याप्ती तोच 720 निर्माण करते जो चुकीच्या कॉन्फिगर केलेला पूल निर्माण करतो, आणि RRAS कन्सोल दोन्ही स्थितींमध्ये पूर्णपणे निरोगी दिसेल. पूल लहान व्याप्तींमध्ये विभागण्याच्या वारशाने मिळालेल्या उपायाला विरोध करा: मूळ सल्ला एका प्रशासकाचा निकाल वर्णन करत होता, आणि तो अशा वाटप बिघाडाची दुरुस्ती करत नाही ज्याला सर्व्हरच्या स्वतःच्या घटना थेट नाव देऊ शकतात.

क्लायंटची बाइंडिंग न तोडता वाचा

पुरावे एका क्लायंटकडे निर्देश करत असल्यास, स्टॅक पुन्हा इन्स्टॉल करण्याऐवजी लपलेला अडॅप्टर तपासा. पहिले कमांड WAN Miniport इंटरफेस आणि त्यांची नावे सूचीबद्ध करते; दुसरे त्याने परत दिलेले नाव घेते, मार्गदर्शकातून कॉपी केलेले नाही.

Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindings

यादी पत्ता-निराकरण बाइंडिंग आणि तृतीय-पक्ष फिल्टरसाठी वाचा. अक्षम बाइंडिंग ही लक्ष्यित दुरुस्ती आहे, तर फिल्टरची उपस्थिती त्या सॉफ्टवेअरच्या मालकाला प्रश्न आहे, सुरक्षा उत्पादन अक्षम करण्याची परवानगी नाही. सर्व अडॅप्टर हटवणे हेच एकमेव पाऊल आहे जे बिघाड परत आल्यास लागणारे पुरावे नष्ट करते.

दुरुस्तीनंतर तोच प्रोफाइल पुन्हा वापरून पहा आणि नंतर दोन-क्लायंट प्रकरण पुन्हा करा जर तेच मूळ लक्षण होते, कारण यशस्वी पहिले कनेक्शन दुसरा क्लायंट उघड करणारी वाटप समस्या लपवते. नोंद चार फील्डमध्ये ठेवा: कोणता क्लायंट, कोणती बाइंडिंग, कोणती घटना आणि काय बदलले. प्रत्येक प्रयत्नात एक थर बदला, कारण क्लायंट दुरुस्ती आणि पूल बदल एकत्र लागू केल्यास त्यांना श्रेय देता येत नाही, आणि पुढील बिघाड तोच असूनही नवीन दिसेल.

संबंधित लेख