VPN प्रमाणीकरण अयशस्वी: पोर्ट किंवा DNS क्वचितच कारण असतात

प्रमाणीकरण अयशस्वी म्हणजे सेवेने ओळख स्वीकारून ती नाकारली, हे बहुतेक लोकांच्या कल्पनेपेक्षा अरुंद विधान आहे. पोर्ट उघडा आहे, TLS सत्र पूर्ण झाले असेल, आणि क्रेडेन्शियल किंवा खात्यातील काहीतरी नाकारले गेले. त्रुटीचा मजकूर आधीच टप्पा सांगतो, म्हणून तिथूनच सुरुवात करा.

त्रुटीने आधीच सांगितले कोणता टप्पा अयशस्वी झाला

जे कनेक्शन कधीही त्याचे TLS हस्तांदोलन पूर्ण करत नाही ते प्रमाणीकरणापर्यंत पोहोचलेच नाही. जे कनेक्शन हस्तांदोलन पूर्ण करते आणि नंतर क्रेडेन्शियल नाकारल्याचे नोंदवते ते तिथे पोहोचले आणि तिथेच अयशस्वी झाले. या दोन निकालांसाठी वेगळी चौकशी लागते, आणि दोन्ही बंद खिडकीने संपत असल्याने त्यांची अनेकदा गल्लत होते.

OpenVPN सर्व्हरच्या AUTH_FAILED संदेशाने फरक स्पष्ट करते, जो निर्णय आहे, वाहतूक त्रुटी नाही. TLS वाटाघाटीचा कालबाह्य होणे किंवा प्रमाणपत्र पडताळणीची त्रुटी पूर्वीच्या टप्प्यातील आहे. क्रेडेन्शियलना स्पर्श करण्यापूर्वी तुमच्याकडे कोणते आहे ते वाचा, कारण पासवर्ड रीसेट हस्तांदोलन दुरुस्त करू शकत नाही आणि फायरवॉल बदल नाकारलेला लॉगिन दुरुस्त करू शकत नाही. क्लायंट लॉगची एक ओळ प्रश्नाचे उत्तर देते.

जोडले जाऊन नंतर तुटणाऱ्या सत्रालाही तोच तर्क लागू होतो. चाळिसाव्या मिनिटाला पुनःप्रमाणीकरणाची अयशस्वीता पहिल्या लॉगिनच्या नाकारण्यापेक्षा वेगळी बिघाड आहे, आणि मध्यंतर हाच सुगावा आहे.

प्रोफाइल योग्य सेवेकडे निर्देश करत असल्याची खात्री करा

प्रदात्याच्या वेबसाइटवर वापरलेले खाते त्याच्या VPN गेटवेला स्वीकारार्ह खाते असेलच असे नाही. जतन केलेले प्रोफाइल सेवा हलल्यानंतर बराच काळ जुन्या गेटवेकडेही निर्देश करू शकते.

प्रोफाइलमधील अंतिमबिंदूची तुलना ऑपरेटरने प्रकाशित केलेल्या बिंदूशी करा, आणि गेटवे कोणत्या ओळखप्रणालीचा सल्ला घेते ते तपासा. टनेल वेगळ्या डिरेक्टरीविरुद्ध प्रमाणीकरण करत असेल तर वेब पोर्टलवरील पासवर्ड रीसेट काहीही बदलत नाही. असंबंधित सार्वजनिक सर्व्हरची क्रेडेन्शियल तुमच्यावर चालणार नाहीत, आणि अविश्वासार्ह संदेशातून मिळालेल्या प्रोफाइलमध्ये कार्यालयीन पासवर्ड तपासणे कोणत्याही परिस्थितीत वाईट सौदा आहे. काहीही टाइप करण्यापूर्वी स्रोताची खात्री करा.

प्रोफाइलवर दोन मिनिटे घालवल्याने क्रेडेन्शियलच्या अंदाजाचा एक दिवस वाचतो.

