आप NPS RADIUS क्लाइंट के रूप में कौन-सा पता दर्ज करते हैं?
गेटवे का वास्तविक बैकएंड स्रोत दर्ज करें, सार्वजनिक होस्टनाम या क्लाइंट पूल नहीं। साझा गोपनीयता मिलाएँ, फिर एक नियंत्रित अनुरोध से पुष्टि करें।
Windows NPS को प्रमाणीकरण सौंपने वाले VPN गेटवे को NPS की ओर एक ऑब्जेक्ट चाहिए, तभी कोई उपयोगकर्ता नीति चल सकती है: गेटवे के लिए RADIUS क्लाइंट प्रविष्टि। अधिकांश असफल प्रयास गलत पता दर्ज करते हैं, क्योंकि महत्वपूर्ण पता वह है जो गेटवे अपने बैकएंड पथ पर उपयोग करता है, न कि वह होस्टनाम जो कर्मचारी अपने VPN ऐप में लिखते हैं। यह मान गलत हो तो NPS अनुरोध को चुपचाप छोड़ देता है, जो क्लाइंट की ओर से गलत पासवर्ड जैसा दिखता है। कौन-सा पता फ़ील्ड में जाता है यह तीन शर्तें तय करती हैं, इसलिए कंसोल खोलने से पहले उन्हें सुलझा लें।
गेटवे दर्ज करें, लैपटॉप या पूल नहीं
RADIUS क्लाइंट ऑब्जेक्ट उस नेटवर्क एक्सेस डिवाइस का प्रतिनिधित्व करता है जो प्रमाणीकरण अनुरोध भेजता है। वह VPN गेटवे है, क्लाइंट चलाने वाला हर लैपटॉप नहीं, और टनल के भीतर बाँटे जाने वाले पतों की श्रेणी भी नहीं।
वे टनल पते कभी RADIUS अनुरोध के स्रोत के रूप में नहीं दिखते, क्योंकि अनुरोध गेटवे के अपने नेटवर्क पथ से जाता है। क्लाइंट पूल प्रविष्टि दर्ज करने से ऐसी नीति बनती है जो कभी मेल नहीं खा सकती, जबकि असली अनुरोध ऐसे पते से आता है जिसके बारे में NPS ने कभी नहीं सुना। वही उलझन लोगों को हर कर्मचारी का घरेलू IP जोड़ने पर ले जाती है, जो एक साथ अस्थिर और गलत है।
आप जो पता दर्ज करते हैं वह तीन शर्तें तय करती हैं
पहले, वह स्रोत पता खोजें जो गेटवे वास्तव में NPS की ओर उपयोग करता है। बहु-इंटरफ़ेस गेटवे अक्सर अपने सार्वजनिक VPN श्रोता के बजाय प्रबंधन या बैकएंड इंटरफ़ेस से भेजता है। दूसरे, जाँचें कि दोनों के बीच NAT है या नहीं: यदि अनुरोध अनूदित होता है, तो NPS अनूदित पता देखता है, और वही दर्ज करने योग्य मान है। तीसरे, यदि दो गेटवे भूमिका साझा करते हैं, तो हर अनुरोध स्रोत को अपनी अलग क्लाइंट प्रविष्टि चाहिए, क्योंकि एक पते वाला एक ऑब्जेक्ट उनमें से केवल एक को कवर करता है।
दो सिरों वाला रिकॉर्ड जोड़ी को सीधा रखता है। नीचे दी गई तालिका उदाहरण के लिए निजी पते उपयोग करती है, इसलिए उन्हें उन पतों से बदलें जो आपका पथ वास्तव में उपयोग करता है।
| At NPS | At the VPN gateway |
|---|---|
| RADIUS client address 10.20.0.10 | Authentication server 10.20.0.20 |
| Shared secret, agreed value | The same secret, same value |
| UDP 1812 permitted from 10.20.0.10 | UDP 1812 permitted toward 10.20.0.20 |
अनुमान लगाने के बजाय स्रोत की पुष्टि करें। एक प्रयास के दौरान NPS या फ़ायरवॉल लॉग देखें, या NPS होस्ट पर sudo tcpdump -ni any udp port 1812 से कैप्चर करें। उस कैप्चर का पता क्लाइंट प्रविष्टि के लिए एकमात्र तर्कसंगत उत्तर है। यदि गेटवे के कई संभावित स्रोत हैं, तो हर एक को उसके अपने मैत्रीपूर्ण नाम से दर्ज करें।
साझा गोपनीयता गेटवे और NPS के बीच का मान है
साझा गोपनीयता डिवाइस संबंध की प्रामाणिकता जाँचती है। यह उपयोगकर्ता पासवर्ड नहीं है और इसे कभी कर्मचारियों में नहीं बाँटा जाता या क्लाइंट प्रोफ़ाइल में नहीं डाला जाता।
एक मान चुनें, उसे दोनों जगह दर्ज करें, और उसे वहाँ रखें जहाँ गेटवे का कॉन्फ़िगरेशन बैकअप रहता है। बेमेल होने पर ऐसा अनुरोध बनता है जिसे NPS किसी उपयोगी त्रुटि के बिना छोड़ देता है, और गेटवे के लॉग में यह अप्राप्य सर्वर से अलग नहीं पहचाना जा सकता। रखरखाव विंडो में इसे बदलें और उसी परिवर्तन में दोनों सिरे अद्यतन करें।
एक अनुमत अनुरोध से पुष्टि करें
नियंत्रित खाता उपयोग करें और दोनों ओर एक प्रयास का मिलान करें। गेटवे पर पुष्टि करें कि अनुरोध इच्छित सर्वर की ओर गया; NPS पर पुष्टि करें कि वह दर्ज क्लाइंट से आया और अपेक्षित कनेक्शन अनुरोध नीति से मेल खाया। समय-समाप्ति और अस्वीकृति अलग-अलग बातें कहती हैं, और दोनों को क्रेडेंशियल समस्या मानने से अगला घंटा बर्बाद होता है। फिर एक वैध पर अपात्र खाता और गलत पासवर्ड जाँचें, क्योंकि सब कुछ स्वीकार करने वाली नीति पहली परीक्षा भी पास कर लेती है।
अंत में, देखें कि गेटवे लौटाए गए प्राधिकरण का क्या करता है। RADIUS क्लाइंट दर्ज करना केवल डिवाइस को भाग लेने देता है; यह हर परिणामी सत्र को LAN तक पहुँच नहीं देता।
निदान आउटपुट सीमित रखें: कोई साझा गोपनीयता नहीं, कोई उपयोगकर्ता पासवर्ड नहीं, सहायता टिकट में कोई पूरा पैकेट पेलोड नहीं। यदि डिज़ाइन चाहता है कि NPS सर्वर डायरेक्टरी विशेषताएँ पढ़े, तो वह अनुमति क्लाइंट पंजीकरण से अलग प्रशासनिक कार्य है, और उसके न होने पर यह अलग तरह से विफल होती है।