VPN पासवर्ड रीसेट केल्यानंतरही एक डिव्हाइस कनेक्ट होत नाही
नवीन पासवर्ड एका क्लायंटशिवाय सर्वत्र काम करतो। जुने मूल्य अजूनही ठेवणारे स्टोअर शोधा, पुनःप्रयत्न मर्यादित करा आणि एका प्रयत्नाने पडताळा।
तुम्ही पासवर्ड रीसेट केला, पोर्टलमध्ये तपासला, आणि एक लॅपटॉप अजूनही कनेक्ट होऊ शकत नाही। पहिली प्रवृत्ती तो पुन्हा रीसेट करण्याची असते, आणि अशाच प्रकारे खाते लॉक होते आणि जुने रहस्य घटना बनते। VPN क्लायंट प्रत्येक वेळी पासवर्ड मागत नाही; तो एकदा मागतो आणि उत्तर तुम्ही न निवडलेल्या जागी साठवतो। ती जागा शोधणे हेच संपूर्ण काम आहे, आणि ते आणखी एका रीसेटपेक्षा जलद आहे।
प्रत्येक क्लायंट प्रत्यक्षात काय पाठवतो ते निश्चित करा
पासवर्ड हीच समस्या आहे असे गृहीत धरण्यापूर्वी अपयशी क्लायंटवर खाते, डोमेन आणि गेटवे तपासा। वेब पोर्टल लॉगिन VPN पेक्षा वेगळी ओळख प्रणाली वापरू शकते, त्यामुळे यशस्वी पोर्टल साइन-इन प्रोटोकॉलच्या प्रमाणीकरणाबद्दल काहीही सांगत नाही। काही तैनाती पोर्टलवर ईमेल आणि टनलमध्ये वेगळे वापरकर्तानाव स्वीकारतात। काहीही रीसेट करण्यापूर्वी क्लायंट कोणती ओळख सादर करण्यासाठी कॉन्फिगर आहे ते निश्चित करा।
त्रुटीचा मजकूर वाचा आणि त्याचे वर्गीकरण करा। प्रमाणपत्र अपयश, कालबाह्य आव्हान किंवा असमर्थित सिफर हा जुना पासवर्ड नाही, आणि त्याला तसे मानल्यास कोणत्याही परिणामाशिवाय रीसेटचे चक्र तयार होते। सेवेला लॉकआउट धोरण असल्यास, दोन किंवा तीन अपयशी प्रयत्नांनंतर थांबा आणि पुढे जाण्यापूर्वी खात्याची स्थिती निश्चित करा।
अंदाज लावण्याऐवजी स्टोअरची यादी करा
चार स्टोअर VPN रहस्य ठेवतात, आणि खालील तक्ता प्रत्येकासाठी मूल्य कुठे टिकते आणि ते पुसण्याचा प्रत्यक्ष अर्थ काय आहे हे दाखवतो। मूळ OS प्रोफाइल प्लॅटफॉर्मच्या क्रेडेन्शियल स्टोअरमध्ये रहस्य ठेवते, म्हणून नोंद ती लिहिणाऱ्या ॲपपेक्षा जास्त काळ टिकू शकते। क्लायंट कॉन्फिगरेशन फाइल मूल्य तिथे ठेवते जिथे तो क्लायंट ते वाचतो, एकतर इनलाइन किंवा संदर्भित auth फाइलमध्ये, त्यामुळे दुसरी फाइल संपादित केल्याने काहीही बदलत नाही। ब्राउझर पोर्टल कुकी आणि धोरणाद्वारे दिलेले क्रेडेन्शियल अशा ठिकाणी राहतात ज्याचे डिव्हाइस प्रत्यक्षात मालक नाही, आणि ते कोणाला ती बदलण्याची परवानगी आहे हे ठरवते।
| Store | Where it lives | How to clear it |
|---|---|---|
| Native OS profile | Windows Credentials, NetworkManager secrets | forget or edit the connection |
| Client configuration file | a referenced auth file or inline value | edit the file the client actually reads |
| Browser session | cookie for the portal SSO | sign out of the portal, not just close the tab |
| Managed policy | delivered by the management service | change it in the manager, not on the device |
त्यांना निश्चित क्रमाने तपासा: प्रथम OS क्रेडेन्शियल स्टोअर, कारण क्लायंट डीफॉल्टने त्याच्याकडेच विचारतो, नंतर क्लायंटचे स्वतःचे व्हॉल्ट किंवा कॉन्फिग फाइल, नंतर ब्राउझर सत्र, आणि शेवटी तीनही ओव्हरराइट करू शकणारे धोरण। क्रम महत्त्वाचा आहे कारण नंतरचे स्टोअर आधीचे गुपचूप पुनर्संचयित करू शकते, आणि अपयश सुरू असताना तुम्ही चुकीचा थर दुरुस्त कराल। तुम्ही कोणते स्टोअर बदलले ते लिहा, कारण तीच नोंद पुढील रीसेटला संपूर्ण दुपारऐवजी दोन मिनिटांचे काम बनवते।
क्लायंट प्रत्यक्षात वापरत असलेल्या स्टोअरमध्ये पाहा
हटवण्यापूर्वी वाचा, जेणेकरून कोणती नोंद VPNची होती हे कळेल। खालील आदेश काढून टाकण्याऐवजी यादी करतात आणि तपासतात, ज्यामुळे निदान उलटण्यायोग्य राहते।
# Windows credential store
cmdkey /list | findstr /i vpn# Windows native profile
Get-VpnConnection -Name "Work" | Select-Object -ExpandProperty Guid# macOS Keychain
security find-generic-password -s "Company VPN" -g# Linux NetworkManager
nmcli -s connection show "Work" | grep -i passwordLinux वर, -s अशी रहस्ये दाखवते जी NetworkManager अन्यथा लपवतो। macOS वर, Keychain आदेश साठवलेला घटक छापतो, त्यामुळे टर्मिनलचा स्क्रोलबॅक संवेदनशील म्हणून घ्या। अपयशी क्लायंट स्वतःचे व्हॉल्ट असलेले तृतीय-पक्ष ॲप असल्यास, OS स्टोअर बरोबर दिसेल पण ॲप स्वतःची प्रत ठेवेल, आणि बदल त्याच व्हॉल्टमध्ये व्हायला हवा।
ऑफलाइन डिव्हाइस हाताळा
स्वतः जागे होऊन पुन्हा कनेक्ट होणारे लॅपटॉप त्यांची प्रत असेपर्यंत जुने रहस्य सादर करत राहतील। ती डिव्हाइस एकत्र पुन्हा प्रयत्न करण्यापूर्वी सुधारली जातील अशी अद्ययावत योजना करा, आणि प्रत्येकाने समर्थित प्रवाह पूर्ण करेपर्यंत प्रभावित प्रोफाइलवर स्वयं-कनेक्शन बंद करण्याचा विचार करा।
व्यवस्थापित ताफ्यासाठी, धोरण जिथे परिभाषित आहे तिथे मूल्य बदला। ज्या डिव्हाइसचे क्रेडेन्शियल केंद्रीय पद्धतीने पुरवले जाते त्यावर स्थानिक प्रत संपादित करणे सर्वोत्तम स्थितीत तात्पुरते आहे; पुढील धोरण रिफ्रेश जुने मूल्य पुनर्संचयित करते आणि अपयश स्पष्टीकरणाशिवाय परत येते।
एका नियंत्रित प्रयत्नाने पडताळा
इच्छित नोंद अद्ययावत करा, एकदा पुन्हा कनेक्ट करा, आणि टनल एखाद्या विशिष्ट गोष्टीपर्यंत पोहोचते याची खात्री करा। एक नियंत्रित प्रयत्न अपयशी झाल्यास उपयुक्त त्रुटी देतो, तर वीस प्रयत्न लॉक झालेले खाते आणि एक कोडे देतात। स्टोअर दुरुस्त केल्यानंतरही क्लायंट अपयशी झाल्यास, रहस्य नसलेली एक त्रुटी पकडा आणि थांबा। ती त्रुटी डिव्हाइसच्या नावासह ठेवा जेणेकरून पुढील शिफ्ट तुम्ही जिथे संपवले तिथून सुरू होईल।
पासवर्ड बदलणे प्रमाणपत्रे, सत्र टोकन किंवा MFA नोंदणीला स्पर्श करत नाही, आणि त्या स्वतःच्या जीवनचक्रासह वेगळ्या ओळखी आहेत। नूतनीकृत प्रमाणपत्र पासवर्ड फिरवल्याने दुरुस्त होत नाही, आणि रीसेटपूर्वी जारी केलेले टोकन अजूनही वैध असू शकते। कोणत्या स्टोअरमध्ये जुने मूल्य होते ते लिहून संपवा, कारण पुढील रीसेट त्याच यादीशी भिडेल।