Cuestión 1 — SSID, VLAN y seguridad por perfil

Principio de diseño. Un SSID por perfil de uso, cada uno mapeado a una VLAN 802.1Q distinta que la WLC aplica en el punto de aplicación (anclaje del túnel CAPWAP). Se evita multiplicar SSID innecesariamente (cada SSID adicional consume airtime por las tramas de gestión/beacons), pero aquí los cuatro perfiles tienen requisitos de seguridad y enrutamiento incompatibles, por lo que justifican SSID separados. Todos los SSID se difunden (broadcast): ocultar el SSID no aporta seguridad real (se descubre con sniffing pasivo de probe requests/responses) y degrada el roaming y la conexión de algunos clientes.

Plan de SSID, banda y VLAN (subredes del bloque 10.40.0.0/16):

La VLAN de docentes y alumnado se dimensiona con /22 (≈1.000 hosts) por la densidad de dispositivos; invitados y eduroam con /24. El gateway de cada VLAN reside en el L3 del núcleo, y la salida pasa por el cortafuegos perimetral con NAT.

Por qué 802.1X/RADIUS y no una PSK común en Docentes y Alumnado:

1. Identidad individual y trazabilidad. Con 802.1X cada usuario se autentica con sus credenciales del LDAP de Conselleria; los registros RADIUS (Access-Accept con User-Name) permiten saber quién se conectó. Una PSK es anónima.
2. Revocación selectiva. Si un docente cesa o un alumno pierde el portátil, se deshabilita su cuenta en el LDAP sin afectar a nadie más. Con PSK común, dar de baja a uno obliga a rotar la clave de todos y reconfigurar cientos de dispositivos.
3. Claves de cifrado por sesión. En WPA-Enterprise, el material de clave (PMK/PTK) se deriva por usuario y sesión a partir del intercambio EAP; un atacante no puede descifrar el tráfico de otro aunque capture el 4-way handshake. Con WPA-Personal todos comparten la misma PMK y, conociendo la PSK, se descifra el tráfico ajeno.
4. Asignación dinámica de políticas. RADIUS puede devolver atributos (VLAN, ACL) por usuario o grupo, imposible con una PSK estática.

WPA3-Enterprise añade SAE/PMF (Protected Management Frames obligatorio) y suite criptográfica reforzada; se publica en modo transición para no dejar fuera dispositivos solo-WPA2.

Cuestión 2 — Flujo 802.1X / EAP con RADIUS

Roles:

• Suplicante: software 802.1X del portátil del docente (gestor Wi-Fi del SO).
• Autenticador: el AP, que tunela vía CAPWAP a la WLC; la WLC es quien actúa como cliente RADIUS (NAS) frente a FreeRADIUS. Hasta que la autenticación no termina, el puerto lógico está «cerrado» salvo para tramas EAPoL.
• Servidor de autenticación: FreeRADIUS sobre Lliurex, integrado con el LDAP de Conselleria.

Flujo paso a paso (EAP encapsulado):

1. Asociación 802.11 al SSID corporativo (Open System, sin clave aún).
2. Autenticador → Suplicante: EAP-Request/Identity.
3. Suplicante → Autenticador: EAP-Response/Identity (anonymous@iesmarjal en el outer).
4. WLC (NAS) → FreeRADIUS: RADIUS Access-Request (EAP-Message) [UDP/1812].
   - Aire:  EAPoL (802.1X)
   - Cable: EAP dentro de RADIUS
5. FreeRADIUS ↔ Suplicante: negociación EAP (p.ej. PEAP):
   a) Se establece un túnel TLS: el servidor presenta su certificado;
      el suplicante valida la CA → se crea canal cifrado.
   b) Dentro del túnel, fase 2: MSCHAPv2 (usuario/contraseña) contra LDAP.
6. FreeRADIUS valida en LDAP:
   - OK  → RADIUS Access-Accept (+ Tunnel-Type=VLAN, Tunnel-Private-Group-Id=40)
   - KO  → RADIUS Access-Reject
7. La WLC abre el puerto, ubica al cliente en la VLAN 40 y se ejecuta
   el 4-way handshake WPA (PMK derivada del EAP) → tráfico cifrado.

EAP recomendado — justificación:

