IP पते के साथ त्रुटि 868? Windows पहले किसे हल करता है

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

क्लाइंट डायल करने से पहले नाम हल करता है

Windows का मूल VPN कनेक्शन अपनी प्रोफ़ाइल पढ़ता है, सर्वर पता हल करता है, टनल शुरू करता है और उसके बाद ही प्रमाणित करता है। त्रुटि 868 दूसरे चरण की है। चूँकि बाद के चरण कभी नहीं चलते, जब लुकअप पहले विफल हुआ हो तो संवाद क्रेडेंशियल समस्या जैसा दिख सकता है।

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

कौन-सा नाम, जब फ़ील्ड पता दिखाता है

दिखाए गए नाम के बजाय संग्रहीत मान पढ़ें। कनेक्शन का लेबल उसका सर्वर पता नहीं है, और मिलते-जुलते लेबल वाली दो प्रविष्टियाँ आपको गलत के पीछे भेजती हैं:

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

यदि प्रोफ़ाइल सभी उपयोगकर्ताओं के लिए बनाई गई है, तो उस दायरे को भी इससे पूछें -AllUserConnection। फिर ठीक वही मान हल करें जो कमांड ने छापा, उस नेटवर्क से जहाँ विफलता होती है। ऑपरेटर का प्रलेखित गेटवे उपयोग करें, ऐप्लिकेशन का आंतरिक नाम नहीं जो टनल उठने के बाद ही हल होता है। वह दूसरी क्वेरी अपेक्षित कारण से विफल होती है और डायल के बारे में आपको कुछ नहीं बताती:

Resolve-DnsName vpn.example.com

जब संग्रहीत मान वास्तव में संख्यात्मक हो, तो दूसरी जगह खोजें जहाँ क्लाइंट नाम पढ़ता है। EAP कॉन्फ़िगरेशन किसी सर्वर का संदर्भ दे सकता है, किसी अन्य टूल से आयातित प्रोफ़ाइल अपना मान ले जा सकती है, और पहले का इंस्टॉलर एक अनुलिपि प्रविष्टि छोड़ सकता है। संवाद का फ़ील्ड हमेशा एकमात्र इनपुट नहीं है।

Windows 7 का पुनःकनेक्ट पैटर्न

इस त्रुटि के पीछे का थ्रेड ऐसी मशीनों का वर्णन करता है जो एक बार जुड़ीं और फिर बाद के प्रयास में 868 के साथ विफल हुईं, बिना प्रोफ़ाइल में कुछ बदले। योगदानकर्ताओं ने बताया कि Remote Access Connection Manager सेवा को पुनः आरंभ करने या साइन आउट करके फिर साइन इन करने से कनेक्शन अस्थायी रूप से बहाल हुआ। ये वैकल्पिक उपाय हैं, सिद्ध मूल कारण नहीं।

उस पैटर्न को अलग परिकल्पना मानें। पुनः आरंभ क्लाइंट की स्थिति रीसेट करता है, इसलिए बाद की अस्थायी सफलता यह सिद्ध नहीं करती कि DNS रिकॉर्ड गलत था:

तालिका को निदान नहीं, बल्कि भेद करने वाले अवलोकनों का समूह पढ़ें। पहली पंक्ति नाम की समस्या है, दूसरी क्लाइंट की स्थिति है, और तीसरी ऐसी प्रोफ़ाइल है जो कभी सही नहीं थी। हर एक अलग व्यक्ति और अलग सुधार की ओर ले जाती है।

प्रशासक के लिए क्या एकत्र करें

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

पुराने बिल्ड का वैकल्पिक उपाय इस बात का प्रमाण है कि व्यवहार मौजूद था, यह वादा नहीं कि वही सेवा पुनः आरंभ मौजूदा मशीन को ठीक कर देगा। प्रलेखित होस्टनाम को शाब्दिक पते से बदलना भी मरम्मत नहीं है।

कुछ प्रोफ़ाइलें ऐसी सर्वर पहचान चाहती हैं जो कॉन्फ़िगर किए गए नाम से मेल खाए, इसलिए संख्यात्मक वैकल्पिक उपाय एक त्रुटि को दूसरी से बदल सकता है। यदि नाम रहना ही है, तो प्रोफ़ाइल पाठ नहीं, हल करने का मार्ग ठीक करें। किसी भी हाल में, आपने क्या बदला और क्यों, यह लिखें।