RouterOS OpenVPN en NPS: stel user-auth-method yn, net auth

RouterOS kin NPS berikke mei in OpenVPN-oanmelding en dochs wegere wurde, en de gewoane oarsaak is twa ynstellings wêrfan't de nammen beide as autentikaasje klinke. Ien kiest in kryptografyske digest foar de tunnel; de oare beslút hoe't de ynloggegevens fan de brûker oan RADIUS presintearre wurde. In digestwiziging sil nea in PAP-oanfraach yn MS-CHAPv2 feroarje, hoe faak de tsjinst ek werstart. De checklist hjirûnder skiedt de beide en folget dan ien mislearre oanmelding troch it NPS-belied dat it beoardiele hat.

Stap 1: lês beide ynstellings foardat jo ien feroarje

Print de effektive OpenVPN-serverkonfiguraasje op de router dy't de tunnel beëiniget, net út in reservekopy of in kopiearre forumberjocht. De twa fjilden dy't jo ynteressearje steane meastentiids yn itselde menu en lêze as wiene it alternativen. Dat binne se net: ien giet oer it datakanaal, de oare oer de útwikseling fan ynloggegevens.

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

It fjild auth listet digests lykas sha1 en sha256 en bewurket de HMAC dy't tunnelpakketten autentisearret. It fjild user-auth-method kiest pap of mschap2 en beslút hoe't de router de ynloggegevens fan de brûker oan RADIUS presintearret. In digestwiziging kin it twadde gedrach net feroarje, en dêrom oerlibbet deselde wegering elke oanpassing oan it earste.

Stop hjir as jo ferzje user-auth-method hielendal net oanbiedt. Aldere RouterOS-builds biede it miskien net oan op de OpenVPN-server, en de oplossing heart yn in ferzje dy't jo stypje kinne, net yn in opdracht kopiearre út in nijere.

Stap 2: fyn it belied dat de oanmelding echt wegere hat

Oan de NPS-kant wurdt in ferbiningsfersyk beoardiele tsjin netwurkbelied, en de autentikaasjemetoade neamd yn it byhearrende belied moat ien wêze dy't de klant echt oanbean hat. Korrelearje ien mislearre oanmelding op tiid en brûker ynstee fan in gearfettingsgetal te lêzen. It feiligensloch registrearret tastiene en wegere fersiken mei in oarsaakkoade, wat jo folle mear fertelt as de algemiene flaterrigel fan de router.

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

Lês trije dingen yn it evenemint: de namme fan it byhearrende belied, de autentikaasjemetoade en de oarsaakkoade. In belied dat MS-CHAPv2 easket, wiist in PAP-fersyk ôf sels as it wachtwurd korrekt is, en in belied dat in domeinaccount easket, wiist in lokaal ien ôf. De RADIUS-klantynskriuwing moat ek by it boarneadres fan de router passe, oars wurdt it fersyk weilitten foardat elk belied rieplachte wurdt. Neat dêrfan ferskynt yn it OpenVPN-loch.

Stop hjir as it fersyk NPS nea berikt. Dat is in probleem mei it dielde geheim, it klantadres of UDP 1812, en it feroarjen fan autentikaasjemetoaden sil dat net oplosse.

Stap 3: feroarje ien metoade, oan beide kanten

As it goedkarde ûntwerp MS-CHAPv2 is, stel it dan yn op de router en befêstigje dat it byhearrende belied it akseptearret. Feroarje ien kant, test opnij en feroarje dan de oare; beide tagelyk feroarje lit jo net mear sizze hokker fan belang wie.

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

Aktivearje net elke swakkere metoade op NPS om de flater ferdwine te litten. De backend moat materiaal hâlde dat de keazen metoade ferifiearje kin: MS-CHAPv2 hat tagong ta it wachtwurd of it domein nedich, en in belied kin dat materiaal net betinke. It belied ferbreedzjen ferbreedet ek wat in oanfaller tsjin itselde account besykje kin. Skriuw de metoade, de beliedsnamme en de wizigingsferwizing byinoar, sadat de folgjende persoan in beslút erft ynstee fan in gissing.

Hâld de sertifikaatfalidaasje fan de tunnel krekt sa't dy wie. In ynloggegevensmetoade ferfangt de serveridentiteit net, en it ferleegjen fan TLS-kontrôles om in test te heljen ruilet ien probleem foar in slimmer.

Stap 4: test trije oanmeldingen en ien tastimming

Test in tastiene brûker, in ferkeard wachtwurd en in útsletten brûker, elk yn in frisse sesje. De earste bewissiget it paad, de twadde bewissiget dat de kontrôle fan ynloggegevens echt is, en de tredde bewissiget dat it belied noch altyd útslút wa't it moat. In cache-sesje kin alle trije ferbergje, dus ferbrek tusken besikings.

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

Suksesfolle autentikaasje is net it ein fan 'e checklist. Kontrolearje it adres dat de klant krige en de boarnen dy't dat adres berikke kin, want in brûker kin korrekt autentisearje en dochs yn 'e ferkearde pool bedarje. As it tawiisde adres ferkeard is, sit it probleem yn it profyl of yn 'e RADIUS-antwurdattributen, net yn 'e metoade. Befêstigje beide foardat jo it ticket slute.

De checklist is klear as de routerynstelling en it NPS-belied deselde metoade neame, ien tastiene brûker ferbynt mei in frisse sesje, ien ferkeard wachtwurd wegere wurdt, ien útsletten brûker noch altyd útsletten is en it tawiisde adres by de bedoelde pool past. Alles minder lit de folgjende oanmelding oan it tafal oer.