Windows VPN त्रुटि 691: कौन-सी जाँच वास्तव में विफल हुई?
एक संवाद कई अलग-अलग अस्वीकृतियों को समेटता है। खाता रीसेट करने से पहले शाब्दिक लॉगिन, संग्रहीत क्रेडेंशियल और सर्वर के निर्णय की जाँच करें।
Windows ऐसे पासवर्ड को अस्वीकार करता है जिसे उसने एक मिनट पहले कहीं और स्वीकार किया था, इसलिए खाता टूटा हुआ लगता है जबकि प्रयास का मूल्यांकन कभी नहीं हुआ। त्रुटि 691 का अर्थ है कि प्रमाणीकरण के दौरान कनेक्शन अस्वीकार कर दिया गया, और क्लाइंट वही पाठ दिखाता है चाहे रहस्य गलत हो, खाता नाम किसी अप्रत्याशित पहचान में बदल गया हो, या सर्वर-पक्ष की नीति ने कनेक्शन अस्वीकार कर दिया हो। तीन अलग-अलग मरम्मतें एक ही संदेश साझा करती हैं, इसलिए रीसेट कभी मदद करता है और कभी कुछ भी नहीं बदलता। उस हिस्से से शुरू करें जिसे आप अकेले जाँच सकते हैं: क्लाइंट द्वारा भेजी गई सटीक स्ट्रिंग और वह क्रेडेंशियल स्टोर जिससे उसने इसे लिया। फिर सर्वर से पूछें कि उसने कौन-सा निर्णय दर्ज किया, क्योंकि संवाद एक अस्वीकृति है, निदान नहीं।
अस्वीकार होने के तीन तरीके, एक संवाद
गलत रहस्य इस संवाद तक पहुँचने का केवल पहला रास्ता है। खाता नाम ऐसी पहचान में बदल सकता है जिसका आपने इरादा नहीं किया, खाते के पास डायल-इन अनुमति न हो, या पासवर्ड स्वीकार होने के बाद सर्वर की कोई शर्त कनेक्शन अस्वीकार कर सकती है। इनमें से हर स्थिति वही क्लाइंट पाठ पैदा करती है, और हर एक की अपनी मरम्मत है।
इसीलिए रीसेट सोमवार को काम करता दिखता है और मंगलवार को कुछ नहीं करता। संवाद को निदान नहीं, अस्वीकृति के रूप में पढ़ें, और खाते को छूने से पहले प्रोफ़ाइल नाम तथा विफलता का स्थानीय समय लिख लें।
ये तीन श्रेणियाँ अलग-अलग परतों पर भी विफल होती हैं। गलत रहस्य पहचान-प्रमाण में विफल होता है, गलत खाता स्वरूप खोज में विफल होता है, और नीति की शर्त पहचान सिद्ध होने के बाद प्राधिकरण में विफल होती है। केवल पहली पासवर्ड बदलकर ठीक होती है। बाकी दो के लिए ऐसा व्यक्ति चाहिए जिसके पास सर्वर के निर्णय-रिकॉर्ड तक पहुँच हो, इसलिए अगला कदम एक और रीसेट नहीं, सूचना का अनुरोध है।
क्लाइंट ने वास्तव में क्या भेजा
गेटवे चलाने वाले के साथ स्वीकृत खाता प्रारूप की पुष्टि करें, क्योंकि खाली उपयोगकर्ता नाम, डोमेन-योग्य नाम और उपयोगकर्ता प्रमुख नाम अलग-अलग खाता संदर्भों में बदल सकते हैं। इनमें से केवल एक ही वह पहचान हो सकती है जिसके पास अनुमति है। पाँचवें प्रयास के बाद नहीं, पहले प्रयास से पहले पूछें कि गेटवे कौन-सा रूप अपेक्षित करता है, और जाँचें कि क्लाइंट आपके टाइप किए क्रेडेंशियल के बजाय संग्रहीत क्रेडेंशियल का पुनः उपयोग कर रहा है या नहीं।
Windows मशीन पर दो केवल-पढ़ने वाली क्वेरी प्रोफ़ाइल और कोई भी कैश किया गया क्रेडेंशियल दिखाती हैं जो संवाद को हरा सकता है। इनमें से कोई भी सर्वर को डायल नहीं करती:
Get-VpnConnection -Name 'Corp VPN' | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod
cmdkey /list | Select-String -Pattern 'corp' -SimpleMatchपासवर्ड को दस्तावेज़ से कॉपी किए गए पाठ के बजाय डेटा की तरह मानें। किसी स्क्रिप्ट से गुज़री वैल्यू में ऐसे एस्केप अक्षर हो सकते हैं जो कभी रहस्य का हिस्सा नहीं थे, और कॉन्फ़िगरेशन निर्यात ने उसे उद्धरण चिह्नों में रखा हो सकता है। फ़िट कराने के लिए हर विशेष अक्षर हटाना वास्तविक मान खोजने से अलग बदलाव है, इसलिए पहले वास्तविक मान स्थापित करें।
नीति का निर्णय लें, रीसेट नहीं
नेटवर्क नीति सर्वर का उपयोग करने वाले दूरस्थ-पहुँच परिनियोजन में दो निर्णय क्रम से चलते हैं। प्रमाणीकरण तय करता है कि कौन-सा खाता पूछ रहा है, और प्राधिकरण तय करता है कि वह खाता बिल्कुल कनेक्ट कर सकता है या नहीं। नीति की शर्तें और सीमाएँ अपने ही मानदंडों पर मूल्यांकित होती हैं, इसलिए सही रहस्य प्रश्न का केवल पहला आधा हिस्सा सुलझाता है। सर्वर इवेंट में नीति का नाम बताता है कि वास्तव में कौन-सा निर्णय चला।
व्यवस्थापक को प्रोफ़ाइल नाम, प्रयास किया गया खाता और समय-चिह्न भेजें। दूसरे पासवर्ड रीसेट के बजाय संबंधित निर्णय-रिकॉर्ड और उसका कारण माँगें, और वह नीति नाम भी माँगें जो इवेंट में है। Microsoft का दूरस्थ-पहुँच त्रुटि कोड संदर्भ क्रेडेंशियल और प्रमाणीकरण विफलताओं में 691 को सूचीबद्ध करता है, और इसीलिए संवाद तीनों मामलों को अलग नहीं कर सकता।
किसी खाते को बिना शर्त अनुमति में बदलना प्राधिकरण के निर्णय को स्थायी अपवाद बना देता है। यह उस शर्त को भी हटा देता है जो उपयोगी काम कर रही थी, और नीति की अगली समीक्षा करने वाले को पता नहीं होगा कि यह क्यों बदली। इसके बजाय स्वामी से इच्छित नीति की पुष्टि कराएँ, ताकि स्वीकृति जानबूझकर बनी रहे।
एक बार फिर प्रयास करें, फिर तुलना करें
आपके द्वारा पहचाने गए एकमात्र सुधार के बाद उसी प्रोफ़ाइल को दोहराएँ। यदि पहुँच स्वीकार हो जाए और कोई आंतरिक संसाधन अब भी विफल रहे, तो विफलता दूसरी परत पर चली गई है और अब पासवर्ड के बारे में कुछ नहीं कहती। प्रोफ़ाइल को अपरिवर्तित रखना ही उस तुलना को अर्थपूर्ण बनाता है।
अस्वीकृति के समझाए जाने से पहले किसी पता-परिवार को अक्षम करने या विस्तृत ट्रेसिंग सक्षम करने के लोभ का विरोध करें। ट्रेसिंग निर्णय नहीं, मात्रा पैदा करती है, और पहला उपयोगी परिणाम वही घटक रहता है जिसने प्रयास अस्वीकार किया और वह कारण जो उसने दर्ज किया। यह ज्ञात होने पर, पुनः प्रयास या तो मरम्मत की पुष्टि करता है या नया और संकरा लक्षण पैदा करता है।