एक प्रयोगकर्ता VPN मा साइन इन गर्न सक्दैन: क्रमबद्ध निदान

जब एक व्यक्ति जडान गर्न सक्दैन भने बाँकी टोलीले काम जारी राख्छ, तब उपयोगी प्रश्न के बिग्रियो भन्ने होइन, तर कुन तह मिलेन भन्ने हो। साइन इन एउटा शृंखला हो: क्लाइन्ट सुरु हुन्छ, गेटवे जवाफ दिन्छ, पहिचान दाबी गरिन्छ, दोस्रो कारक पूरा हुन्छ, नीति मूल्याङ्कन गरिन्छ, र त्यसपछि मात्र ट्राफिक बहन्छ। त्यो शृंखलाको जहाँसुकै टुट्ने कुरा तपाईंकहाँ प्रयोगकर्ताकै उही वाक्यका रूपमा पुग्छ, त्यसैले पहिलो काम भनेको साँच्चै असफल भएको कडी खोज्नु हो।

प्रतिवेदनलाई निदान होइन, सुरुवात बिन्दु मान्नुहोस्। तलका जाँचहरू सबैभन्दा सस्तोबाट सुरु हुन्छन्, र हरेक असफल हुँदा अनुसन्धान अन्त्य गर्न लेखिएको छ।

चरण र समय-छाप निश्चित गर्नुहोस्

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

यो बिन्दुमा पासवर्ड अनुमान गर्न रोक्नुहोस्। जहाँ खातामा पुनः प्रयासको सीमा छ, त्यहाँ द्रुत प्रयासहरूको लहरले त्यसलाई लक गर्न सक्छ र वास्तविक दोषमाथि दोस्रो, कृत्रिम दोष थप्न सक्छ। पहिले नै कति प्रयास भएका छन् लेख्नुहोस्, ताकि लकआउटलाई पछि नयाँ लक्षण ठानिँदैन। लक भएको खाताले गलत पासवर्डलाई अस्वीकृत नीतिबाट छुट्याउने क्षमता पनि खोस्छ, किनकि दुवै अस्वीकारका रूपमा आउँछन्।

त्यो एक प्रयासको पहिचान घटना पढ्नुहोस्

तपाईंले रेकर्ड गरेको मिनेटसँग मिल्ने प्रमाणीकरण रेकर्ड निकाल्न प्रशासकलाई भन्नुहोस्। Windows NPS तैनाथीमा, Microsoft को NPS समस्या समाधान मार्गदर्शिका अस्वीकृति घटना 6273 लाई त्यससँगै आउने कारण कोडसहित अभिलेख गर्छ, र यसले सामान्यतया अज्ञात प्रयोगकर्ता, खराब प्रमाण, नीति बेमेल र असम्बन्धित कारणले खसालेको कल छुट्याउँछ।

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

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

नीतिभित्र, एकपटकमा एउटा सर्त बदल्नुहोस्

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

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

मूल मार्गमा मर्मत पुष्टि गर्नुहोस्

टुटेको कडी पहिचान भएपछि त्यही कडी मात्र मर्मत गर्नुहोस् र मूल प्रयास दोहोर्याउनुहोस्: उही व्यक्ति, उही यन्त्र, उही सञ्जाल, उही अनुप्रयोग। प्रशासकीय VLAN बाट जडान हुने परीक्षण खाताले गेटवे जीवित छ भनी प्रमाणित गर्छ, र प्रयोगकर्ताको मङ्गलबार बिहानबारे केही प्रमाणित गर्दैन। प्रयोगकर्तालाई सजिलो कार्य नभई असफल भएको कार्य गर्न भन्नुहोस्, किनकि सफल ping ले अस्वीकृत फाइल साझेदारीबारे थोरै भन्छ।

के बाहिर राखियो र के बदलियो भनेर टिकट बन्द गर्नुहोस्। त्यो नोट एकपटकको उद्धार र अर्को ड्युटी इन्जिनियरले पुनः प्रयोग गर्न सक्ने कुराबीचको फरक हो।