RouterOS OpenVPN dhe NPS: vendos user-auth-method, jo auth
Në RouterOS, auth zgjedh digestin e tunelit ndërsa user-auth-method vendos si verifikohet kërkesa RADIUS. Përshtat të dytën me politikën NPS.
RouterOS mund të arrijë NPS me një hyrje OpenVPN dhe gjithsesi të refuzohet, dhe shkaku i zakonshëm janë dy cilësime emrat e të cilave tingëllojnë të dy si vërtetim. Njëri zgjedh një digest kriptografik për tunelin; tjetri vendos si kredencialet e përdoruesit paraqiten te RADIUS. Ndryshimi i digestit nuk do ta kthejë kurrë një kërkesë PAP në MS-CHAPv2, sado herë të rinisë shërbimi. Lista e kontrollit më poshtë i ndan të dyja, pastaj ndjek një hyrje të dështuar përmes politikës NPS që e gjykoi.
Hapi 1: lexo të dyja cilësimet përpara se të ndryshosh ndonjë
Printo konfigurimin efektiv të serverit OpenVPN në ruterin që përfundon tunelin, jo nga një kopje rezervë ose një postim forumi i kopjuar. Dy fushat që të interesojnë zakonisht ndodhen në të njëjtin menu dhe lexohen sikur të ishin alternativa. Nuk janë: njëra ka të bëjë me kanalin e të dhënave, tjetra me shkëmbimin e kredencialeve.
/interface ovpn-server server print
/interface ovpn-server server export
Fusha auth liston digeste si sha1 dhe sha256 dhe kontrollon HMAC-in që vërteton paketat e tunelit. Fusha user-auth-method zgjedh pap ose mschap2 dhe vendos si ruteri paraqet kredencialet e përdoruesit te RADIUS. Ndryshimi i digestit nuk mund të ndryshojë sjelljen e dytë, dhe për këtë arsye i njëjti refuzim mbijeton çdo rregullim të të parit.
Ndal këtu nëse versioni yt nuk e ekspozon fare user-auth-method. Ndërtimet më të vjetra të RouterOS mund të mos e ofrojnë në serverin OpenVPN, dhe rregullimi i takon një versioni që mund të mbështesësh, jo një komande të kopjuar nga një më i ri.
Hapi 2: gjej politikën që e refuzoi vërtet hyrjen
Në anën e NPS, një kërkesë lidhjeje vlerësohet kundrejt politikave të rrjetit, dhe metoda e vërtetimit e përmendur në politikën përkatëse duhet të jetë një që klienti e ofroi vërtet. Lidh një hyrje të dështuar sipas kohës dhe përdoruesit në vend që të lexosh një numër përmbledhës. Regjistri i sigurisë shënon kërkesat e miratuara dhe të refuzuara me një kod arsyeje, që të tregon shumë më tepër se rreshti i përgjithshëm i dështimit të ruterit.
Get-WinEvent -LogName Security -MaxEvents 200 |
Where-Object { $_.Id -in 6272,6273 } |
Format-List TimeCreated,Id,Message
Lexo tre gjëra në ngjarje: emrin e politikës përkatëse, metodën e vërtetimit dhe kodin e arsyes. Një politikë që kërkon MS-CHAPv2 refuzon një kërkesë PAP edhe kur fjalëkalimi është i saktë, dhe një politikë që kërkon një llogari domeni refuzon një lokale. Zëri i klientit RADIUS duhet të përputhet gjithashtu me adresën burimore të ruterit, përndryshe kërkesa hidhet poshtë përpara se të konsultohet çdo politikë. Asnjë prej këtyre nuk shfaqet në regjistrin e OpenVPN.
Ndal këtu nëse kërkesa nuk arrin kurrë te NPS. Ky është problem i sekretit të përbashkët, adresës së klientit ose UDP 1812, dhe ndryshimi i metodave të vërtetimit nuk do ta rregullojë.
Hapi 3: ndrysho një metodë, nga të dyja anët
Nëse dizajni i miratuar është MS-CHAPv2, vendose në ruter dhe konfirmo që politika përkatëse e pranon. Ndrysho njërën anë, testoj përsëri dhe pastaj ndrysho tjetrën; ndryshimi i të dyjave njëherësh të lë pa mundësi të thuash cila kishte rëndësi.
/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"
Mos aktivizo çdo metodë më të dobët në NPS që gabimi të zhduket. Backend-i duhet të ketë material që metoda e zgjedhur mund ta verifikojë: MS-CHAPv2 ka nevojë për akses te fjalëkalimi ose domeni, dhe një politikë nuk mund ta sajojë atë material. Zgjerimi i politikës zgjeron edhe çfarë mund të provojë një sulmues kundër të njëjtit llogari. Shkruaj bashkë metodën, emrin e politikës dhe referencën e ndryshimit, që personi tjetër të trashëgojë një vendim, jo një supozim.
Lëre vërtetimin e certifikatës së tunelit saktësisht siç ishte. Një metodë kredencialesh nuk zëvendëson identitetin e serverit, dhe ulja e kontrolleve TLS që një test të kalojë ndërron një problem me një më të keq.
Hapi 4: testo tre hyrje dhe një leje
Testo një përdorues të lejuar, një fjalëkalim të gabuar dhe një përdorues të përjashtuar, secili në një sesion të re. I pari vërteton rrugën, i dyti vërteton që kontrolli i kredencialeve është i vërtetë, dhe i treti vërteton që politika ende përjashton ata që duhet. Një sesion i ruajtur në cache mund t'i fshehë të tre, prandaj shkëputu midis provave.
/log print where topics~"ovpn"
/radius monitor 0
Suksesi i vërtetimit nuk është fundi i listës së kontrollit. Kontrollo adresën që mori klienti dhe burimet që ajo adresë mund të arrijë, sepse një përdorues mund të vërtetohet saktë dhe gjithsesi të përfundojë në pishinën e gabuar. Nëse adresa e caktuar është e gabuar, problemi qëndron në profil ose në atributet e përgjigjes RADIUS, jo në metodë. Konfirmo të dyja përpara se të mbyllësh tiketën.
Lista plotësohet kur cilësimi i ruterit dhe politika NPS emërtojnë të njëjtën metodë, një përdorues i lejuar lidhet me një sesion të re, një fjalëkalim i gabuar refuzohet, një përdorues i përjashtuar mbetet i përjashtuar dhe adresa e caktuar përputhet me pishinën e synuar. Çdo gjë më pak e lë hyrjen tjetër në dorë të rastit.