EAP y RADIUS, el intercambio paso a paso

La conversación usa dos protocolos encadenados. Entre el equipo y el conmutador viaja EAP sobre LAN (EAPOL), que es EAP metido en tramas de la red local. Entre el conmutador y el servidor viaja RADIUS, y dentro de sus mensajes va el EAP envuelto. EAP (protocolo de autenticación extensible) no es un método, sino un marco: cada método decide qué se prueba, por ejemplo un certificado de equipo o una contraseña dentro de un túnel cifrado.

RADIUS tiene cuatro mensajes que verás en cualquier registro. El conmutador envía Access-Request. El servidor responde Access-Challenge (necesita más pasos), Access-Accept (entra) o Access-Reject (no entra). El servidor escucha en el puerto UDP 1812 según su especificación, el RFC 2865.

Lee intercambio.

En el tercer paso el equipo responde a la pregunta «¿quién eres?». La identidad que declara en ese momento es solo una afirmación: no prueba nada hasta que el servidor valida la prueba posterior. Aun así es la que queda en el registro, y es la que se usa para buscar el rastro de un equipo después.

Cuando el servidor acepta, el Access-Accept puede llevar atributos que le dicen al conmutador qué hacer con el puerto. Para asignar una VLAN se usan tres atributos estándar (RFC 3580): Tunnel-Type con valor 13 (VLAN), Tunnel-Medium-Type con valor 802 y Tunnel-Private-Group-ID con el número de la VLAN. El puerto no tiene la VLAN escrita: la recibe de la respuesta, según quién se autenticó.

Cada conmutador y el servidor comparten un secreto: con él se autentican entre sí los mensajes RADIUS y se protegen partes de su contenido. Si una misma clave está repetida en todos los conmutadores, quien la obtenga de uno puede hablarle al servidor como cualquiera de ellos. La buena práctica es un secreto por equipo, largo, guardado en una bóveda y rotado.

Consulta clientes_radius. El valor real nunca se muestra: los marcadores CLAVE-FICTICIA-NNNN identifican la clave, y dos filas con el mismo marcador comparten el mismo secreto.

Todos los puertos protegidos dependen del servidor. Por eso se configura un servidor de respaldo: si el principal no contesta, el conmutador consulta al segundo. Un autenticador sin respaldo convierte la caída de un solo servidor en el bloqueo de todos sus puertos, o, según cómo esté configurado el fallo, en una red abierta mientras dura. Ninguna de las dos situaciones es aceptable en una planta que trabaja por turnos.