• EAP-TLS (certificado de cliente y de servidor): máxima seguridad, sin contraseñas en el aire (resistente a phishing/robo de credenciales). Requiere PKI que emita y distribuya certificados a cada dispositivo y su gestión de ciclo de vida (renovación, revocación).
• PEAP-MSCHAPv2 (solo certificado de servidor; cliente con usuario/contraseña): no necesita PKI de cliente, reutiliza directamente las credenciales LDAP existentes; despliegue inmediato para cientos de alumnos.

Recomendación: PEAP-MSCHAPv2 para alumnado (no es viable emitir y mantener un certificado por alumno; ya tienen credenciales LDAP) y EAP-TLS para profesorado (colectivo estable, gestionable con PKI, y aporta autenticación fuerte para el acceso a recursos internos sensibles). En ambos casos es imprescindible validar el certificado del servidor en el cliente (ver Cuestión 4).

eduroam — jerarquía de proxies. Un visitante se identifica con usuario@su-universidad.es. FreeRADIUS local lee el realm (la parte tras la @):

RADIUS local IES  →  FLR (servidor nacional, RedIRIS/eduroam.es)
                  →  TLR (servidor europeo/confederación eduroam)
                  →  RADIUS de origen de su-universidad.es

Como el túnel EAP es extremo a extremo entre el suplicante y el RADIUS de origen, las credenciales nunca se revelan a los servidores intermedios; estos solo reenvían (proxy) el Access-Request según el realm y devuelven el Access-Accept/Reject. El IES (Service Provider) aplica la VLAN de eduroam al usuario aceptado.

Cuestión 3 — Segmentación de invitados y portal cautivo

(a) Aislamiento del tráfico de invitados.

• VLAN dedicada (VLAN 60, 10.40.60.0/24), separada lógicamente del resto en todo el camino (SSID → CAPWAP → trunk 802.1Q → cortafuegos).
• Reglas de cortafuegos (orden y sentido):

# Invitados (10.40.60.0/24)
PERMITIR  10.40.60.0/24 -> servidor portal/DNS interno  (solo DNS+HTTP redirección)
PERMITIR  10.40.60.0/24 -> INTERNET  (tras aceptar el portal)
DENEGAR   10.40.60.0/24 -> 10.40.0.0/16  (todas las VLAN internas: docentes, alumnado, gestión)
DENEGAR   10.40.60.0/24 -> 10.40.60.0/24  (refuerzo a nivel L3; ver client isolation)

Debe alcanzar: el portal cautivo (para autenticarse), un resolutor DNS e Internet. No debe alcanzar: ITACA, NAS, impresoras, WLC de gestión, ni VLAN de docentes/alumnado.

(b) El portal cautivo no cifra. El portal cautivo es un mecanismo de autorización: intercepta el primer HTTP/HTTPS y redirige a una página de aceptación/login. La asociación Wi-Fi subyacente puede ser abierta (sin clave), de modo que el tráfico viaja en claro por el aire; cualquiera con la radio en modo monitor lo captura. Para proteger la confidencialidad se añade OWE (Opportunistic Wireless Encryption, WPA3-Open / Enhanced Open), que cifra el enlace sin contraseña mediante un Diffie-Hellman por sesión, combinado con HTTPS extremo a extremo en la página del portal.

(c) Client isolation (aislamiento entre clientes). Impide que dos dispositivos de la misma VLAN de invitados se comuniquen entre sí a nivel L2 (el AP/WLC descarta el tráfico estación-a-estación). Sirve para que un invitado no pueda escanear, atacar ni infectar los dispositivos de otros invitados (que son equipos no gestionados y de confianza nula entre sí); todo el tráfico se fuerza hacia el gateway/Internet. Reduce la superficie de ataque lateral en una red abierta a terceros.

Cuestión 4 — Diagnóstico de un fallo de autenticación

Síntoma y log:

Login incorrect (TLS Alert read:fatal:unknown CA): [estudiante@iesmarjal]
... reason: client rejected our server certificate

Causa más probable. Al migrar el certificado del servidor RADIUS, este se ha firmado con una CA distinta (o se sirve sin la cadena intermedia completa), y los dispositivos del alumnado tienen su perfil PEAP configurado para confiar solo en la CA antigua (o para validar el nombre/CA del servidor). En la fase 1 de PEAP el cliente valida el certificado del servidor; al no reconocer la nueva CA, el suplicante envía la alerta TLS unknown CA y aborta antes siquiera de enviar la contraseña → «no se puede unir a la red».

Por qué a unos sí y a otros no.

