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 बोकेको लग लाइनमा सामान्यतया कारण कोड वा चुनौती स्ट्रिङ हुन्छ। मद्दत माग्दा त्यसलाई फेरि भन्नुभन्दा ठ्याक्कै प्रतिलिपि गर्नुहोस्।

दोस्रो कारकको आफ्नै सम्झौता हुन्छ

प्रोफाइलले एकपटकको कोड, अन्तरक्रियात्मक चुनौती वा क्लाइन्टलाई टोकन फर्काउने ब्राउजर साइन-इन अपेक्षा गर्न सक्छ। आफैँ आविष्कार गर्नुभन्दा अपरेटरले समर्थन गर्ने प्रवाह प्रयोग गर्नुहोस्।

त्यो ढाँचा स्पष्ट रूपमा नचाहिएसम्म पासवर्डमा कोड नथप्नुहोस्, किनकि केही परिनियोजनले छुट्टै फिल्ड र केहीले चुनौती स्ट्रिङ प्रयोग गर्छन्। समयमा आधारित कोडका लागि यन्त्रको घडी जाँच्नुहोस्, किनकि केही मिनेटको फरकले हरेक कोड अमान्य बनाउँछ। ब्राउजर लगइन सफल भई क्लाइन्ट कहिल्यै नचलेमा ठ्याक्कै त्यही बिन्दु नोट गर्नुहोस्, किनकि त्यसले प्रमाण होइन, हस्तान्तरण चिन्हित गर्छ। अर्को पासवर्ड रिसेटले सहयोग गर्ने सम्भावना कम छ।

सत्र सीमा अर्को सामान्य अस्वीकृति हो। खाताले एक सत्र मात्र अनुमति दिन्छ भने दोस्रो लगइनले पहिलो अन्त्य गर्न सक्छ, र लक्षण नीति होइन, डगमगाउँदो जडानजस्तो देखिन्छ।

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

खाताको पासवर्ड पूर्ण रूपमा सही हुँदा पनि क्लाइन्ट प्रमाणपत्रको म्याद सकिन वा रद्द हुन सक्छ। निजी कुञ्जीको पासफ्रेज फेरि तेस्रो रहस्य हो, र त्यसले खाता होइन, फाइल सुरक्षित गर्छ।

केही परिवर्तन गर्नुअघि त्रुटि पढ्नुहोस्, त्यसपछि प्रमाणित अपरेटरबाट सही प्रतिस्थापन लिनुहोस्। त्यसो गर्दा सर्भर पहिचान प्रमाणीकरण खुला राख्नुहोस्: असम्बन्धित प्रमाणपत्र स्वीकार गर्नु वा अरूको निजी कुञ्जी प्रतिलिपि गर्नु मर्मत होइन, दोस्रो घटना हो। त्यसपछि तपाईंलाई साँच्चै चाहिने स्रोत परीक्षण गर्नुहोस्, किनकि पहुँच नहुने सेवासहितको जोडिएको टनेल अर्को अनुसन्धानमा पर्छ। कुन चरण असफल भयो लेख्नुहोस् ताकि अर्को व्यक्तिले पूरै प्रक्रिया फेरि सुरु नगरोस्।

सत्र स्थापित भई पछि असफल भएमा अन्तराल र नजिकका नवीकरण घटना रेकर्ड गर्नुहोस्। त्यो रेकर्डले टोकनको आयु समस्यालाई पहिलो लगइनको असफलताबाट छुट्याउँछ, र पाँच मिनेटको सुधार र एक हप्ताको पुनःप्रयासबीचको फरक त्यही हो।