RouterOS OpenVPN और NPS: auth नहीं, user-auth-method सेट करें

RouterOS OpenVPN लॉगिन के साथ NPS तक पहुँच सकता है और फिर भी अस्वीकार हो सकता है, और सामान्य कारण दो सेटिंग्स हैं जिनके नाम दोनों प्रमाणीकरण जैसे लगते हैं। एक टनल के लिए क्रिप्टोग्राफ़िक डाइजेस्ट चुनती है; दूसरी तय करती है कि उपयोगकर्ता के क्रेडेंशियल RADIUS को कैसे प्रस्तुत किए जाएँ। डाइजेस्ट बदलने से PAP अनुरोध कभी MS-CHAPv2 नहीं बनेगा, चाहे सेवा कितनी भी बार पुनः आरंभ हो। नीचे दी गई चेकलिस्ट दोनों को अलग करती है और फिर एक असफल लॉगिन को उस NPS नीति के माध्यम से ट्रेस करती है जिसने उसका निर्णय किया।

चरण 1: कोई भी बदलने से पहले दोनों सेटिंग्स पढ़ें

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

/interface ovpn-server server print
/interface ovpn-server server export

auth फ़ील्ड sha1 और sha256 जैसे डाइजेस्ट सूचीबद्ध करता है और उस HMAC को नियंत्रित करता है जो टनल पैकेट प्रमाणित करता है। user-auth-method फ़ील्ड pap या mschap2 चुनता है और तय करता है कि राउटर उपयोगकर्ता के क्रेडेंशियल RADIUS को कैसे प्रस्तुत करेगा। डाइजेस्ट परिवर्तन दूसरे व्यवहार को नहीं बदल सकता, इसलिए पहले में हर बदलाव के बाद वही अस्वीकृति बनी रहती है।

अगर आपका संस्करण user-auth-method बिल्कुल प्रदान नहीं करता तो यहीं रुकें। पुराने RouterOS बिल्ड इसे OpenVPN सर्वर पर नहीं दे सकते, और सुधार उस संस्करण में होना चाहिए जिसे आप सहायता दे सकें, न कि नए संस्करण से कॉपी किए गए कमांड में।

चरण 2: वह नीति खोजें जिसने वास्तव में लॉगिन अस्वीकार किया

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

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

घटना में तीन चीजें पढ़ें: मेल खाने वाली नीति का नाम, प्रमाणीकरण विधि और कारण कोड। MS-CHAPv2 मांगने वाली नीति सही पासवर्ड होने पर भी PAP अनुरोध अस्वीकार करती है, और डोमेन खाता मांगने वाली नीति स्थानीय खाता अस्वीकार करती है। RADIUS क्लाइंट प्रविष्टि को राउटर के स्रोत पते से भी मेल खाना चाहिए, अन्यथा किसी भी नीति से परामर्श से पहले अनुरोध गिरा दिया जाता है। इनमें से कुछ भी OpenVPN लॉग में नहीं दिखता।

अगर अनुरोध कभी NPS तक नहीं पहुँचता तो यहीं रुकें। यह साझा गुप्त, क्लाइंट पता या UDP 1812 की समस्या है, और प्रमाणीकरण विधियाँ बदलने से यह ठीक नहीं होगी।

चरण 3: दोनों ओर एक विधि बदलें

अगर स्वीकृत डिज़ाइन MS-CHAPv2 है, तो इसे राउटर पर सेट करें और पुष्टि करें कि मेल खाने वाली नीति इसे स्वीकार करती है। एक ओर बदलें, फिर परीक्षण करें, फिर दूसरी ओर बदलें; दोनों एक साथ बदलने से आप यह नहीं बता पाएँगे कि कौन महत्वपूर्ण था।

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

त्रुटि गायब करने के लिए NPS पर हर कमजोर विधि सक्षम न करें। बैकएंड के पास ऐसी सामग्री होनी चाहिए जिसे चुनी गई विधि सत्यापित कर सके: MS-CHAPv2 को पासवर्ड या डोमेन तक पहुँच चाहिए, और नीति उस सामग्री को गढ़ नहीं सकती। नीति को चौड़ा करने से यह भी चौड़ा होता है कि हमलावर उसी खाते के विरुद्ध क्या आज़मा सकता है। विधि, नीति का नाम और परिवर्तन संदर्भ एक साथ दर्ज करें, ताकि अगला व्यक्ति अनुमान के बजाय निर्णय विरासत में पाए।

टनल का प्रमाणपत्र सत्यापन बिल्कुल पहले जैसा रखें। क्रेडेंशियल विधि सर्वर पहचान का विकल्प नहीं है, और परीक्षण पास कराने के लिए TLS जाँच घटाना एक समस्या के बदले बदतर समस्या लाता है।

चरण 4: तीन लॉगिन और एक अनुमति जाँचें

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

/log print where topics~"ovpn"
/radius monitor 0

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

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