RouterOS OpenVPN és NPS: a user-auth-methodot állítsd be, ne az auth-ot

A RouterOS OpenVPN-bejelentkezéssel is elérheti az NPS-t, és mégis elutasíthatják, és a szokásos ok két beállítás, amelyeknek a neve egyaránt hitelesítésnek hangzik. Az egyik kriptográfiai digestet választ az alagúthoz; a másik eldönti, hogyan kerülnek a felhasználó hitelesítő adatai a RADIUS elé. A digest megváltoztatása soha nem alakít egy PAP-kérést MS-CHAPv2-vé, akárhányszor indul újra a szolgáltatás. Az alábbi ellenőrzőlista szétválasztja a kettőt, majd végigkövet egyetlen sikertelen bejelentkezést azon az NPS-szabályzaton keresztül, amely elbírálta.

1. lépés: olvasd el mindkét beállítást, mielőtt bármelyiket módosítanád

Nyomtasd ki az alagutat lezáró router OpenVPN-kiszolgáló hatékony konfigurációját, ne egy biztonsági mentésből vagy egy másolt fórumbejegyzésből. A két érdekes mező általában ugyanabban a menüben van, és úgy olvasható, mintha alternatívák lennének. Nem azok: az egyik az adatcsatornáról szól, a másik a hitelesítő adatok cseréjéről.

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

A auth mező digesteket sorol fel, például sha1 és sha256, és azt a HMAC-ot vezérli, amely az alagút csomagjait hitelesíti. A user-auth-method mező papot vagy mschap2-t választ, és eldönti, hogyan mutatja be a router a felhasználó hitelesítő adatait a RADIUS-nak. A digest változtatása nem módosíthatja a második viselkedést, ezért ugyanaz az elutasítás minden elsőre tett módosítást túlél.

Állj meg itt, ha a kiadásod egyáltalán nem teszi elérhetővé a user-auth-method-at. A régebbi RouterOS-verziók esetleg nem kínálják az OpenVPN-kiszolgálón, és a javítás egy általad támogatható kiadásba tartozik, nem egy újabbról másolt parancsba.

2. lépés: keresd meg a szabályzatot, amely ténylegesen elutasította a bejelentkezést

Az NPS oldalán a kapcsolati kérést hálózati szabályzatok alapján értékelik, és az egyező szabályzatban megnevezett hitelesítési módszernek olyannak kell lennie, amelyet az ügyfél ténylegesen felajánlott. Egy sikertelen bejelentkezést idő és felhasználó szerint korrelálj, ne egy összesített számot olvass. A biztonsági napló rögzíti az engedélyezett és megtagadott kéréseket egy okkóddal, ami sokkal többet mond a router általános hibasoránál.

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

Három dolgot olvass az eseményben: az egyező szabályzat nevét, a hitelesítési módszert és az okkódot. Az MS-CHAPv2-t megkövetelő szabályzat a helyes jelszó esetén is elutasítja a PAP-kérést, a tartományi fiókot megkövetelő szabályzat pedig a helyit utasítja el. A RADIUS-ügyfél bejegyzésének is meg kell egyeznie a router forráscímével, különben a kérés még bármely szabályzat vizsgálata előtt eldobódik. Ezek egyike sem jelenik meg az OpenVPN-naplóban.

Állj meg itt, ha a kérés soha nem ér el az NPS-hez. Ez megosztott titok, ügyfélcím vagy UDP 1812 problémája, és a hitelesítési módszerek módosítása nem javítja.

3. lépés: változtass egy módszert, mindkét oldalon

Ha a jóváhagyott terv MS-CHAPv2, állítsd be a routeren, és igazold, hogy az egyező szabályzat elfogadja. Változtass az egyik oldalon, teszteld újra, majd a másikon; mindkettő egyszerre történő módosítása után nem tudod megmondani, melyik számított.

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

Ne engedélyezz minden gyengébb módszert az NPS-en, hogy a hiba eltűnjön. A háttérrendszernek olyan anyagot kell tartania, amelyet a választott módszer ellenőrizni tud: az MS-CHAPv2-nek hozzáférés kell a jelszóhoz vagy a tartományhoz, és egy szabályzat nem találhatja ki ezt az anyagot. A szabályzat szélesítése szélesíti azt is, amit egy támadó ugyanazon fiók ellen kipróbálhat. Rögzítsd együtt a módszert, a szabályzat nevét és a változtatás hivatkozását, hogy a következő ember döntést örököljön, ne találgatást.

Hagyd az alagút tanúsítványának ellenőrzését pontosan úgy, ahogy volt. A hitelesítő adatok módszere nem helyettesíti a kiszolgáló identitását, és a TLS-ellenőrzések csökkentése egy teszt átengedéséért egy problémát rosszabbra cserél.

4. lépés: tesztelj három bejelentkezést és egy engedélyt

Tesztelj egy engedélyezett felhasználót, egy rossz jelszót és egy kizárt felhasználót, mindegyiket friss munkamenetben. Az első az útvonalat bizonyítja, a második azt, hogy a hitelesítőadat-ellenőrzés valódi, a harmadik pedig azt, hogy a szabályzat továbbra is kizárja, akit kell. A gyorsítótárazott munkamenet mindhármat elrejtheti, ezért a kísérletek között bontsd a kapcsolatot.

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

A sikeres hitelesítés nem az ellenőrzőlista vége. Ellenőrizd az ügyfél által kapott címet és azokat az erőforrásokat, amelyeket az a cím elérhet, mert egy felhasználó helyesen is hitelesíthet, és mégis rossz poolba kerülhet. Ha a kiosztott cím rossz, a probléma a profilban vagy a RADIUS-válasz attribútumaiban van, nem a módszerben. Mindkettőt igazold a jegy lezárása előtt.

Az ellenőrzőlista akkor van kész, ha a router beállítása és az NPS-szabályzat ugyanazt a módszert nevezi meg, egy engedélyezett felhasználó friss munkamenettel csatlakozik, egy rossz jelszó elutasításra kerül, egy kizárt felhasználó továbbra is ki van zárva, és a kiosztott cím megfelel a tervezett poolnak. Ennél kevesebb a következő bejelentkezést a véletlenre bízza.