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 सर्व्हरने डिरेक्टरी गुणधर्म वाचणे आवश्यक असेल, तर ती परवानगी क्लायंट नोंदणीपासून वेगळे प्रशासकीय कार्य आहे, आणि ती नसल्यास ते वेगळ्या पद्धतीने अयशस्वी होते।