Windows में VPN त्रुटि 720: पता पूल या क्लाइंट बाइंडिंग?
त्रुटि 720 का अर्थ है कि कनेक्शन को कभी भी उपयोगी पता नहीं मिला। एडाप्टर को फिर से इंस्टॉल करने से पहले एक होस्ट की विफलताओं को कई होस्ट की विफलताओं से अलग करें।
त्रुटि 720 क्रेडेंशियल स्वीकार होने के बाद दिखती है, इसलिए यह लोगों को पासवर्ड फ़ील्ड पर वापस भेजती है। कनेक्शन उस बिंदु तक पहुँचा जहाँ पते पर बातचीत होती है और उसे कोई पता नहीं मिला। दो बिल्कुल अलग विफलताएँ वही डायलॉग बनाती हैं: सर्वर के पास बाँटने को कुछ नहीं था, या यही क्लाइंट बातचीत पूरी नहीं कर सका। कुछ भी छूने से पहले इन दोनों को अलग करना मरम्मत का बड़ा हिस्सा है, और यह अंतर Microsoft के त्रुटि 720 समस्या-निवारण पृष्ठ पर प्रलेखित है।
डायलॉग क्या नहीं बताता
संदेश PPP बातचीत में विफलता का वर्णन करता है, और यह जानबूझकर अस्पष्ट है क्योंकि क्लाइंट नहीं देख सकता कि सर्वर ने क्यों मना किया। यह क्रेडेंशियल की त्रुटि नहीं है और टनल के एन्क्रिप्शन के बारे में कोई कथन नहीं है। इसका अर्थ है कि पता या बातचीत के पैरामीटर नहीं पहुँचाए गए।
सर्वर की ओर सामान्य कारण आवंटन है: बिना खाली पतों वाला स्थिर RRAS पूल, या ऐसा DHCP कॉन्फ़िगरेशन जिसका दायरा समाप्त या अगम्य हो, हर कोशिश करने वाले क्लाइंट में ठीक यही लक्षण पैदा करता है। क्लाइंट की ओर सामान्य कारण बाइंडिंग है। PPP ले जाने वाले WAN Miniport को सही घटकों से बाँधना होता है, और अक्षम बाइंडिंग या डाला गया नेटवर्क फ़िल्टर किसी दिखाई देने वाली डिवाइस समस्या के बिना बातचीत रोक सकता है। दोनों परिवारों को अलग सबूत चाहिए, और उनके बीच चुनने का सबसे तेज़ तरीका यह गिनना है कि कितने क्लाइंट प्रभावित हैं।
पहले आबादी अलग करें, फिर पूल
कोई भी कॉन्फ़िगरेशन पढ़ने से पहले प्रभावित क्लाइंट गिनें। एक साथ सबको लगने वाली विफलता सर्वर की स्थिति है, और एक मशीन का नेटवर्कों के बीच पीछा करने वाली विफलता क्लाइंट की स्थिति है। यह गिनती चैट चैनल में एक संदेश की कीमत पर होती है और एक दोपहर बचाती है।
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why 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सूची को पता-समाधान बाइंडिंग और तृतीय-पक्ष फ़िल्टर के लिए पढ़ें। अक्षम बाइंडिंग एक लक्षित मरम्मत है, जबकि फ़िल्टर की उपस्थिति उस सॉफ़्टवेयर के मालिक से सवाल है, सुरक्षा उत्पाद को अक्षम करने की अनुमति नहीं। सभी एडाप्टर हटाना ही वह कदम है जो उन सबूतों को नष्ट करता है जिनकी विफलता लौटने पर आपको आवश्यकता होगी।
सुधार के बाद वही प्रोफ़ाइल फिर आज़माएँ और फिर दो-क्लाइंट वाला मामला दोहराएँ यदि मूल लक्षण वही था, क्योंकि सफल पहला कनेक्शन उस आवंटन समस्या को छिपा देता है जिसे दूसरा क्लाइंट उजागर करता है। नोट को चार फ़ील्ड में रखें: कौन-सा क्लाइंट, कौन-सी बाइंडिंग, कौन-सी घटना और क्या बदला। हर प्रयास में एक परत बदलें, क्योंकि क्लाइंट सुधार और पूल परिवर्तन एक साथ लागू हों तो उन्हें श्रेय नहीं दिया जा सकता, और अगली विफलता वही होने पर भी नई दिखेगी।