RouterOS OpenVPN და NPS: დააყენეთ user-auth-method და არა auth

RouterOS-ში auth ირჩევს გვირაბის დაიჯესტს, ხოლო user-auth-method განსაზღვრავს, როგორ მოწმდება RADIUS მოთხოვნა. მეორე შეუსაბამეთ NPS პოლიტიკას.

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 პოლიტიკა ერთსა და იმავე მეთოდს ასახელებს, დაშვებული მომხმარებელი ახალი სესიით უკავშირდება, არასწორი პაროლი უარყოფილია, გამორიცხული მომხმარებელი კვლავ გამორიცხულია და მინიჭებული მისამართი შეესაბამება განკუთვნილ აუზს. ამაზე ნაკლები შემდეგ შესვლას შემთხვევას ანდობს.

დაკავშირებული სტატიები