RouterOS OpenVPN at NPS: itakda ang user-auth-method, hindi auth

Maaaring maabot ng RouterOS ang NPS gamit ang pag-login sa OpenVPN at tanggihan pa rin, at ang karaniwang dahilan ay dalawang setting na ang mga pangalan ay parehong parang authentication. Pinipili ng isa ang cryptographic digest para sa tunnel; pinapasya ng isa pa kung paano inihaharap ang mga kredensyal ng user sa RADIUS. Ang pagbabago ng digest ay hindi kailanman gagawing MS-CHAPv2 ang isang kahilingang PAP, gaano man kadalas mag-restart ang serbisyo. Hinihiwalay ng checklist sa ibaba ang dalawa, pagkatapos ay sinusundan ang isang nabigong pag-login sa patakaran ng NPS na humatol dito.

Hakbang 1: basahin ang dalawang setting bago baguhin ang alinman

I-print ang epektibong configuration ng OpenVPN server sa router na nagtatapos sa tunnel, hindi mula sa backup o kinopyang post sa forum. Ang dalawang field na mahalaga sa iyo ay karaniwang nasa parehong menu at binabasa na parang mga alternatibo. Hindi sila: isa ay tungkol sa data channel, ang isa ay tungkol sa pagpapalitan ng kredensyal.

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

Inililista ng field na auth ang mga digest tulad ng sha1 at sha256 at kinokontrol ang HMAC na nagpapatunay sa mga packet ng tunnel. Pinipili ng field na user-auth-method ang pap o mschap2 at pinapasya kung paano inihaharap ng router ang mga kredensyal ng user sa RADIUS. Hindi mababago ng pagbabago ng digest ang pangalawang pag-uugali, kaya't ang parehong pagtanggi ay nananatili pagkatapos ng bawat pagsasaayos sa una.

Huminto dito kung hindi inilalantad ng iyong release ang user-auth-method kahit ano. Maaaring hindi ito inaalok ng mas lumang build ng RouterOS sa OpenVPN server, at ang pag-aayos ay nabibilang sa release na maaari mong suportahan, hindi sa command na kinopya mula sa mas bago.

Hakbang 2: hanapin ang patakarang talagang tumanggi sa pag-login

Sa panig ng NPS, ang kahilingan sa koneksyon ay sinusuri laban sa mga patakaran ng network, at ang paraan ng authentication na nakasaad sa katugmang patakaran ay dapat isa sa aktwal na inialok ng client. Iugnay ang isang nabigong pag-login ayon sa oras at user sa halip na magbasa ng buod na bilang. Itinatala ng security log ang mga pinahintulutan at tinanggihang kahilingan na may reason code, na nagsasabi sa iyo ng higit pa kaysa sa pangkalahatang linya ng pagkabigo ng router.

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

Basahin ang tatlong bagay sa event: ang pangalan ng katugmang patakaran, ang paraan ng authentication at ang reason code. Ang patakarang nangangailangan ng MS-CHAPv2 ay tumatanggi sa kahilingang PAP kahit tama ang password, at ang patakarang nangangailangan ng domain account ay tumatanggi sa lokal. Dapat ding tumugma ang entry ng RADIUS client sa source address ng router, kung hindi ay itinatapon ang kahilingan bago pa man konsultahin ang anumang patakaran. Wala sa mga ito ang lumilitaw sa log ng OpenVPN.

Huminto dito kung hindi kailanman umaabot ang kahilingan sa NPS. Iyon ay problema sa shared secret, address ng client o UDP 1812, at hindi ito aayusin ng pagbabago ng mga paraan ng authentication.

Hakbang 3: baguhin ang isang paraan, sa magkabilang panig

Kung ang aprubadong disenyo ay MS-CHAPv2, itakda ito sa router at kumpirmahing tinatanggap ito ng katugmang patakaran. Baguhin ang isang panig, subukan muli, pagkatapos ay baguhin ang isa pa; ang pagbabago ng dalawa nang sabay ay nag-iiwan sa iyo na hindi masabi kung alin ang mahalaga.

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

Huwag paganahin ang bawat mas mahinang paraan sa NPS para mawala ang error. Dapat may materyal ang backend na maaaring i-verify ng napiling paraan: ang MS-CHAPv2 ay nangangailangan ng access sa password o sa domain, at hindi kayang imbentuhin ng patakaran ang materyal na iyon. Ang pagpapalawak ng patakaran ay nagpapalawak din sa maaaring subukan ng attacker laban sa parehong account. Itala nang sabay ang paraan, pangalan ng patakaran at reference ng pagbabago, upang ang susunod na tao ay magmana ng desisyon at hindi ng hula.

Iwanan ang validation ng certificate ng tunnel nang eksakto tulad ng dati. Ang paraan ng kredensyal ay hindi kapalit ng pagkakakilanlan ng server, at ang pagbaba ng mga pagsusuring TLS para pumasa ang isang test ay nagpapalit ng isang problema sa mas malala.

Hakbang 4: subukan ang tatlong pag-login at isang pahintulot

Subukan ang pinahintulutang user, maling password at ibinukod na user, bawat isa sa bagong session. Ang una ay nagpapatunay ng landas, ang pangalawa ay nagpapatunay na totoo ang pagsusuri ng kredensyal, at ang pangatlo ay nagpapatunay na ibinubukod pa rin ng patakaran ang dapat ibukod. Maaaring itago ng naka-cache na session ang tatlo, kaya mag-disconnect sa pagitan ng mga pagtatangka.

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

Ang tagumpay ng authentication ay hindi katapusan ng checklist. Suriin ang address na natanggap ng client at ang mga resource na maaabot ng address na iyon, dahil ang isang user ay maaaring mag-authenticate nang tama at mapunta pa rin sa maling pool. Kung mali ang itinalagang address, ang problema ay nasa profile o sa mga attribute ng tugon ng RADIUS, hindi sa paraan. Kumpirmahin ang dalawa bago isara ang ticket.

Kumpleto ang checklist kapag pinangalanan ng setting ng router at patakaran ng NPS ang parehong paraan, kumonekta ang pinahintulutang user gamit ang bagong session, tinanggihan ang maling password, nananatiling ibinukod ang ibinukod na user, at tumutugma ang itinalagang address sa nilalayong pool. Anumang kulang doon ay iniiwan ang susunod na pag-login sa pagkakataon.