Acceso federado y VPN

En el acceso federado entre instituciones, como el del servicio eduroam descrito en el RFC 7593, el visitante usa 802.1X, EAP y RADIUS. La solicitud viaja por una jerarquía de servidores proxy, según el dominio de la identidad, hasta la institución de origen, que es quien verifica la credencial. La institución anfitriona no conoce la clave: solo recibe un «aceptado» o «rechazado» y decide qué red darle.

Por eso el campus anfitrión tiene dos trabajos: confiar en la respuesta de la federación y asignar a esos visitantes una red limitada, igual para todos.

Todo visitante federado debe caer en la VLAN de visitantes federados. La tabla vlans dice qué es cada número; autenticaciones_federadas dice dónde cayó cada sesión. Una sesión federada fuera de su VLAN indica un error de política de asignación.

Cada población tiene su perfil de VPN, con un segundo factor, un tipo de túnel y destinos permitidos. Un perfil sin segundo factor depende de una sola contraseña, y si da acceso a recursos de cómputo, la brecha es mayor que su tamaño aparente.

Consulta perfiles_vpn.

Las sesiones de VPN dejan hora y duración. La suma por usuario permite ver patrones (horarios inusuales, sesiones muy largas) antes de pensar en causas. Un patrón por sí solo no prueba nada: pide contexto.

Suma las sesiones del usuario inv-0077 que aparecen en sesiones_vpn.

En el acceso federado, la identidad externa (la que viaja sin cifrar al inicio) puede ser anónima: el nombre real solo va dentro del túnel EAP que termina en la institución de origen. Así el campus anfitrión no ve quién es la persona. Cuando un visitante muestra su identidad real en el campo externo, el anfitrión la guarda en sus registros.