Hogyan jut el a VPN-bejelentkezés a RADIUS-hoz és az identitásszolgáltatójához
Kövesse végig a VPN-bejelentkezést az ügyféltől az átjáró RADIUS-kéréséig, a mögötte álló identitásszolgáltatóig és az elfogadás után alkalmazott szabályig.
Múlt héten egy felhasználó be tudott jelentkezni a VPN-be, és mégis olyan hálózatra került, ahol semmi sem oldódott fel. Az ügyfél azt mondta, kapcsolódva, az átjáró naplója Access-Acceptet írt, az identitáscsapat pedig azt, hogy a fiók rendben van. A bejelentkezés működött; a mögötte lévő engedélyezés nem. Amikor egy VPN-bejelentkezés meghiúsul, végigjárom azt az útvonalat, amelyet a kérés valóban bejár — ügyfél, átjáró, RADIUS-kiszolgáló, identitásszolgáltató —, és az első olyan ugrásnál állok meg, amelynek válasza nem egyezik a következőével.
Az ügyfél soha nem beszél RADIUS-t
Bármit is mutat a laptopon lévő alkalmazás, az első ugrása a VPN-protokoll: IKEv2, OpenVPN, WireGuard vagy TLS-alapú ügyfél. A RADIUS nem jelenik meg ebben a cserében. Az ügyfél tanúsítvánnyal, felhasználónévvel és jelszóval, vagy az alagút beállításán belül szállított EAP-módszerrel hitelesít az átjárónál.
Ez akkor számít, amikor naplókat olvas, mert az általános hitelesítési hibát, amelyet a felhasználó lát, az átjáró állítja elő, miután már beszélt valami mással. Ha az ügyfél soha nem éri el az átjárót, nincs hibakereshető RADIUS-kérés, és a RADIUS-kiszolgálón eltöltött egy óra elveszik. Erősítse meg, hogy az alagút egyáltalán feljött, mielőtt a háttérrendszerhez nyúl.
Az átjáró a RADIUS-ügyfél
Amint az alagút beállítása eléri azt a pontot, ahol a hitelesítő adatokat ellenőrizni kell, az átjáró hálózati hozzáférési kiszolgálóvá válik. Összeállít egy Access-Requestet: User-Name, jelszó vagy EAP-adat, NAS-IP-Address vagy NAS-Identifier, és Message-Authenticator, amikor a módszer megköveteli. A kérés alapértelmezés szerint UDP 1812-re, az elszámolás 1813-ra megy. A régebbi telepítések még mindig 1645-öt és 1646-ot használnak, ezért az egy párra írt tűzfal-szabály sok csendes hibát megmagyaráz.
Mindkét fél osztozik egy titkon, és az nem felhasználói hitelesítő adat. Aláírja a cserét, és minden választ ellene ellenőriznek. Állítsa be a titkot eltérően a két oldalon, és a kiszolgáló nem rossz titokkal válaszol — eldobja a kérést, vagy a válasz nem megy át az ellenőrzésen, így az átjáró időtúllépést jelent. Egy rossz titok és egy halott kiszolgáló az átjáró felől ugyanúgy néz ki, ezért ügyféleszközzel tesztelem az ugrást, mielőtt a könyvtárat hibáztatom.
A protokoll kicsi és régi — a RFC 2865 határozza meg a hitelesítési cserét —, de az általa szállított attribútumok azok, amelyekre a legtöbb VPN-szabály épül.
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'A RADIUS-kiszolgáló lehet, hogy csak az identitásszolgáltató előtere
Az emberek úgy beszélnek a RADIUS-ról és az identitásszolgáltatóról, mintha ugyanaz a doboz lenne. Gyakran nem az. A RADIUS-kiszolgáló megkapja az Access-Requestet, majd válaszadás előtt megkérdez valami mást — Active Directoryt LDAP-on vagy Kerberoson keresztül, helyi felhasználói fájlt vagy külső szolgáltatást. A FreeRADIUS az LDAP- vagy krb5-modullal, a Windows NPS és a Cisco ISE mind ebben a helyzetben áll.
A különbség dönti el, hova nézzen. Az elutasított jelszó az identitásszolgáltató válasza, amelyet a RADIUS továbbít. Az időtúllépés általában a RADIUS és a könyvtár közötti szakasz: lejárt bind-fiók, elérhetetlen könyvtár vagy rossz háttérrendszerhez irányított kérés. Ha a felhasználónév tartományi utótagot visel, a kiszolgáló ez alapján irányíthat, és ugyanaz a fiók CORP\alice és [email protected] formában küldve különböző helyekre kerülhet. A Windows NPS-ben a Security napló 6272-t rögzít engedélyezéskor és 6273-at elutasításkor, ami megmondja, hogy a döntés egyáltalán az NPS-től jött-e.
A hibát azon az ugráson olvassa, amely előállította
Egyetlen nem-tud-csatlakozni üzenet négy különböző hibát fed le. Mielőtt bármit módosítana, párosítsa a tünetet azzal az ugrással, amely előállította.
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
Az utolsó sor az, amely rossz csapathoz küldi az embereket. Az Access-Accept azt jelenti, hogy a hitelesítő adatokat elfogadták; nem azt, hogy az átjáró a megfelelő poolba helyezte a felhasználót, vagy útvonalakat tolt. A csoportattribútumok csak akkor számítanak, ha az átjáró szabálya olvassa őket. Láttam helyes bejelentkezést vendég poolba esni, mert a csoportleképezés a RADIUS oldalán más attribútumra volt beállítva, mint amelyet az átjáró vizsgál.
Kövessen végig egy bejelentkezést elejétől a végéig
Válasszon egyetlen tesztfiókot és egy átjárót, majd figyelje ugyanazt a kísérletet mind a négy ponton. Indítson hibakeresést a RADIUS oldalán — a freeradius -X kiírja a kérést és minden modult, amelyet megérint —, kövesse az átjáró hitelesítési naplóját, és futtassa a tcpdumpot az UDP-cseréhez. Csatlakozzon egyszer, és olvassa el a négy nyomot sorrendben.
Amit látni szeretne, az az egyetértés: az átjáró a várt felhasználóról kérdezett, a RADIUS-kiszolgáló a várt háttérrendszert választotta, az a háttérrendszer döntést adott vissza, és a válasz attribútumai megfelelnek az átjáró által alkalmazott szabálynak. Az első hely, ahol a nyomok eltérnek, a hiba határvonala. Ha a válasz nem hordoz csoportattribútumot, a probléma a RADIUS oldalán van, nem a VPN-profilban; ha az attribútum ott van, és az átjáró figyelmen kívül hagyja, az átjáró szabálya a probléma.
Egy biztonsági megjegyzés, amíg ott van. A megosztott titok védi a cserét, de a legtöbb attribútumot nem titkosítja. Ha az átjáró és a RADIUS-kiszolgáló külön szegmenseken van, tegye azt az ugrást RADIUS-ra TLS-en vagy magánúton. A titkosított felhasználói alagút semmit sem mond a háttérrendszer kapcsolatáról.
Mielőtt lezárja a jegyet, erősítsen meg négy dolgot. Az átjáró eléri a RADIUS-kiszolgálót azon a porton, amelyre valóban be van állítva. A megosztott titok mindkét oldalon egyezik. A RADIUS-kiszolgáló feloldja az átjáró által küldött felhasználónév pontos formáját. Az elfogadás hordozza azokat az attribútumokat, amelyekre az átjáró szabályának szüksége van. Ha mind a négy teljesül, egy továbbra is meghiúsuló bejelentkezés átjárószabály-probléma, nem hitelesítési probléma.