त्रुटि 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

सूची ठेगाना-समाधान बाइन्डिङ र तेस्रो-पक्ष फिल्टरका लागि पढ्नुहोस्। अक्षम बाइन्डिङ लक्षित मर्मत हो, जबकि फिल्टरको उपस्थिति त्यो सफ्टवेयरको मालिकलाई प्रश्न हो, सुरक्षा उत्पादन अक्षम गर्ने अनुमति होइन। सबै एडाप्टर मेटाउनु नै त्यो एक कदम हो जसले खराबी फर्किएमा आवश्यक पर्ने प्रमाण नष्ट गर्छ।

सुधारपछि त्यही प्रोफाइल फेरि प्रयास गर्नुहोस् र त्यसपछि दुई-क्लाइन्ट अवस्था दोहोर्याउनुहोस् यदि त्यही मूल लक्षण थियो भने, किनकि सफल पहिलो कनेक्सनले दोस्रो क्लाइन्टले उजागर गर्ने आवंटन समस्या लुकाउँछ। नोटलाई चार फिल्डमा राख्नुहोस्: कुन क्लाइन्ट, कुन बाइन्डिङ, कुन घटना र के बदलियो। प्रत्येक प्रयासमा एउटा तह बदल्नुहोस्, किनकि क्लाइन्ट सुधार र पूल परिवर्तन सँगै लागू गरेमा तिनलाई श्रेय दिन सकिँदैन, र अर्को खराबी उही भए पनि नयाँ देखिनेछ।

सम्बन्धित लेखहरू