Quien en redes corporativas quiera controlar de forma seria qué endpoints pueden operar en qué puertos y SSIDs (identificadores de red WLAN), difícilmente puede prescindir de 1X Network Access Control. En la práctica se suele referir casi siempre a IEEE 802.1X: control de acceso basado en puertos, en el que un switch o un punto de acceso (el Authenticator) retransmite las credenciales de un cliente (el Supplicant) a un servidor RADIUS (backend AAA para Authentication, Authorization, Accounting). El resultado no es solo “dentro o fuera”, sino que puede desencadenar asignaciones como VLAN, ACL o cuarentena.
El inconveniente: 802.1X es menos una funcionalidad que un modelo operativo. Fallos raramente se deben a una casilla sin marcar en el switch, sino a certificados, identidades no uniformes, dispositivos especiales (impresoras, IoT), timers incorrectos, políticas poco claras y un despliegue sin ruta de retroceso. Este artículo le guía de forma práctica por la configuración de RADIUS, el diseño de políticas NAC y un plan de despliegue que funciona de forma realista en redes heterogéneas (LAN/WLAN, Windows/macOS/Linux, gestionadas/no gestionadas).
Por qué 802.1X/NAC: lo que gana operativamente (y lo que no)
802.1X aborda un problema central de las redes clásicas de Capa 2: un puerto activo suele considerarse “confiable” mientras exista enlace. Eso ya no encaja con BYOD, puestos de trabajo cambiantes, el regreso al teletrabajo, redes de invitados y la necesidad de separar segmentos de forma rigurosa. Con 802.1X hace que un dispositivo demuestre una identidad antes de obtener acceso a la red.
Importante para gestionar expectativas: 802.1X no es una seguridad de endpoints completa. No reemplaza la gestión de parches ni EDR. Tampoco es una panacea contra dispositivos comprometidos. Pero establece una base técnica sólida para estandarizar accesos: “¿Quién eres, a qué tipo perteneces y qué perfil se te aplica?” Precisamente esa asignación suele ser en operación y auditoría la palanca decisiva.
Fundamentos de la arquitectura: roles y protocolos sin ambigüedades
En 802.1X intervienen tres roles:
- Supplicant: Cliente en el endpoint (p. ej. Windows Wired AutoConfig, macOS 802.1X, wpa_supplicant en Linux).
- Authenticator: Puerto de switch o punto de acceso WLAN, que inicialmente bloquea el puerto y procesa EAPOL (EAP over LAN) o EAP over WLAN.
- Authentication Server: Servidor RADIUS que termina o procesa EAP (Extensible Authentication Protocol) y devuelve decisiones.
Métodos EAP importantes en el día a día del NAC:
- EAP-TLS: autenticación basada en certificados (certificado de cliente). Muy robusto, pero intensivo en PKI y en la gestión del ciclo de vida.
- PEAP: túnel (TLS) más un método de contraseña interno (típicamente MSCHAPv2). Más fácil de desplegar, pero más vulnerable a ataques contra contraseñas y phishing; además depende de una correcta confianza en el certificado del servidor.
Para los administradores es importante: en el enlace no circula una «contraseña RADIUS», sino que EAP se transporta entre el Supplicant y el RADIUS a través del Authenticator. Si algo falla, debe averiguarse siempre: ¿falla en el cliente (Supplicant), en el Authenticator (Switch/AP) o en el RADIUS/servicio de directorio (p. ej. AD/LDAP) y su cadena de certificados?
Requisitos antes del primer paquete: inventario, identidades, PKI
Un inicio ordenado le ahorra semanas de resolución de problemas. Aclare de antemano estos puntos:
1) Inventariar tipos de dispositivos y casos especiales
Enumere puertos/redes y clases de endpoints: clientes gestionados, portátiles de administración, teléfonos VoIP, impresoras, sistemas de conferencia, cámaras, equipos de producción, puntos de acceso, clientes ligeros. Lo decisivo es: ¿quién puede 802.1X como Supplicant? ¿Quién necesita MAB? ¿Qué dispositivos tienen MACs cambiantes (randomization) y por tanto son inadecuados para MAB?
2) Determinar la fuente de identidades: usuarios, dispositivos o ambos
Para LAN la elección «User-Auth» vs. «Machine-Auth» es central. En Windows-entornos el Computer-Zertifikat (EAP-TLS) para «el dispositivo pertenece al dominio» suele ser más estable que usuario/contraseña, porque el inicio de sesión puede ocurrir antes del logon del usuario. Para WLAN a menudo necesita ambos (p. ej. WLAN de empleados mediante certificado de usuario, dispositivos/WLAN mediante certificado de máquina).
3) Decisión PKI: ¿Quién emite certificados y cómo se rotan?
EAP-TLS depende totalmente de los certificados: CA (Certificate Authority), plantillas/perfiles, periodos de validez, revocación (CRL/OCSP), distribución de CAs raíz/intermedias y renovación. Trampa típica: el cliente no confía en el certificado del servidor RADIUS porque faltan certificados intermedios o se usan EKUs (Extended Key Usage) incorrectos.
Si emplea PEAP: incluso entonces necesita un Server-Zertifikat en el RADIUS, y los clientes deben verificar su trust correctamente. De lo contrario, un «túnel seguro» se convierte rápidamente en seguridad de „aceptar con un clic“.
RADIUS-Setup: Redundanz, Ports, Zertifikate, Logging
Un entorno RADIUS productivo no consiste solo en un servicio de servidor. Planifique al menos dos instancias (HA mediante loadbalancer o servidores duales en los dispositivos de red), políticas consistentes y registro limpio.
Base a nivel de red: accesibilidad y secretos compartidos
RADIUS utiliza típicamente UDP/1812 (Auth) y UDP/1813 (Accounting). En entornos antiguos aparecen UDP/1645/1646. Verifique firewalls y enrutamiento, especialmente si el access layer y los servidores AAA están en zonas separadas. Por cada Authenticator (Switch/AP/Controller) existe un Shared Secret (clave compartida) que no debe poder adivinarse y debe ser susceptible de rotación.
Una prueba mínima de conectividad (sin cliente 802.1X) suele ser útil. Un ejemplo con radclient (herramientas de FreeRADIUS) contra un usuario de prueba puede mostrar si RADIUS responde en términos generales:
# Beispiel: Access-Request an RADIUS schicken (Test-User/Passwort nur für Lab)
# radclient erwartet hier PAP/CHAP-ähnliche Attribute, nicht EAP-TLS.
echo "User-Name=testuser,User-Password=testpass" |
radclient -x 10.10.10.20 auth SuperSecretSharedKeyImportante: esto no es una prueba EAP. Es un «¿está vivo el RADIUS y es correcto el Secret?». Para EAP-TLS/PEAP necesita pruebas reales con supplicants o herramientas de prueba EAP específicas.
Zertifikate auf dem RADIUS: Kette, EKU, Name
El servidor RADIUS debe presentar un certificado de servidor que los clientes validen. Compruebe lo siguiente:
- Subject/SAN: El nombre DNS que esperan los clientes debe figurar en el certificado (SAN: Subject Alternative Name).
- EKU: „Server Authentication“ debe estar establecido.
- Zertifikatskette: Los intermedios deben entregarse correctamente; de lo contrario muchos clientes fallarán silenciosamente.
- CRL/OCSP: Si los clientes exigen comprobación de revocación, la accesibilidad de las listas de revocación debe estar garantizada (también en el Pre-Logon).
Accounting und Telemetrie: Ohne Logs kein Betrieb
El accounting de RADIUS le proporciona inicios/paros de sesión y puede ayudar en el análisis de NAC: qué puertos/SSIDs se usan y cómo, quién se desvía del perfil esperado. Incluso si no utiliza el accounting para facturación, resulta valioso para operación, resolución de incidencias y auditoría.
Planifique las fuentes de registros de modo que pueda correlacionar eventos:
- Registros RADIUS (Accept/Reject, Reason, EAP-State)
- Registros de switch/AP (Dot1x, AAA, Port-Events)
- Registros de cliente (Windows Visor de eventos, macOS consola, wpa_supplicant)
NAC-Policy designen: Weniger „alles dicht“, mehr kontrollierte Pfade
Una política NAC es la regla de operación que determina en qué perfil objetivo cae un dispositivo final. El clásico es: «Employee VLAN» o «Guest VLAN». En la práctica necesita más graduaciones para que el despliegue y la operación permanezcan estables.
Policy-Bausteine, die sich bewährt haben
- Pre-Auth / Fail-Open / Fail-Closed: comportamiento cuando RADIUS no está accesible. Fail-Open puede salvar el negocio, pero constituye un riesgo de seguridad; Fail-Closed es más seguro, pero puede dejar fuera de servicio de forma masiva ante una falla de AAA. En muchos entornos, un Fail-Open controlado con un perfil reducido (p. ej. solo acceso a remediación/gestión) es el mejor compromiso.
- Quarantäne/Remediation: VLAN o ACL que solo permita servicios de actualización/gestión, DNS, DHCP y, si procede, proxy. Objetivo: que los dispositivos sean «reparables» en lugar de bloquearlos.
- Rollen nach Gerätetyp: Managed Client, Unmanaged Device, Voice, Printer, IoT, Admin-Workstation.
- Guest/BYOD separat: SSID/puertos propios, espacios de direcciones claramente separados, privilegios reducidos.
Técnicamente, esto suele implementarse mediante atributos RADIUS (p. ej. VLAN-ID, Tunnel-Private-Group-ID, Filter-ID, dACL). Qué atributos entiende su infraestructura depende del fabricante. Lo decisivo es el principio operativo: perfiles claros y comprobables.
EAP-TLS vs. PEAP im Policy-Kontext
EAP-TLS suele ser la mejor opción para dispositivos gestionados, porque proporciona una identidad de dispositivo sólida. La desventaja es el esfuerzo de PKI: Enrollment, Erneuerung, Sperrung, Offboarding. PEAP suele ser el punto de entrada cuando necesita autenticación basada en usuario de forma rápida, pero genera más casos de soporte («aviso de certificado», cambio de contraseña, bloqueos) y es más vulnerable si los clientes no verifican estrictamente la identidad del servidor.
Un híbrido frecuente en empresas: LAN mediante EAP-TLS (Machine), WLAN de empleados mediante EAP-TLS (User o Device), dispositivos legacy/especiales mediante MAB a una VLAN RESTrictiva.
Lado de switches y WLAN: Parámetros típicos que determinan la estabilidad
Muchos proyectos 802.1X no fracasan por «¿el switch soporta 802.1X?», sino por temporizadores y prioridades. PRESTe atención a los siguientes puntos:
Roles de puerto y escenarios con múltiples dispositivos (PC + teléfono)
En el puesto de trabajo suele haber un teléfono VoIP conectado al puerto y el PC conectado al teléfono. Para eso necesita un modelo que pueda representar dos identidades en el mismo puerto. Palabras clave: „Multi-Auth“ o „Multi-Domain Authentication“ (Voice/Data separados). Si lo ignora, solo se autentica uno de los dispositivos y el otro cae en el perfil incorrecto.
Temporizadores y reintentos
Intervalos de reautenticación demasiado agresivos o timeouts cortos provocan „Flapping“: el puerto se reautentica periódicamente, las conexiones se interrumpen y Teams/VoIP se ve afectado. Intervalos demasiado largos retrasan el Offboarding. Empiece de forma conservadora y optimice después.
Definir bien los fallbacks: MAB y Guest VLAN
Si permite MAB como excepción, el switch debe priorizar claramente: primero 802.1X y luego MAB (o al revés, según la clase de dispositivo). Una „Guest VLAN“ para fallos de autenticación puede hacer el despliegue más seguro, pero es una puerta de entrada si se configura demasiado permisiva. La VLAN de invitados/fallo debería tener solo accesos mínimos.
Plan de despliegue: del laboratorio al modo Monitor y a la aplicación
Un despliegue es menos una acción técnica y más una transición controlada. Ha demostrado ser eficaz un enfoque por etapas que incluya puntos de medición y rutas de retroceso.
Fase 0: laboratorio y recorrido de referencia
Monte un pequeño recorrido de referencia: 1–2 Switches/1 AP, un RADIUS-Cluster (o dos instancias), un Windows-Client, un macOS-Client, un Linux-Client, más un dispositivo especial (p. ej., impresora). El objetivo no es la exhaustividad, sino detectar pronto los problemas críticos: cadena de certificados, nombre, accesibilidad de CRL, decisiones de política, asignación de VLAN.
Fase 1: visibilidad sin imposición (Monitor/Low Impact)
Si su plataforma lo permite: comience con el „Monitor Mode“ o con una configuración que registre las autenticaciones pero que aún no las bloquee. Alternativamente: los puertos permanecen abiertos, pero el accounting y las peticiones RADIUS corren en paralelo (según el proveedor). Eso le proporciona datos: qué dispositivos podrían soportar 802.1X y cuáles no, dónde hay una randomización de MAC inesperada, y dónde hay dispositivos detrás de switches no gestionados?
Fase 2: grupo piloto con responsabilidad clara
Elija un área con usuarios que puedan recibir soporte (TI, usuarios avanzados, una ubicación) y defina criterios de éxito:
- Inicio de sesión/desbloqueo estable
- VPN/VDI/telefonía/impresión funcionan
- No interrupciones «esporádicas» por reautenticación
- Prueba de offboarding: retirar dispositivo/certificado y comprobar el comportamiento
Fase 3: enforcement gradual por segmento
Despliegue siguiendo límites naturales: edificio/planta/switch de acceso, SSIDs separadas, luego áreas núcleo. Importante: no «todos los puertos a la vez».
Establezca una gestión explícita de excepciones: los dispositivos especiales deben ser registrados, clasificados y migrados a un perfil RESTrictivo antes del enforcement. De lo contrario, los equipos inventarán «workarounds» (mini-switch, puente WLAN) que al final son más arriesgados que la red original.
Listas de verificación prácticas: qué debe comprobar antes, durante y después del cutover
Comprobación previa al Cutover (por bloque de Switch/AP)
- Redundancia RADIUS configurada y probada (ambas instancias Accept)
- Shared Secrets documentados, con posibilidad de rotación, no reutilizados
- NTP sincronizado (la deriva de tiempo rompe TLS y la correlación de logs)
- DHCP/DNS presentes en el perfil de cuarentena y de invitados
- Accesibilidad de CRL/OCSP comprobada desde el contexto pre-logon (si procede)
- Escenario multi-dispositivo Voice/PC probado
- Acceso de emergencia: definir al menos un puerto/SSID como Break-Glass (controlado físicamente/administrativamente)
Protocolo de Cutover (apto para runbook operativo)
- Definir ventana de cambio y canal de comunicación (Ops/Red/Sec/Service Desk)
- Activar enforcement para el bloque definido
- Comprobar en vivo: nuevas sesiones se autentican, sin Port-Flaps
- Muestreos: Windows/macOS/Linux, teléfono, impresora/IoT
- Agrupar logs RADIUS por motivos de Reject (Top-3 causas primero)
Post-Cutover: estabilidad e higiene
- Eliminar excepciones: inventariar dispositivos MAB y, si procede, migrarlos
- Optimizar intervalos de reautenticación y temporizadores una vez que los datos sean estables
- Establecer reporting: autenticaciones rechazadas, nuevos OUI/MAC-Vendor, clases de dispositivos desconocidas
Resolución de problemas: los fallos más frecuentes y cómo acotarlos rápidamente
Los errores 802.1X suelen parecer iguales («sin red»), pero tienen causas muy distintas. Trabaje de forma estructurada de abajo hacia arriba: enlace/puerto, inicio EAP, solicitud RADIUS, verificación de certificados, decisión de política, aplicación de VLAN/ACL.
Caso 1: el cliente no obtiene IP (DHCP) tras un inicio de sesión exitoso
Las causas a menudo no son «802.1X roto», sino VLAN incorrecto, DHCP no en el VLAN objetivo, o falta DHCP-Relay/Helper. Compruebe en el switch: ¿en qué VLAN está el puerto después de Accept? Y: ¿se permite DHCP en absoluto (con dACL/Filter-IDs)?
Caso 2: «Certificado no confiable» o advertencias esporádicas
Típico en PEAP y también en la confianza de servidor EAP-TLS: nombre de servidor incorrecto, certificados intermedios faltantes, Root-CA obsoleta en clientes, o CRL/OCSP inaccesible. Si los usuarios pueden cerrar las advertencias, es un problema de diseño. El objetivo debe ser: validación estricta del servidor sin avisos.
Caso 3: telefonía inestable tras la implementación
A menudo se debe a método de puerto incorrecto (sin Multi-Auth/Multi-Domain), priorización errónea (MAB/802.1X) o reautenticación demasiado agresiva. Los dispositivos VoIP a menudo necesitan un perfil propio (Voice VLAN, marcas QoS), y procesan 802.1X de formas diferentes.
Caso 4: impresora/IoT deja de funcionar aunque MAB esté activado
Compruebe la randomización de MAC (en algunos dispositivos/adaptadores), los límites de Port-Security (máx. de MACs) y si el dispositivo está conectado detrás de un switch pequeño. MAB verá entonces la MAC del uplink, no la del equipo final. En esos casos necesita o bien dispositivos compatibles con 802.1X, puertos separados o una estrategia de conexión distinta.
Patrón de fallo 5: Todo funciona en el piloto, pero en el despliegue falla en áreas concretas
Esto suele indicar plantillas de switch inconsistentes, distintos niveles de firmware, parámetros AAA diferentes o un problema de enrutamiento/firewall hacia los RADIUS-Servern. Un control de configuración basado en diffs para dispositivos de red se amortiza de inmediato.
Fragmentos de configuración de ejemplo: Qué debe documentar y versionar
La configuración concreta de switch/AP depende del fabricante. Para la operación y el control de cambios es, sin embargo, crucial que versione ordenadamente sus parámetros: RADIUS-Server, gestión de secretos, orden de autenticación, mapeo VLAN/ACL, temporizadores, failover. Más abajo hay ejemplos intencionadamente genéricos como plantilla de documentación.
RADIUS-Client-Definition (Beispiel INI-ähnlich)
; Dokumentationsvorlage: RADIUS-Clients pro Authenticator
; Nicht 1:1 für ein bestimmtes Produkt gedacht.
[client:access-switch-12]
ip = 10.20.30.12
secret = <rotierbares_shared_secret>
ports = 1812,1813
coa_port = 3799
notes = Access-Layer, Etage 3, Ports 1-48Asignación de políticas (ejemplo YAML para documentación interna/automatización)
# Beispiel: Rollen auf Netzprofile abbilden (für Doku, IaC oder NAC-Policy-Design)
roles:
managed_workstation:
auth_method: eap-tls
network_profile:
vlan: 120
RESTrictions: standard
managed_admin:
auth_method: eap-tls
network_profile:
vlan: 130
RESTrictions: privileged
unmanaged_printer:
auth_method: mab
network_profile:
vlan: 220
RESTrictions: limited
guest:
auth_method: captive_or_psk
network_profile:
vlan: 300
RESTrictions: internet_only
fallbacks:
radius_unreachable:
behavior: controlled_fail_open
network_profile:
vlan: 210
RESTrictions: remediation_onlyComandos de comprobación para la resolución de problemas (Linux-Client, contexto EAP/WLAN)
# Link und Treiberzustand
ip link
nmcli device status
# WLAN-Details (wenn zutreffend)
iw dev
# Logs (systemd-basierte Distributionen)
journalctl -u NetworkManager --since "-30 min" | tail -n 200Estos bloques no reemplazan la documentación del proveedor, pero ayudan a operar su proyecto NAC de forma reproducible: qué es „Standard“, qué es excepción y qué fallbacks se han definido deliberadamente.
Estrategia de rollback que no solo funcione en el papel
Un rollback en 802.1X no es un único interruptor si ya ha reconfigurado VLANs/ACLs y perfiles. Defina por tanto una estrategia de retroceso en tres niveles:
1) Retroceso técnico por segmento
- Plantillas de puertos de switch preparadas: „Enforcement“ y „Open/Legacy“
- Límites claros de scope: ¿qué bloque de switch/AP puede aislarse y revertirse?
- Puerto(s) Break-Glass: físicamente asegurados, documentados, probados
2) Retroceso AAA (interrupción de RADIUS)
- Utilizar activamente la redundancia RADIUS (no solo tenerla instalada)
- Monitorización de la disponibilidad de RADIUS y de picos de rechazos
- Decisión definida de Fail-Open/Fail-Closed por clase de red (Office vs. Producción)
3) Retroceso organizativo
- Runbook del Service Desk: ¿qué preguntas, qué logs, qué medidas estándar?
Lo esencial es: el rollback debe practicarse. Un plan de retroceso no probado es inútil durante un incidente.
Seguridad y operación: hardening, monitorización, ciclos de vida
Tras el despliegue comienza la operación real. Estos temas deberían integrarse en sus procesos operativos:
- Ciclo de vida de certificados: renovación automática, informes de expiración, procesos de revocación en caso de pérdida de dispositivos.
- Control de cambios de políticas: tratar las modificaciones en roles/VLANs como reglas de firewall (revisión, pruebas, rollback).
- Registro/Auditoría: clasificar los motivos de rechazo, alertar sobre patrones inusuales (p. ej., muchos eventos MAB en un puerto).
- Reducir deuda técnica: disminuir excepciones MAB, reemplazar equipos antiguos, eliminar switches „sombra“.
Conclusión: 1X Network Access Control es un proyecto que se fortalece con la operación
802.1X y RADIUS son tecnologías maduras, pero su éxito depende de la interacción entre identidades, certificados, políticas NAC claras y un despliegue que controle las excepciones en lugar de ocultarlas. Si inicia con una fase de monitorización, separe los perfiles con claridad (estándar, cuarentena, dispositivos especiales), tome el registro en serio desde el principio y defina una estrategia real de retroceso, 1X Network Access Control no se convertirá en una obra permanente, sino en una base estable para segmentación, modelos de acceso próximos a Zero Trust y decisiones de red auditables.