RouterOS OpenVPN и NPS: поставете user-auth-method, а не auth

Во RouterOS, auth го избира диџестот на тунелот, а user-auth-method одлучува како се проверува барањето RADIUS. Усогласете го второто со политиката на NPS.

RouterOS може да стигне до NPS со OpenVPN најава и сепак да биде одбиен, а вообичаената причина се две поставки чии имиња и двете звучат како автентикација. Едната избира криптографски диџест за тунелот; другата одлучува како се презентираат податоците за најава на корисникот до 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 го именуваат истиот метод, дозволен корисник се поврзува со нова сесија, погрешна лозинка се одбива, исклучен корисник останува исклучен и доделената адреса одговара на предвидениот базен. Помалото од тоа го остава следното најавување на случајноста.

Поврзани статии