Cómo un inicio de sesión VPN llega a RADIUS y a su proveedor de identidad
Recorra un inicio de sesión VPN desde el cliente hasta la solicitud RADIUS de la puerta de enlace, el proveedor de identidad que hay detrás y la política aplicada tras la aceptación.
La semana pasada un usuario pudo iniciar sesión en la VPN y aun así acabó en una red donde no se resolvía nada. El cliente decía conectado, el registro de la puerta de enlace decía Access-Accept y el equipo de identidad decía que la cuenta estaba bien. El inicio de sesión había funcionado; la autorización que había detrás, no. Cuando falla un inicio de sesión VPN, recorro el camino que realmente sigue la solicitud — cliente, puerta de enlace, servidor RADIUS, proveedor de identidad — y me detengo en el primer salto cuya respuesta no concuerda con la siguiente.
El cliente nunca habla RADIUS
Diga lo que diga la aplicación del portátil, su primer salto es el protocolo VPN: IKEv2, OpenVPN, WireGuard o un cliente basado en TLS. RADIUS no aparece en ese intercambio. El cliente se autentica ante la puerta de enlace con un certificado, un nombre de usuario y una contraseña, o un método EAP transportado dentro de la configuración del túnel.
Eso importa cuando se leen registros, porque el error genérico de autenticación que ve el usuario lo produce la puerta de enlace después de haber hablado ya con otra cosa. Si el cliente nunca llega a la puerta de enlace, no existe ninguna solicitud RADIUS que depurar y una hora dedicada al servidor RADIUS es tiempo perdido. Confirme que el túnel se levantó antes de tocar el backend.
La puerta de enlace es el cliente RADIUS
En cuanto la configuración del túnel llega al punto en que hay que comprobar las credenciales, la puerta de enlace se convierte en un servidor de acceso a la red. Construye una Access-Request: User-Name, una contraseña o carga EAP, NAS-IP-Address o NAS-Identifier, y un Message-Authenticator cuando el método lo exige. La solicitud va a UDP 1812 por defecto, y la contabilidad a 1813. Las instalaciones más antiguas siguen usando 1645 y 1646, así que una regla de cortafuegos escrita para un par explica muchas fallas silenciosas.
Ambos lados comparten un secreto, y no es una credencial de usuario. Firma el intercambio y cada respuesta se verifica contra él. Configure el secreto de forma distinta en los dos lados y el servidor no responde con un secreto incorrecto: descarta la solicitud o la respuesta no supera la verificación, de modo que la puerta de enlace informa un tiempo de espera. Un secreto incorrecto y un servidor muerto parecen idénticos desde la puerta de enlace, por eso pruebo el salto con una herramienta de cliente antes de culpar al directorio.
El protocolo es pequeño y antiguo — RFC 2865 define el intercambio de autenticación —, pero los atributos que transporta son la base sobre la que se construye la mayor parte 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 puede ser solo la fachada del proveedor de identidad
La gente habla de RADIUS y del proveedor de identidad como si fueran la misma caja. A menudo no lo son. El servidor RADIUS recibe la Access-Request y luego pregunta a otra cosa — Active Directory por LDAP o Kerberos, un archivo de usuarios local o un servicio externo — antes de responder. FreeRADIUS con el módulo LDAP o krb5, Windows NPS y Cisco ISE ocupan todos esta posición.
La distinción decide dónde mirar. Una contraseña rechazada es una respuesta del proveedor de identidad retransmitida por RADIUS. Un tiempo de espera suele ser el tramo RADIUS-directorio: una cuenta de enlace caducada, un directorio inalcanzable o una solicitud encaminada al backend equivocado. Si el nombre de usuario lleva un sufijo de dominio, el servidor puede enrutar por él, y la misma cuenta enviada como CORP\alice y [email protected] puede acabar en lugares distintos. En Windows NPS, el registro Security anota 6272 para una concesión y 6273 para una denegación, lo que dice si la decisión vino de NPS.
Lea el fallo en el salto que lo produjo
Un solo mensaje de no se puede conectar cubre cuatro fallos distintos. Antes de cambiar nada, empareje el síntoma con el salto que lo produjo.
| 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 |
La última fila es la que envía a la gente al equipo equivocado. Access-Accept significa que las credenciales se aceptaron; no significa que la puerta de enlace haya colocado al usuario en el grupo correcto ni haya empujado rutas. Los atributos de grupo solo importan si la política de la puerta de enlace los lee. He visto un inicio de sesión correcto caer en un grupo de invitados porque el mapeo de grupos estaba configurado en el lado RADIUS para un atributo distinto del que inspecciona la puerta de enlace.
Siga un inicio de sesión de principio a fin
Elija una sola cuenta de prueba y una puerta de enlace, y observe el mismo intento en los cuatro puntos. Inicie una ejecución de depuración en el lado RADIUS — freeradius -X imprime la solicitud y cada módulo que toca —, siga el registro de autenticación de la puerta de enlace y ejecute tcpdump para el intercambio UDP. Conéctese una vez y lea las cuatro trazas en orden.
Lo que quiere ver es acuerdo: la puerta de enlace preguntó por el usuario que esperaba, el servidor RADIUS eligió el backend que esperaba, ese backend devolvió una decisión y los atributos de la respuesta coinciden con la política que aplica la puerta de enlace. El primer lugar donde las trazas no coinciden es su línea de fallo. Si la respuesta no lleva atributo de grupo, el problema está en el lado RADIUS, no en el perfil VPN; si el atributo está y la puerta de enlace lo ignora, el problema es la política de la puerta de enlace.
Una nota de seguridad mientras está ahí. El secreto compartido protege el intercambio, pero no cifra la mayoría de los atributos. Si la puerta de enlace y el servidor RADIUS están en segmentos distintos, ponga ese salto en RADIUS sobre TLS o en una ruta privada. Un túnel de usuario cifrado no dice nada sobre el enlace del backend.
Antes de cerrar el tique, confirme cuatro cosas. La puerta de enlace puede alcanzar el servidor RADIUS en el puerto para el que está realmente configurada. El secreto compartido coincide en ambos lados. El servidor RADIUS resuelve la forma exacta del nombre de usuario que envía la puerta de enlace. La aceptación lleva los atributos que necesita la política de la puerta de enlace. Cuando se cumplen las cuatro, un inicio de sesión que sigue fallando es un problema de política de la puerta de enlace, no de autenticación.