VPN प्रमाणीकरण रियल्म: कौन-सा खाता नामस्थान जीतता है?

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

रियल्म क्या चुनता है

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

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

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

एक बार में एक चीज़ बदलें और प्रयास दोहराएँ, क्योंकि लॉग रूटिंग को क्रेडेंशियल विफलता से केवल तभी अलग करता है जब इनपुट रनों के बीच भिन्न हो। साझा गोपनीयता को शेल इतिहास से बाहर रखें जहाँ उपकरण फ़ाइल या प्रॉम्प्ट से पढ़ने का समर्थन करता है।

प्रयास दर्ज करें बिना उसे लीक किए

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

फिर उपयोगकर्ताओं के लिए जीतने वाला रूप दस्तावेज़ करें, क्योंकि अगला व्यक्ति जो इसे गलत टाइप करेगा वही टिकट खोलेगा। पासवर्ड रीसेट उस अनुरोध को नहीं ठीक करता जो गलत नामस्थान में पहुँचता रहता है। रियल्म एक रूटिंग निर्णय है, और रूटिंग निर्णय उन्हें सही नाम देकर ठीक किए जाते हैं।