त्रुटि 809 लॉगिन की नहीं, पथ की समस्या है

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

अवरुद्ध पोर्ट और ग़लत पासवर्ड बिल्कुल अलग संदेश देते हैं, और 809 शायद ही दूसरा होता है।

प्रोफ़ाइल जो प्रोटोकॉल उपयोग करती है, उसकी पुष्टि करें

सर्वर का नाम, पता और टनल का प्रकार ऑपरेटर के मौजूदा निर्देशों के सामने जाँचें, फिर नोट करें कि वह प्रकार किस परिवहन पर निर्भर है। ये तीन मान एक साथ जुड़े हैं; पुराने टनल प्रकार के साथ सही नाम भी ग़लत नाम की तरह विफल होता है। IKEv2 UDP 500 और 4500 पर निर्भर है, और मूल ESP ट्रैफ़िक को TCP या UDP के रूप में नहीं, अपने प्रोटोकॉल के रूप में अनुमति देनी होती है। पुराने सेटअप से कॉपी की गई प्रोफ़ाइल ऐसा टनल प्रकार बता सकती है जो सर्वर अब नहीं देता। संवाद-पेटी के लेबल से अनुमान लगाने के बजाय मान ऑपरेटर से लें।

उसी होस्टनाम पर ब्राउज़र पृष्ठ पूरी तरह दूसरी सेवा की जाँच करता है। यह साबित कर सकता है कि होस्ट ज़िंदा है और विफल बातचीत के बारे में कुछ साबित नहीं करता।

क्रेडेंशियल नहीं, नेटवर्क बदलें

अगर नीति अनुमति दे, तो वही प्रोफ़ाइल किसी दूसरे भरोसेमंद नेटवर्क से जाँचें, क्लाइंट और सर्वर अपरिवर्तित रखते हुए ताकि एक्सेस पथ ही एकमात्र अंतर हो। कहीं और सफलता मूल पथ पर फ़िल्टरिंग की ओर इशारा करती है, जबकि हर जगह विफलता अंतिम बिंदु या प्रोफ़ाइल की ओर। ऑपरेटर से पूछें कि गेटवे ने प्रयास देखा या नहीं, क्योंकि सर्वर पर संबंधित घटना के बिना क्लाइंट स्पष्ट अस्वीकृति से अलग सीमा है।

बेतरतीब रजिस्ट्री बदलाव और फ़ायरवॉल बंद करना इस कोड के लिए लोकप्रिय सलाह हैं, और इनमें से कोई भी पुष्ट निदान से नहीं निकलता। ऑपरेटर से पूछें कि इस परिनियोजन के लिए प्रलेखित सुधार क्या है।

कोड के साथ अगले चरण तक जाएँ

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

कोड को फ़ैसला नहीं, चरण-चिह्न मानें; यही पढ़ना पाँच मिनट की जाँच और खोई दोपहर के बीच का अंतर है।

पहले क्या न बदलें

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

अगर ऑपरेटर ने हाल ही में अंतिम बिंदु बदला है, तो स्मृति से पुनर्निर्माण करने के बजाय मौजूदा विवरण माँगें। जो पता अब मौजूद नहीं है वह ठीक इसी श्रेणी की विफलता पैदा करता है।

प्रोटोकॉल, जाँचे गए नेटवर्क और गेटवे का दृश्य दर्ज करें। ये तीन अधिकांश 809 रिपोर्टें सुलझा देते हैं।