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

रियल्मले के छान्छ

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

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

रियल्मको वाक्यरचना तैनाथीको हो। केही सेवाले योग्यतारहित नाम र गुण चाहन्छन्, अरूले user@domain चाहन्छन्, र केहीले अधिकांश मार्गदर्शकले नउल्लेख गर्ने ब्याकस्ल्यास भएको स्वरूप अपेक्षा गर्छन्।

ब्याकएन्डले अपेक्षा गर्ने स्वरूप प्रयोग गर्नुहोस्

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

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

ब्राउजर र मेल क्लाइन्टहरूले कहिलेकाहीँ अघिल्लो पहिचान क्यास गरेर चुपचाप फेरि पठाउँछन्। रिपोर्ट गरिएको प्रयोगकर्ता नाम टाइप गरेकोभन्दा फरक भए पहिले त्यही क्यास हेर्नुहोस्।

प्रोक्सीमार्फत अनुरोधको खोजी गर्नुहोस्

FreeRADIUS फ्रन्ट इन्डमा रियल्महरू प्रोक्सी कन्फिगरेसनमा घोषणा गरिन्छ, र घोषित प्रत्ययले कुन होम सर्भरले अनुरोध पाउने निर्णय गर्छ। केही पनि परिवर्तन गर्नुअघि त्यो फाइल पढ्नुहोस्, किनकि कुनै रियल्मसँग नमिल्ने अनुरोध पूर्वनिर्धारित रूपमा स्थानीय रूपमा ह्यान्डल गरिन्छ।

grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'

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

एक पटकमा एउटा मात्र कुरा परिवर्तन गर्नुहोस् र प्रयास दोहोर्याउनुहोस्, किनकि इनपुट रनहरूबीच फरक हुँदा मात्र लगले मार्गनिर्देशनलाई प्रमाण असफलताबाट अलग गर्छ। साझा गोप्य कुरा shell इतिहासबाहिर राख्नुहोस्, जहाँ उपकरणले फाइल वा प्रम्प्टबाट पढ्न समर्थन गर्छ।

प्रयास लीक नगरी रेकर्ड गर्नुहोस्

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

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

सम्बन्धित लेखहरू