एक वापरकर्ता VPN मध्ये साइन इन करू शकत नाही: क्रमबद्ध निदान

जेव्हा एक व्यक्ती कनेक्ट होऊ शकत नाही तर उर्वरित संघ काम करत राहतो, तेव्हा उपयुक्त प्रश्न हा नाही की काय तुटले आहे, तर हा आहे की कोणता स्तर सहमत झाला नाही। साइन इन ही एक साखळी आहे: क्लायंट सुरू होतो, गेटवे उत्तर देतो, एक ओळख सांगितली जाते, दुसरा घटक पूर्ण होतो, धोरण मूल्यांकन केले जाते, आणि त्यानंतरच रहदारी वाहते। त्या साखळीत कुठेही तुटणे तुमच्यापर्यंत वापरकर्त्याच्याच वाक्यात पोहोचते, म्हणून पहिले काम म्हणजे खरोखर अपयशी ठरलेला दुवा शोधणे।

अहवालाकडे निदान म्हणून नाही तर प्रारंभबिंदू म्हणून पाहा। खालील तपासण्या सर्वात स्वस्तापासून सुरू होतात, आणि प्रत्येक अपयशी झाल्यावर तपासणी संपवण्यासाठी लिहिलेली आहे।

टप्पा आणि वेळेची नोंद निश्चित करा

कोणतेही संरचना-संयोजन स्पर्श करण्यापूर्वी चार गोष्टी लिहा: क्लायंट आणि त्याची आवृत्ती, स्क्रीनवरील नेमकी शब्दरचना, प्रयत्नाचा मिनिट, आणि ती व्यक्ती ज्या नेटवर्कवर होती ते। शब्दरचना खरी माहिती वाहते, कारण नाकारलेली ओळखपत्रे, उत्तर न देणारा गेटवे आणि पूर्ण झालेले साइन इन जे तरीही अंतर्गत पृष्ठ उघडू शकत नाही या तीन वेगवेगळ्या मालकांच्या तीन वेगवेगळ्या समस्या आहेत। क्लायंटने स्थानिक लॉग ओळ तयार केली का ते नोंदवा, कारण ज्या क्लायंटने कधीही पॅकेट पाठवले नाही त्याच्याकडे सर्व्हर-बाजूच्या शोधात भर घालण्यासारखे काही नाही। वेळेची नोंद झाल्यावर पुढील प्रत्येक चौकशी शिकार नाही तर शोध बनते।

या टप्प्यावर पासवर्डचा अंदाज लावणे थांबवा। जिथे खात्याला पुन्हा प्रयत्नांची मर्यादा आहे, तिथे जलद प्रयत्नांचा लोट त्याला कुलूपबंद करू शकतो आणि खऱ्या दोषावर दुसरा, कृत्रिम दोष चढवू शकतो। आधीच किती प्रयत्न झाले आहेत ते नोंदवा, जेणेकरून कुलूपबंदीचा नंतर नवीन लक्षण म्हणून गैरसमज होणार नाही। कुलूपबंद खाते तुमची चुकीचा पासवर्ड आणि नाकारलेले धोरण यात फरक करण्याची क्षमताही काढून घेते, कारण दोन्ही नकार म्हणून येतात।

त्या एका प्रयत्नासाठी ओळख-घटना वाचा

तुम्ही नोंदवलेल्या मिनिटाशी जुळणारा प्रमाणीकरण नोंद अधिकाऱ्याला काढायला सांगा। Windows NPS तैनातीत, Microsoft चे NPS समस्या निवारण मार्गदर्शक नकार घटना 6273 तिच्यासोबत येणाऱ्या कारण कोडसह नोंदवते, आणि हे सहसा अज्ञात वापरकर्ता, वाईट ओळखपत्रे, धोरण विसंगती आणि असंबंधित कारणाने पडलेला कॉल वेगळे करते।

