RouterOS gali pasiekti NPS su OpenVPN prisijungimu ir vis tiek būti atmestas, o įprasta priežastis yra du nustatymai, kurių pavadinimai abu skamba kaip autentifikacija. Vienas parenka kriptografinę tunelio santrauką; kitas nusprendžia, kaip vartotojo prisijungimo duomenys pateikiami RADIUS. Santraukos pakeitimas niekada nepaverčia PAP užklausos MS-CHAPv2, kad ir kiek kartų paslauga būtų paleista iš naujo. Toliau pateiktas kontrolinis sąrašas atskiria abu ir tada seka vieną nepavykusį prisijungimą per NPS politiką, kuri jį įvertino.

1 žingsnis: perskaitykite abu nustatymus prieš keisdami bet kurį

Išspausdinkite galiojančią OpenVPN serverio konfigūraciją maršrutizatoriuje, kuris užbaigia tunelį, o ne iš atsarginės kopijos ar nukopijuoto forumo įrašo. Du jus dominantys laukai paprastai yra tame pačiame meniu ir skaitomi taip, lyg būtų alternatyvos. Jie nėra: vienas susijęs su duomenų kanalu, kitas su prisijungimo duomenų mainais.

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

Laukas auth išvardija santraukas, tokias kaip sha1 ir sha256, ir valdo HMAC, kuris autentifikuoja tunelio paketus. Laukas user-auth-method parenka pap arba mschap2 ir nusprendžia, kaip maršrutizatorius pateikia vartotojo prisijungimo duomenis RADIUS. Santraukos pakeitimas negali pakeisti antrojo elgesio, todėl tas pats atmetimas išlieka po kiekvieno pirmojo koregavimo.

Sustokite čia, jei jūsų leidimas visai neatskleidžia user-auth-method. Senesnės RouterOS versijos gali jo nesiūlyti OpenVPN serveryje, o pataisymas priklauso leidimui, kurį galite palaikyti, o ne komandai, nukopijuotai iš naujesnio.

2 žingsnis: raskite politiką, kuri iš tikrųjų atmetė prisijungimą

NPS pusėje prisijungimo užklausa vertinama pagal tinklo politikas, o atitinkančioje politikoje nurodytas autentifikacijos metodas turi būti vienas iš tų, kuriuos klientas iš tikrųjų pasiūlė. Susiekite vieną nepavykusį prisijungimą pagal laiką ir vartotoją, o ne skaitykite suvestinį skaičių. Saugos žurnalas įrašo leistas ir atmestas užklausas su priežasties kodu, o tai pasako daug daugiau nei bendra maršrutizatoriaus klaidos eilutė.

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

Įvykyje perskaitykite tris dalykus: atitinkančios politikos pavadinimą, autentifikacijos metodą ir priežasties kodą. Politika, reikalaujanti MS-CHAPv2, atmeta PAP užklausą net kai slaptažodis teisingas, o politika, reikalaujanti domeno paskyros, atmeta vietinę. RADIUS kliento įrašas taip pat turi atitikti maršrutizatoriaus šaltinio adresą, kitaip užklausa atmetama dar neperžiūrėjus jokios politikos. Niekas iš to neatsiranda OpenVPN žurnale.

Sustokite čia, jei užklausa niekada nepasiekia NPS. Tai bendros paslapties, kliento adreso arba UDP 1812 problema, ir autentifikacijos metodų keitimas jos neišspręs.

3 žingsnis: pakeiskite vieną metodą abiejose pusėse

Jei patvirtintas sprendimas yra MS-CHAPv2, nustatykite jį maršrutizatoriuje ir patvirtinkite, kad atitinkanti politika jį priima. Pakeiskite vieną pusę, dar kartą išbandykite, tada pakeiskite kitą; keitus abi iš karto nebegalėsite pasakyti, kuri buvo svarbi.

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

Neįjunkite NPS visų silpnesnių metodų, kad klaida išnyktų. Sistema turi turėti medžiagą, kurią pasirinktas metodas gali patikrinti: MS-CHAPv2 reikia prieigos prie slaptažodžio ar domeno, o politika negali tos medžiagos išgalvoti. Politikos išplėtimas taip pat išplečia, ką užpuolikas gali išbandyti prieš tą pačią paskyrą. Užrašykite metodą, politikos pavadinimą ir pakeitimo nuorodą kartu, kad kitas žmogus paveldėtų sprendimą, o ne spėjimą.

Palikite tunelio sertifikato tikrinimą lygiai tokį, koks buvo. Prisijungimo duomenų metodas nepakeičia serverio tapatybės, o TLS patikrų sumažinimas, kad testas praeitų, vieną problemą keičia blogesne.

4 žingsnis: išbandykite tris prisijungimus ir vieną leidimą

Išbandykite leidžiamą vartotoją, neteisingą slaptažodį ir neleidžiamą vartotoją, kiekvieną naujoje sesijoje. Pirmasis įrodo kelią, antrasis įrodo, kad prisijungimo duomenų tikrinimas tikras, o trečiasis įrodo, kad politika vis dar neleidžia tų, kurių neturėtų. Talpykloje saugoma sesija gali paslėpti visus tris, todėl atsijunkite tarp bandymų.

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

Sėkminga autentifikacija nėra kontrolinio sąrašo pabaiga. Patikrinkite adresą, kurį gavo klientas, ir išteklius, kuriuos tas adresas gali pasiekti, nes vartotojas gali teisingai autentifikuotis ir vis tiek patekti į netinkamą baseiną. Jei priskirtas adresas neteisingas, problema yra profilyje arba RADIUS atsakymo atributuose, o ne metode. Patvirtinkite abu prieš uždarydami bilietą.

Kontrolinis sąrašas baigtas, kai maršrutizatoriaus nustatymas ir NPS politika nurodo tą patį metodą, leidžiamas vartotojas prisijungia naujoje sesijoje, neteisingas slaptažodis atmetamas, neleidžiamas vartotojas lieka neleidžiamas, o priskirtas adresas atitinka numatytą baseiną. Viskas mažiau palieka kitą prisijungimą atsitiktinumui.

Susiję straipsniai