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