लॉगिनचे स्वरूप क्रेडेन्शियलचा भाग आहे

वापरकर्तानावाला ईमेल स्वरूप, डोमेन उपसर्ग किंवा डिरेक्टरी प्रत्यय लागू शकतो. गेटवे मिळालेल्या स्ट्रिंगची तुलना करते, म्हणून स्वरूप सजावट नसून क्रेडेन्शियलचा भाग आहे.

मग वाढ करण्यापूर्वी कंटाळवाणी कारणे बाजूला काढा. कीबोर्ड मांडणी, कॉपीमुळे आलेली कोणतीही शेवटची जागा, आणि पासवर्ड व्यवस्थापकातील जुनी नोंद तपासा. रीसेटनंतर VPN तोच ओळखस्रोत वापरत असल्याची खात्री करा जो पासवर्ड बदललेल्या पृष्ठाचा आहे. हे तपशील बरोबर असल्यास अंदाज थांबवा आणि ऑपरेटरला विचारा की खाते VPN प्रवेशासाठी सक्षम व अधिकृत आहे का. ही क्लायंट सेटिंग नसून सेवा बाजूची दुरुस्ती आहे.

openvpn --config office.ovpn --verb 3
journalctl -u openvpn-client@office -n 40 --no-pager

AUTH_FAILED असलेल्या लॉग ओळीत सहसा कारण कोड किंवा आव्हान स्ट्रिंग असते. मदत मागताना ती पुन्हा सांगण्याऐवजी तशीच कॉपी करा.

दुसऱ्या घटकांचा स्वतःचा करार असतो

प्रोफाइल एकवेळचा कोड, संवादात्मक आव्हान, किंवा क्लायंटला टोकन परत देणारे ब्राउझर साइन-इन अपेक्षित करू शकते. स्वतःचे शोधून काढण्याऐवजी ऑपरेटर जे समर्थन देतो तो प्रवाह वापरा.

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

सत्र मर्यादा हा दुसरा सामान्य नकार आहे. खाते एक सत्राला परवानगी देत असेल तर दुसरे लॉगिन पहिले संपवू शकते, आणि लक्षण धोरणासारखे नाही तर झुलत्या जोडणीसारखे दिसते.

प्रमाणपत्र पासवर्ड नाही

खात्याचा पासवर्ड पूर्णपणे बरोबर असतानाही क्लायंट प्रमाणपत्राची मुदत संपू शकते किंवा ते रद्द होऊ शकते. खाजगी कीचा पासफ्रेज पुन्हा तिसरे रहस्य आहे, आणि तो खात्याला नाही तर फाइलला संरक्षित करतो.

काहीही बदलण्यापूर्वी त्रुटी वाचा, मग पडताळलेल्या ऑपरेटरकडून योग्य बदली मिळवा. तसे करताना सर्व्हर ओळख पडताळणी सुरू ठेवा: असंबंधित प्रमाणपत्र स्वीकारणे किंवा दुसऱ्याची खाजगी की कॉपी करणे ही दुरुस्ती नाही, ती दुसरी घटना आहे. मग तुम्हाला खरोखर आवश्यक असलेला स्रोत तपासा, कारण अगम्य सेवेसह जोडलेले टनेल वेगळ्या चौकशीत मोडते. कोणता टप्पा अयशस्वी झाला ते लिहून ठेवा जेणेकरून पुढील व्यक्ती संपूर्ण प्रक्रिया पुन्हा सुरू करणार नाही.

सत्र स्थापित होऊन नंतर अयशस्वी झाल्यास, मध्यंतर आणि जवळच्या नूतनीकरण घटना नोंदवा. ती नोंद टोकनच्या आयुष्याची समस्या पहिल्या लॉगिनच्या अयशस्वीतेपासून वेगळी करते, आणि पाच मिनिटांची दुरुस्ती व आठवडाभराचे पुनःप्रयत्न यातील फरक तोच आहे.