Ako sa prihlásenie do VPN dostane do RADIUS a k vášmu poskytovateľovi identity
Prejdite prihlásenie do VPN od klienta k RADIUS požiadavke brány, poskytovateľovi identity za ňou a politike uplatnenej po prijatí.
Minulý týždeň sa používateľ mohol prihlásiť do VPN a napriek tomu skončil v sieti, kde sa nič nerozlišovalo. Klient hlásil pripojené, log brány hlásil Access-Accept a tím identity hovoril, že účet je v poriadku. Prihlásenie fungovalo; autorizácia za ním nie. Keď prihlásenie do VPN zlyhá, idem cestou, ktorou požiadavka skutočne prechádza — klient, brána, server RADIUS, poskytovateľ identity — a zastavím sa pri prvom skoku, ktorého odpoveď nesúhlasí s nasledujúcou.
Klient nikdy nehovorí RADIUS
Čokoľvek aplikácia na notebooku zobrazuje, jej prvým skokom je protokol VPN: IKEv2, OpenVPN, WireGuard alebo klient založený na TLS. RADIUS sa v tejto výmene neobjavuje. Klient sa autentizuje voči bráne certifikátom, používateľským menom a heslom alebo metódou EAP prenášanou v nastavení tunela.
To je dôležité pri čítaní logov, pretože všeobecnú chybu autentizácie, ktorú používateľ vidí, vytvára brána po tom, čo už hovorila s niečím iným. Ak sa klient nikdy nedostane k bráne, neexistuje žiadna RADIUS požiadavka na ladenie a hodina strávená na serveri RADIUS je stratená. Potvrďte, že tunel vôbec vznikol, skôr než sa dotknete backendu.
Brána je RADIUS klient
Akonáhle nastavenie tunela dospeje do bodu, keď treba overiť prihlasovacie údaje, brána sa stane serverom sieťového prístupu. Zostaví Access-Request: User-Name, heslo alebo EAP payload, NAS-IP-Address alebo NAS-Identifier a Message-Authenticator, keď to metóda vyžaduje. Požiadavka ide predvolene na UDP 1812 a účtovanie na 1813. Staršie nasadenia stále používajú 1645 a 1646, takže pravidlo firewallu napísané pre jednu dvojicu vysvetľuje mnohé tiché zlyhania.
Obe strany zdieľajú tajomstvo a to nie je používateľský údaj. Podpisuje výmenu a každá odpoveď sa overuje proti nemu. Nastavte tajomstvo na oboch stranách odlišne a server neodpovie zlé tajomstvo — požiadavku zahodí alebo odpoveď neprejde overením, takže brána hlási vypršanie času. Zlé tajomstvo a mŕtvy server vyzerajú z brány rovnako, preto skok testujem klientskym nástrojom, než obviním adresár.
Protokol je malý a starý — RFC 2865 definuje autentizačnú výmenu — ale atribúty, ktoré nesie, sú základom, na ktorom je postavená väčšina VPN politiky.
# 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'Server RADIUS môže byť len prednou časťou poskytovateľa identity
Ľudia hovoria o RADIUS a poskytovateľovi identity, akoby to bola tá istá krabica. Často nie sú. Server RADIUS prijme Access-Request a potom sa pred odpoveďou opýta niečoho iného — Active Directory cez LDAP alebo Kerberos, lokálny súbor používateľov alebo externú službu. FreeRADIUS s modulom LDAP alebo krb5, Windows NPS a Cisco ISE stoja všetky na tejto pozícii.
Rozdiel rozhoduje o tom, kam sa pozerať. Odmietnuté heslo je odpoveď poskytovateľa identity preposlaná RADIUSom. Vypršanie času je zvyčajne úsek RADIUS–adresár: vypršaný účet na zviazanie, nedostupný adresár alebo požiadavka smerovaná na nesprávny backend. Ak používateľské meno nesie doménovú príponu, server podľa nej môže smerovať, a ten istý účet odoslaný ako CORP\alice a [email protected] môže skončiť na rôznych miestach. Vo Windows NPS zapisuje protokol Security 6272 pri povolení a 6273 pri odmietnutí, čo vám povie, či rozhodnutie vôbec prišlo z NPS.
Čítajte zlyhanie pri skoku, ktorý ho spôsobil
Jedna správa o nemožnosti pripojiť sa pokrýva štyri rôzne zlyhania. Skôr než čokoľvek zmeníte, priraďte príznak k skoku, ktorý ho spôsobil.
| 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 |
Posledný riadok je ten, ktorý posiela ľudí k nesprávnemu tímu. Access-Accept znamená, že prihlasovacie údaje boli prijaté; neznamená, že brána umiestnila používateľa do správneho poolu alebo pretlačila trasy. Atribúty skupiny záležia len vtedy, keď ich politika brány číta. Videl som správne prihlásenie skončiť v hosťovskom poole, pretože mapovanie skupín bolo na strane RADIUSu nastavené pre iný atribút, než aký brána kontroluje.
Sledujte jedno prihlásenie od začiatku do konca
Vyberte jeden testovací účet a jednu bránu a potom sledujte ten istý pokus vo všetkých štyroch bodoch. Spustite ladenie na strane RADIUSu — freeradius -X vypíše požiadavku a každý modul, ktorého sa dotkne — sledujte autentizačný log brány a spustite tcpdump pre UDP výmenu. Pripojte sa raz a prečítajte štyri stopy v poradí.
Chcete vidieť súhlas: brána sa pýtala na používateľa, ktorého ste očakávali, server RADIUS zvolil backend, ktorý ste očakávali, ten backend vrátil rozhodnutie a atribúty v odpovedi zodpovedajú politike, ktorú brána uplatňuje. Prvé miesto, kde sa stopy rozchádzajú, je vaša línia poruchy. Ak odpoveď nenesie atribút skupiny, problém je na strane RADIUSu, nie v profile VPN; ak atribút existuje a brána ho ignoruje, problémom je politika brány.
Jedna bezpečnostná poznámka, kým ste tam. Zdieľané tajomstvo chráni výmenu, ale nešifruje väčšinu atribútov. Ak brána a server RADIUS ležia v rôznych segmentoch, dajte tento skok na RADIUS cez TLS alebo súkromnú cestu. Šifrovaný používateľský tunel nič nehovorí o prepojení na backend.
Skôr než zatvoríte tiket, potvrďte štyri veci. Brána dosiahne server RADIUS na porte, pre ktorý je skutočne nakonfigurovaná. Zdieľané tajomstvo na oboch stranách súhlasí. Server RADIUS vyrieši presný tvar používateľského mena, ktorý brána posiela. Prijatie nesie atribúty, ktoré politika brány potrebuje. Keď platia všetky štyri, prihlásenie, ktoré stále zlyháva, je problém politiky brány, nie autentizácie.