RouterOS OpenVPN և NPS. սահմանեք user-auth-method, ոչ թե auth

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 քաղաքականությունը նշում են նույն եղանակը, թույլատրված օգտվողը միանում է նոր նստաշրջանով, սխալ գաղտնաբառը մերժվում է, բացառված օգտվողը մնում է բացառված, և հատկացված հասցեն համապատասխանում է նախատեսված լողավազանին։ Ավելի քիչը հաջորդ մուտքը թողնում է պատահականությանը։