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 सर्भरले डाइरेक्टरी विशेषता पढ्नुपर्ने माग गर्छ भने त्यो अनुमति क्लाइन्ट दर्ताबाट अलग प्रशासनिक कार्य हो, र त्यो नभएमा यो फरक तरिकाले असफल हुन्छ।