• Alumnado (PEAP-MSCHAPv2): la seguridad depende de que el cliente valide el certificado de servidor. Cambiada la CA, esa validación falla y rechaza la conexión. (Correcto que falle: justo así PEAP evita servidores RADIUS falsos.)
• Profesorado (EAP-TLS): la autenticación es mutua por certificados. Si el certificado de cliente y la cadena del servidor son coherentes con la(s) CA que el perfil del profesorado ya confía —o se renovaron juntos con la nueva PKI—, la validación del servidor pasa y entran sin problema. Su perfil no está anclado a la CA antigua del mismo modo, o ya se actualizó.

Dos actuaciones para resolverlo:

1. En el servidor (FreeRADIUS). Asegurar que el certificado de servidor entrega la cadena completa (certificado de servidor + CA intermedia + raíz) y que está correctamente referenciado en mods-available/eap (tls-config):

private_key_file = /etc/freeradius/3.0/certs/server.key
certificate_file = /etc/freeradius/3.0/certs/server.pem   # incluye cadena
ca_file          = /etc/freeradius/3.0/certs/ca-chain.pem

y reiniciar: systemctl restart freeradius (probar antes con freeradius -X para ver el handshake TLS).

2. En los dispositivos/perfil de los clientes (alumnado). Distribuir la nueva CA y/o actualizar el perfil 802.1X para que confíe en ella (despliegue del nuevo certificado raíz/intermedio y, si procede, indicar el nombre del servidor RADIUS a validar). Es recomendable hacerlo mediante perfil aprovisionado (MDM, config profile, o eduroam CAT/geteduroam) para que la validación de servidor quede correctamente anclada y no se «acepte cualquier certificado».

Nota de seguridad: no se debe «resolver» desactivando la validación del certificado de servidor en los clientes; eso reabre la puerta a ataques de evil twin RADIUS y robo de credenciales MSCHAPv2.

Cuestión 5 — Radio y cobertura

(a) Por qué 5/6 GHz como banda principal y 2,4 GHz de respaldo.

• En 2,4 GHz solo hay tres canales no solapados (1, 6 y 11, de 20 MHz) en el espectro útil; con 18 AP en tres plantas es imposible evitar la interferencia cocanal y el solapamiento, y además compite con Bluetooth, microondas y vecinos.
• En 5 GHz hay del orden de 20-25 canales de 20 MHz no solapados (incluida la banda DFS), y en 6 GHz (Wi-Fi 6E) hasta 59 canales de 20 MHz adicionales. Esto permite asignar canales distintos a APs cercanos, usar anchos de canal mayores (40/80 MHz) y obtener más capacidad con menos interferencia. Por eso la red principal se publica en 5/6 GHz y 2,4 GHz queda como respaldo de cobertura/compatibilidad para clientes antiguos o IoT.

(b) Problema de fijar toda la potencia al máximo y papel de RRM. Subir todos los AP a potencia máxima provoca solapamiento e interferencia cocanal excesivos: las celdas se invaden, aumenta el ruido y las retransmisiones, los clientes oyen varios AP fuertes y se produce el efecto sticky client (se quedan «pegados» a un AP lejano). Además es asimétrico: el AP «grita» pero el cliente (móvil, poca potencia) no llega de vuelta. El RRM (Radio Resource Management) de la WLC lo corrige automáticamente y de forma global:

• TPC (Transmit Power Control): baja la potencia de cada AP para que las celdas se solapen lo justo (cell breathing), reduciendo cocanal.
• DCA (Dynamic Channel Assignment): reparte canales no solapados entre APs vecinos y evita las fuentes de interferencia detectadas.
• Coverage Hole Detection: sube potencia donde detecta zonas sin señal.

(c) Roaming y por qué lo gestiona la WLC. Roaming es el traspaso de la asociación de un cliente de un AP a otro sin perder la conexión cuando se desplaza. Interesa que lo gestione la WLC centralizada porque:

• Mantiene el contexto del cliente (PMK, VLAN, IP) y permite fast roaming (802.11r PMK caching, 802.11k vecindario y 802.11v sugerencia de AP), evitando re-autenticar 802.1X completo en cada salto (que cortaría VoIP/videollamada).
• Conserva la misma VLAN/IP al cambiar de AP (el túnel CAPWAP ancla el tráfico en la WLC), de modo que un docente que pasa de un aula a otra con su portátil no pierde sesiones (Aules, videoconferencia, NAS) ni cambia de subred.
• Toma decisiones de traspaso con visión global de la radio (carga y calidad de señal de todos los AP), cosa imposible con APs autónomos descoordinados.