रिकामा निकालही माहिती आहे। जर ओळख सेवेपर्यंत काहीही पोहोचले नाही, तर प्रयत्न आधीच मेला: प्रोफाइलमधील जुना गेटवे पत्ता, क्लायंटला पोहोचता न येणारा श्रोता, किंवा प्रोफाइल जिवंत असतानाच सेवेतून काढलेला होस्ट। जर नोंद अस्तित्वात असेल आणि यशाची नोंदवणी करत असेल, तर ओळखपत्रे समस्या नाहीत आणि वाद अधिकृततेकडे किंवा गेटवेच्या मागील मार्गनिर्देशनाकडे सरकतो। हे दोन निकाल विरुद्ध दिशांना निर्देश करतात, म्हणून कोणी क्लायंट पुन्हा प्रस्थापित करण्यापूर्वी लॉग शोध झाला पाहिजे।

कारण कोड तिकिटात ठेवा। ते एकच क्षेत्र पुढील घटनेला पुनरावृत्त तपासणीऐवजी पाच मिनिटांचा शोध बनवते। ते क्लायंट आवृत्तीशी जोडा, कारण एका बिल्डवर दिसणारा कोड प्रत्येक बिल्डवर दिसणाऱ्या कोडपेक्षा वेगळी चर्चा आहे।

धोरणाच्या आत, एका वेळी एक अट बदला

मोह हा आहे की एकाच फेरीत क्लायंट पुन्हा प्रस्थापित करणे, पासवर्ड रीसेट करणे आणि लॅपटॉप दुसऱ्या नेटवर्कवर हलवणे। ते कधीकधी लक्षण सुधारते आणि नेहमी पुरावा नष्ट करते। त्याऐवजी एक परवानगी असलेली अदलाबदल निवडा: तीच व्यक्ती दुसऱ्या नोंदणीकृत उपकरणावर, किंवा त्याच उपकरणावर मंजूर चाचणी ओळख। प्रत्येक अदलाबदल नेमके एका प्रश्नाचे उत्तर देते, म्हणून यश संपूर्ण VPN ला दोष देण्याऐवजी दोष तुम्ही बदललेल्या बाजूकडे संकुचित करते।

ही तुलना करण्यासाठी सहकाऱ्याची ओळखपत्रे उधार घेऊ नका। समर्थित प्रक्रियेद्वारे चाचणी ओळख वापरा, आणि वेगवान होईल म्हणून कधीही उपकरणाची किल्ली कॉपी करू नका किंवा नोंदणी वगळू नका। जिथे धोरण अदलाबदल पूर्णपणे प्रतिबंधित करते, तिथे ती मर्यादा चाचणीत असलेल्या प्रणालीचा भाग आहे आणि ती नोंदीत असावी, टाळाटाळीत नाही।

मूळ मार्गावर दुरुस्तीची पुष्टी करा

तुटलेला दुवा ओळखला गेल्यावर फक्त त्या दुव्याची दुरुस्ती करा आणि मूळ प्रयत्नाची पुनरावृत्ती करा: तीच व्यक्ती, तेच उपकरण, तेच नेटवर्क, तेच अनुप्रयोग। प्रशासकीय VLAN मधून जोडणारे चाचणी खाते गेटवे जिवंत असल्याचे सिद्ध करते, आणि वापरकर्त्याच्या मंगळवारच्या सकाळबद्दल काहीही सिद्ध करत नाही। वापरकर्त्याला सोपी क्रिया नाही तर अपयशी ठरलेली क्रिया करायला सांगा, कारण यशस्वी ping नाकारलेल्या फाइल सामायिकरणाबद्दल थोडे सांगते।

काय वगळले गेले आणि काय बदलले यासह तिकीट बंद करा। ती नोंद एकवेळची सुटका आणि पुढील ड्युटी अभियंता पुन्हा वापरू शकेल अशा गोष्टीतील फरक आहे।