Com un inici de sessió VPN arriba a RADIUS i al vostre proveïdor d'identitat
Recorreu un inici de sessió VPN des del client fins a la sol·licitud RADIUS de la passarel·la, el proveïdor d'identitat que hi ha darrere i la política aplicada després de l'acceptació.
La setmana passada un usuari va poder iniciar sessió a la VPN i tot i així va acabar en una xarxa on no es resolia res. El client deia connectat, el registre de la passarel·la deia Access-Accept i l'equip d'identitat deia que el compte estava bé. L'inici de sessió havia funcionat; l'autorització que hi ha darrere, no. Quan falla un inici de sessió VPN, recorro el camí que la sol·licitud realment segueix — client, passarel·la, servidor RADIUS, proveïdor d'identitat — i m'aturo al primer salt la resposta del qual no concorda amb la següent.
El client mai no parla RADIUS
Tant se val el que mostri l'aplicació de l'ordinador portàtil: el seu primer salt és el protocol VPN: IKEv2, OpenVPN, WireGuard o un client basat en TLS. RADIUS no apareix en aquest intercanvi. El client s'autentica a la passarel·la amb un certificat, un nom d'usuari i una contrasenya, o un mètode EAP transportat dins de la configuració del túnel.
Això importa quan llegiu registres, perquè l'error genèric d'autenticació que veu l'usuari el produeix la passarel·la després d'haver parlat ja amb una altra cosa. Si el client no arriba mai a la passarel·la, no hi ha cap sol·licitud RADIUS per depurar i una hora dedicada al servidor RADIUS és temps perdut. Confirmeu que el túnel s'ha aixecat abans de tocar el backend.
La passarel·la és el client RADIUS
Quan la configuració del túnel arriba al punt en què cal verificar les credencials, la passarel·la es converteix en un servidor d'accés a la xarxa. Construeix una Access-Request: User-Name, una contrasenya o càrrega EAP, NAS-IP-Address o NAS-Identifier, i un Message-Authenticator quan el mètode ho requereix. La sol·licitud va a UDP 1812 per defecte, i la comptabilitat a 1813. Les instal·lacions més antigues encara fan servir 1645 i 1646, així que una regla de tallafoc escrita per a una parella explica moltes fallades silencioses.
Totes dues bandes comparteixen un secret, i no és una credencial d'usuari. Signa l'intercanvi i cada resposta es verifica contra ell. Configureu el secret de manera diferent a les dues bandes i el servidor no respon amb un secret incorrecte: descarta la sol·licitud o la resposta no supera la verificació, de manera que la passarel·la informa d'un temps d'espera. Un secret incorrecte i un servidor mort semblen idèntics des de la passarel·la, per això provo el salt amb una eina de client abans de culpar el directori.
El protocol és petit i antic — RFC 2865 defineix l'intercanvi d'autenticació — però els atributs que transporta són la base sobre la qual es construeix la major part de la política VPN.
# 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'El servidor RADIUS potser només fa de frontal del proveïdor d'identitat
La gent parla de RADIUS i del proveïdor d'identitat com si fossin la mateixa caixa. Sovint no ho són. El servidor RADIUS rep l'Access-Request i després pregunta a una altra cosa — Active Directory per LDAP o Kerberos, un fitxer d'usuaris local o un servei extern — abans de respondre. FreeRADIUS amb el mòdul LDAP o krb5, Windows NPS i Cisco ISE se situen tots en aquesta posició.
La distinció decideix on cal mirar. Una contrasenya rebutjada és una resposta del proveïdor d'identitat transmesa per RADIUS. Un temps d'espera sol ser el tram RADIUS-directori: un compte de bind caducat, un directori inabastable o una sol·licitud encaminada al backend equivocat. Si el nom d'usuari porta un sufix de domini, el servidor pot encaminar-hi, i el mateix compte enviat com a CORP\alice i [email protected] pot acabar en llocs diferents. A Windows NPS, el registre Security anota 6272 per a una concessió i 6273 per a una denegació, cosa que us diu si la decisió ha vingut de NPS.
Llegiu la fallada al salt que l'ha produïda
Un sol missatge de no es pot connectar cobreix quatre fallades diferents. Abans de canviar res, feu coincidir el símptoma amb el salt que l'ha produït.
| 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 |
L'última fila és la que envia la gent a l'equip equivocat. Access-Accept vol dir que les credencials s'han acceptat; no vol dir que la passarel·la hagi col·locat l'usuari al grup correcte o hagi empès rutes. Els atributs de grup només importen si la política de la passarel·la els llegeix. He vist un inici de sessió correcte caure en un grup de convidats perquè el mapatge de grups estava configurat al costat RADIUS per a un atribut diferent del que inspecciona la passarel·la.
Seguiu un inici de sessió de principi a fi
Trieu un sol compte de prova i una passarel·la, i observeu el mateix intent als quatre punts. Inicieu una execució de depuració al costat RADIUS — freeradius -X imprimeix la sol·licitud i cada mòdul que toca — seguiu el registre d'autenticació de la passarel·la i executeu tcpdump per a l'intercanvi UDP. Connecteu-vos un cop i llegiu les quatre traces en ordre.
El que voleu veure és acord: la passarel·la ha preguntat per l'usuari que esperàveu, el servidor RADIUS ha triat el backend que esperàveu, aquell backend ha retornat una decisió i els atributs de la resposta coincideixen amb la política que aplica la passarel·la. El primer lloc on les traces no coincideixen és la vostra línia de fallada. Si la resposta no porta cap atribut de grup, el problema és al costat RADIUS, no al perfil VPN; si l'atribut hi és i la passarel·la l'ignora, el problema és la política de la passarel·la.
Una nota de seguretat mentre hi sou. El secret compartit protegeix l'intercanvi, però no xifra la majoria d'atributs. Si la passarel·la i el servidor RADIUS són en segments diferents, poseu aquell salt a RADIUS sobre TLS o en un camí privat. Un túnel d'usuari xifrat no diu res sobre l'enllaç del backend.
Abans de tancar el tiquet, confirmeu quatre coses. La passarel·la pot arribar al servidor RADIUS al port pel qual està realment configurada. El secret compartit coincideix a les dues bandes. El servidor RADIUS resol la forma exacta del nom d'usuari que envia la passarel·la. L'acceptació porta els atributs que necessita la política de la passarel·la. Quan es compleixen les quatre, un inici de sessió que encara falla és un problema de política de la passarel·la, no d'autenticació.