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