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 पंजीकरण को नहीं छूता, और वे अपने जीवनचक्र वाली अलग पहचानें हैं। नवीनीकृत प्रमाणपत्र पासवर्ड घुमाने से ठीक नहीं होता, और रीसेट से पहले जारी टोकन अभी भी वैध हो सकता है। यह लिखकर समाप्त करें कि किस स्टोर में पुराना मान था, क्योंकि अगला रीसेट उसी सूची से टकराएगा।