Cómo configurar un servidor RADIUS para la autenticación WiFi
Esta guía autorizada ofrece a los líderes de TI y arquitectos de red un plan integral para implementar un servidor RADIUS para la autenticación WiFi empresarial. Cubre las ventajas y desventajas arquitectónicas entre las implementaciones locales y en la nube, la selección del método EAP, la integración con Active Directory y la asignación dinámica de VLAN. Los operadores de recintos y los equipos de TI encontrarán pasos de implementación prácticos, casos de estudio reales y estrategias de mitigación de riesgos para pasar de un entorno PSK inseguro a una infraestructura 802.1X sólida este trimestre.
Escuchar esta guía
Ver transcripción del podcast
Resumen Ejecutivo
Para los entornos empresariales —ya sea un campus universitario en expansión, un estadio de alta densidad o una cadena de tiendas distribuidas—, depender de una clave precompartida (PSK) para el acceso a la WiFi es un riesgo de seguridad significativo. Una sola credencial comprometida expone a toda la red, y revocar el acceso requiere cambiar la contraseña de cada dispositivo de la infraestructura. La implementación de la autenticación 802.1X a través de un servidor RADIUS (Remote Authentication Dial-In User Service) elimina este problema por completo: cada usuario se autentica individualmente, el acceso se puede revocar al instante y la segmentación de la red se aplica de forma dinámica.
Esta guía proporciona una hoja de ruta definitiva para que los responsables de TI y los arquitectos de red implementen la autenticación RADIUS. Analizamos las ventajas y desventajas arquitectónicas entre las implementaciones locales y en la nube, la configuración de los métodos del Protocolo de Autenticación Extensible (EAP) y la integración con servicios de directorio como Active Directory. También demostramos cómo una capa de autenticación sólida se integra con las soluciones de Guest WiFi para proporcionar un acceso fluido a los visitantes, al tiempo que se capturan las WiFi Analytics que convierten su red en un activo de inteligencia empresarial.
Análisis Técnico Detallado
La Arquitectura 802.1X
El estándar IEEE 802.1X define el control de acceso a la red basado en puertos (PNAC). En un contexto inalámbrico, implica tres roles principales que funcionan en conjunto:
| Rol | Componente | Responsabilidad |
|---|---|---|
| Suplicante | Dispositivo cliente (portátil, smartphone) | Presenta las credenciales para solicitar acceso a la red |
| Autenticador | Punto de acceso o controlador WiFi | Aplica el control de acceso; retransmite los mensajes EAP |
| Servidor de Autenticación | Servidor RADIUS | Valida las credenciales; devuelve atributos de aceptación/rechazo y de políticas |
Cuando un suplicante se asocia con un punto de acceso, el AP bloquea todo el tráfico de datos excepto los mensajes EAP (Protocolo de Autenticación Extensible). El AP encapsula estos mensajes EAP en paquetes RADIUS y los reenvía al servidor RADIUS. El servidor verifica las credenciales con una base de datos back-end —normalmente LDAP o Active Directory— y devuelve un mensaje Access-Accept o Access-Reject. Si se acepta, el AP desbloquea el puerto y el tráfico del cliente fluye libremente.
Elección de un Método EAP
La seguridad de su implementación de RADIUS depende en gran medida del método EAP seleccionado. Los dos más prevalentes en las implementaciones empresariales son:
EAP-TLS (Transport Layer Security) es el estándar de oro. Requiere certificados digitales tanto en el servidor RADIUS como en cada dispositivo cliente, eliminando por completo las contraseñas. Incluso si un atacante captura el intercambio de autenticación completo, no hay credenciales que extraer. La contrapartida es la sobrecarga administrativa: implementar y gestionar certificados de cliente requiere una Infraestructura de Clave Pública (PKI) en funcionamiento y una solución MDM (por ejemplo, Microsoft Intune, Jamf) para distribuir los certificados a los endpoints.
PEAP-MSCHAPv2 (EAP protegido) es el método más implementado en la práctica. Utiliza un certificado en el lado del servidor para establecer un túnel TLS cifrado, dentro del cual el cliente se autentica con un nombre de usuario y una contraseña. Esto es significativamente más fácil de implementar que EAP-TLS porque solo se necesita gestionar un certificado: el del servidor. Sin embargo, conlleva una advertencia crítica: si los dispositivos cliente no están configurados explícitamente para validar el certificado del servidor RADIUS, son vulnerables a ataques de intermediario (MitM) a través de puntos de acceso no autorizados.
> Nota de seguridad crítica: No aplicar una validación estricta de certificados en los dispositivos cliente anula de manera efectiva los beneficios de seguridad de PEAP-MSCHAPv2. Un atacante puede desplegar un AP no autorizado, presentar un certificado fraudulento y capturar las credenciales de los usuarios en texto plano. Este no es un riesgo teórico: es un vector de ataque bien documentado que ha sido explotado en entornos reales.
Guía de implementación
Paso 1: Decisión arquitectónica — RADIUS local frente a Cloud RADIUS
La primera decisión es dónde alojar la infraestructura RADIUS. Se trata principalmente de una cuestión operativa y de costes, no de seguridad: ambos modelos pueden implementarse de forma segura.
RADIUS local (por ejemplo, Microsoft NPS, FreeRADIUS, Cisco ISE) es adecuado para organizaciones con personal de TI dedicado, infraestructura de directorio local existente y requisitos estrictos de cumplimiento o soberanía de datos. No depende de la conectividad a Internet para la autenticación, lo que supone una ventaja significativa para entornos donde no se puede garantizar el tiempo de actividad de Internet.
Cloud RADIUS es cada vez más el modelo preferido para entornos distribuidos: cadenas de Retail , grupos de Hospitality y centros de Transport donde implementar servidores en cada ubicación resulta operativamente inviable. Cloud RADIUS se integra de forma nativa con proveedores de identidad en la nube (Azure AD, Google Workspace, Okta) y proporciona alta disponibilidad integrada y escalabilidad global.
Paso 2: Instalar y configurar el servidor RADIUS
Para una implementación local utilizando Microsoft NPS (la opción más común en entornos centrados en Windows):
- Instale el rol Servidor de políticas de red (NPS) a través del Administrador del servidor.
- Registre el servidor NPS en Active Directory para permitirle leer las propiedades de marcado de los usuarios.
- Cree una entrada de Cliente RADIUS para cada punto de acceso o controlador inalámbrico, especificando la dirección IP del AP y un Secreto compartido fuerte y único.
- Configure una Política de red que defina las condiciones (por ejemplo, pertenencia a un grupo de usuarios) y las restricciones (por ejemplo, método EAP, tiempo de espera de la sesión) para el acceso.
- Configure la Política de solicitud de conexión para procesar las solicitudes localmente.
Para FreeRADIUS en Linux:
- Instale a través del gestor de paquetes:
sudo apt-get install freeradius freeradius-ldap. - Configure
/etc/freeradius/3.0/clients.confpara definir los clientes RADIUS (APs) y sus secretos compartidos. - Configure el módulo LDAP en
/etc/freeradius/3.0/mods-available/ldappara que apunte a su Active Directory o servidor LDAP. - Habilite el módulo LDAP:
sudo ln -s /etc/freeradius/3.0/mods-available/ldap /etc/freeradius/3.0/mods-enabled/. - Defina los métodos EAP en
/etc/freeradius/3.0/mods-available/eap.
Paso 3: Configurar los puntos de acceso
En su controlador inalámbrico o en los puntos de acceso individuales:
- Defina la(s) dirección(es) IP del servidor RADIUS y el puerto de autenticación (por defecto: UDP 1812).
- Configure el Secreto compartido: utilice un mínimo de 22 caracteres, mezclando caracteres alfanuméricos y especiales. Utilice un secreto único por ubicación o grupo de AP.
- Configure el SSID para utilizar el modo de seguridad WPA2-Enterprise o WPA3-Enterprise con gestión de claves 802.1X.
- Configure un servidor RADIUS secundario para la tolerancia a fallos.
Paso 4: Integración del directorio
Para la integración con AD local, el servidor RADIUS debe estar unido al dominio o tener acceso de lectura LDAP. Asegúrese de que las cuentas de servicio utilizadas para la vinculación LDAP tengan los permisos mínimos requeridos. Para RADIUS en la nube, configure la sincronización basada en API o la integración SAML/OIDC con su IdP.
Defina grupos de usuarios claros en su directorio, ya que estos impulsarán las políticas de autorización. Estructura de grupos recomendada:
| Grupo | VLAN | Nivel de acceso |
|---|---|---|
Corp_Staff |
VLAN 10 | Red interna completa |
Corp_Contractors |
VLAN 20 | Internet + recursos internos específicos |
Corp_IoT |
VLAN 30 | Solo puertos aislados específicos del dispositivo |
Corp_Guests |
VLAN 100 | Solo Internet a través de Captive Portal |
Paso 5: Configuración del cliente y validación de certificados
Este es el paso más crítico a nivel operativo. Utilice Directivas de grupo (GPO) para Windows y perfiles MDM para macOS/iOS/Android para enviar las configuraciones de WiFi de forma silenciosa a los dispositivos gestionados. El perfil debe especificar:
- La CA raíz que emitió el certificado del servidor RADIUS.
- El nombre de servidor esperado (CN o SAN del certificado del servidor).
- El método EAP y el protocolo de autenticación interna.
Para dispositivos BYOD no gestionados, proporcione instrucciones claras de incorporación en autoservicio, idealmente a través de un portal de Control de acceso a la red (NAC).
Paso 6: Implementar la asignación dinámica de VLAN
Configure el servidor RADIUS para que devuelva los atributos de asignación de VLAN en la respuesta Access-Accept:
Tunnel-Type=VLAN(13)Tunnel-Medium-Type=IEEE-802(6)Tunnel-Private-Group-Id= ``
El punto de acceso lee estos atributos y coloca al cliente autenticado en la VLAN especificada, sin necesidad de reconfiguración manual a medida que los usuarios cambian de rol o de ubicación.
Buenas prácticas
La redundancia no es negociable. Despliegue un mínimo de dos servidores RADIUS (principal y secundario) y configure todos los puntos de acceso para que realicen la conmutación por error de forma automática. Para despliegues locales, considere ubicar el servidor secundario en una ubicación física o zona de disponibilidad diferente. Una caída de RADIUS significa que nadie puede autenticarse, lo que se traduce en una caída total de la red para los SSID protegidos por 802.1X.
Supervise la expiración de los certificados de forma proactiva. La expiración del certificado del servidor RADIUS es una de las causas más comunes de fallos de autenticación repentinos y generalizados. Implemente una monitorización que alerte a los administradores al menos 30 días antes de la expiración. Esto se aplica tanto al certificado del servidor como a cualquier certificado de CA intermedia de la cadena.
Trate el Secreto Compartido como una credencial crítica. El secreto compartido entre el AP y el servidor RADIUS cifra los paquetes RADIUS. Utilice secretos únicos por ubicación o grupo de AP, almacénelos en un gestor de secretos y rótelos periódicamente. Consulte nuestra guía sobre Proteja su red con DNS y seguridad robustos para obtener recomendaciones más amplias sobre higiene de seguridad de red.
Alineación con los marcos de cumplimiento. Para entornos sujetos a PCI DSS (por ejemplo, redes de pago minoristas), la autenticación 802.1X respalda directamente los requisitos de control de acceso a la red y registro de auditoría. Para el cumplimiento de GDPR, los registros de contabilidad de RADIUS (puerto 1813) proporcionan un registro de auditoría detallado de quién accedió a la red, desde dónde y cuándo, lo cual es muy valioso para la respuesta a incidentes. Para entornos de Sanidad , la segmentación de red mediante la asignación dinámica de VLAN respalda los requisitos de HIPAA para proteger la información de salud electrónica protegida (ePHI).
Resolución de problemas y mitigación de riesgos
| Modo de fallo | Síntoma | Resolución |
|---|---|---|
| Expiración de certificado | Fallos repentinos de autenticación masiva | Supervisar la expiración; renovar y volver a desplegar el certificado |
| Desincronización de NTP | Fallos intermitentes de EAP-TLS | Asegurar que el servidor RADIUS y los DC se sincronicen con la misma fuente NTP |
| Pérdida de conectividad LDAP | La autenticación falla cuando AD no está accesible | Desplegar DC redundantes; configurar RADIUS para almacenar en caché autenticaciones recientes |
| Secreto compartido incorrecto | Los registros del AP muestran RADIUS timeout o Bad authenticator |
Verificar que el secreto coincida tanto en el AP como en el servidor RADIUS |
| Discrepancia de certificado de cliente | Fallos de EAP-TLS para dispositivos específicos | Verificar que el certificado de cliente esté emitido por una CA de confianza; comprobar el periodo de validez del certificado |
| VLAN no asignada | Usuario autenticado pero en el segmento de red incorrecto | Verificar que los atributos RADIUS se devuelvan correctamente; comprobar la configuración de VLAN del AP |
Para profundizar en el proceso de configuración de 802.1X, la guía Cómo configurar la autenticación WiFi 802.1X: Guía paso a paso ofrece tutoriales de configuración detallados y específicos para cada fabricante.
ROI e impacto empresarial
La transición de PSK a 802.1X respaldado por RADIUS requiere una inversión inicial en configuración y, potencialmente, licencias para soluciones en la nube o hardware para despliegues locales. El caso de ROI es claro:
Mitigación de riesgos: El coste medio de una brecha de datos en el Reino Unido supera los 3 millones de libras (según el informe Cost of a Data Breach de IBM). Una PSK comprometida puede exponer toda la red. 802.1X limita el radio de impacto a una única cuenta de usuario comprometida, que puede desactivarse en segundos a través del directorio.
Eficiencia operativa: La asignación dinámica de VLAN elimina la reconfiguración manual de la red cuando el personal cambia de función. Incorporar a un nuevo empleado consiste simplemente en añadirlo al grupo de AD correcto; el acceso a la red se aplica automáticamente.
Cumplimiento normativo: Para las organizaciones sujetas a PCI DSS, ISO 27001 o Cyber Essentials Plus, 802.1X es un control directo que los auditores esperan ver. Su despliegue refuerza su postura de cumplimiento y reduce los costes de remediación de auditorías.
Experiencia de invitados y analítica: Para los operadores de recintos, integrar RADIUS para la autenticación del personal con la plataforma de Guest WiFi de Purple para el acceso de visitantes crea un modelo de acceso unificado y por niveles. El personal se autentica de forma silenciosa a través de 802.1X; los invitados se conectan a través de un Captive Portal personalizado. La plataforma de WiFi Analytics de Purple ofrece entonces visibilidad en tiempo real sobre los tiempos de permanencia de los visitantes, las tasas de visitas repetidas y las métricas de interacción, datos que informan directamente las decisiones de gasto en marketing y operaciones del recinto.
Para más información, consulte Como Configurar a Autenticação 802.1X WiFi: Um Guia Passo a Passo para obtener orientación sobre la implementación en portugués, y What Is a Leased Line? Dedicated Business Internet para asegurar que la conectividad subyacente cumpla con los requisitos empresariales.
Definiciones clave
RADIUS (Remote Authentication Dial-In User Service)
Un protocolo de red que proporciona una gestión centralizada de Autenticación, Autorización y Contabilidad (AAA) para los usuarios que se conectan a un servicio de red. Definido en RFC 2865.
El componente de servidor principal que valida las credenciales de usuario contra un directorio antes de otorgar acceso WiFi. Cada despliegue de WiFi empresarial que utiliza 802.1X requiere un servidor RADIUS.
802.1X
Un estándar IEEE para el Control de Acceso a Red basado en puertos (PNAC). Proporciona un mecanismo de autenticación a los dispositivos que desean conectarse a una LAN o WLAN, bloqueando todo el tráfico que no sea EAP hasta que la autenticación se realice con éxito.
El estándar de marco global que define cómo se comunican el Supplicant, el Authenticator y el Servidor de Autenticación. Cuando los equipos de TI se refieren a la "seguridad WiFi empresarial", normalmente se refieren a WPA2/WPA3-Enterprise con 802.1X.
Supplicant
El dispositivo cliente — o más precisamente, la pila de software 802.1X en ese dispositivo — que inicia el proceso de autenticación presentando las credenciales a la red.
En Windows, el supplicant integrado es el servicio Wireless AutoConfig. En macOS e iOS, es nativo del sistema operativo. Garantizar que el supplicant esté configurado correctamente (especialmente para la validación de certificados) es la fuente más común de problemas de despliegue.
Authenticator
El dispositivo de red — normalmente un punto de acceso WiFi o un controlador inalámbrico — que actúa como intermediario entre el Supplicant y el servidor RADIUS, aplicando el control de acceso en función del resultado de la autenticación.
El AP bloquea todo el tráfico de datos en el puerto hasta que recibe un Access-Accept del servidor RADIUS. También lee los atributos RADIUS (por ejemplo, la asignación de VLAN) de la respuesta Access-Accept y los aplica a la sesión.
EAP (Extensible Authentication Protocol)
Un marco de autenticación definido en RFC 3748 que proporciona un mecanismo de transporte estandarizado para varios métodos de autenticación (TLS, PEAP, TTLS, etc.) entre el Supplicant y el Servidor de Autenticación.
EAP es el "idioma" que se habla entre el cliente y el servidor RADIUS. La elección del método EAP (EAP-TLS frente a PEAP) determina la solidez de la seguridad y la complejidad del despliegue del sistema de autenticación.
PEAP (Protected EAP)
Un método EAP que primero establece un túnel TLS utilizando el certificado del servidor y luego realiza una autenticación secundaria (normalmente MSCHAPv2 con usuario/contraseña) dentro de ese túnel cifrado.
El método de autenticación WiFi empresarial más común debido a su equilibrio entre seguridad y simplicidad de despliegue. Requiere solo un certificado en el lado del servidor, lo que hace que sea mucho más fácil de implementar que EAP-TLS.
Dynamic VLAN Assignment
Una función de RADIUS en la que el servidor incluye atributos específicos de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) en la respuesta Access-Accept, indicando al AP que coloque al cliente autenticado en una VLAN específica.
Permite que un único SSID sirva a múltiples poblaciones de usuarios con diferentes requisitos de seguridad. Elimina la necesidad de transmitir múltiples SSID para diferentes grupos de usuarios, reduciendo la sobrecarga de RF y simplificando la experiencia del usuario.
Shared Secret
Una cadena de texto preconfigurada conocida únicamente por el Authenticator (AP) y el servidor RADIUS, utilizada para firmar y cifrar paquetes RADIUS, garantizando la integridad y autenticidad de la comunicación.
Un elemento crítico de configuración de seguridad. Si el shared secret es débil o está comprometido, un atacante podría falsificar respuestas Access-Accept de RADIUS, otorgando acceso no autorizado a la red. Utilice secretos únicos por ubicación y almacénelos en un gestor de secretos.
MAC Authentication Bypass (MAB)
Un mecanismo de autenticación alternativo en el que la dirección MAC de un dispositivo se utiliza como su credencial de identidad, lo que permite el acceso a la red para dispositivos que no admiten supplicants 802.1X.
Se utiliza para dispositivos sin interfaz de usuario (impresoras, sensores IoT, cámaras IP). Debido a que las direcciones MAC son visibles públicamente y fáciles de suplantar, MAB proporciona identificación de dispositivos en lugar de una autenticación sólida. Emparéjelo siempre con una asignación de VLAN restrictiva.
Ejemplos prácticos
Una cadena minorista nacional con 500 ubicaciones necesita implementar WiFi seguro para las tabletas de los gerentes de tienda y las terminales de punto de venta (POS). Actualmente utilizan una única PSK en todas las tiendas, que se comparte con frecuencia con personal y contratistas no autorizados. Utilizan Azure AD para la gestión de identidades y no disponen de personal de TI dedicado en las sucursales.
Implementar una solución Cloud RADIUS integrada directamente con Azure AD. Esto elimina la necesidad de desplegar y gestionar servidores RADIUS locales en 500 ubicaciones. El equipo de TI utiliza Microsoft Intune para enviar un perfil de WiFi a todas las tabletas de los gerentes de tienda y terminales POS configuradas para PEAP-MSCHAPv2, aplicando estrictamente la validación del certificado del servidor Cloud RADIUS. La política de Cloud RADIUS comprueba la pertenencia al grupo de Azure AD del usuario antes de conceder el acceso: el grupo "Store_Managers" recibe la VLAN 10 (acceso completo a POS y back-office), el grupo "Contractors" recibe la VLAN 20 (solo internet). Cuando finaliza el contrato de un colaborador externo, al eliminarlo del grupo de Azure AD se revoca inmediatamente su acceso a la WiFi en las 500 ubicaciones de forma simultánea, sin necesidad de cambiar la PSK.
Un hotel de 400 habitaciones en el centro de la ciudad necesita proporcionar WiFi seguro tanto para el personal (recepción, limpieza, administración) como para los huéspedes. El personal requiere acceso al sistema de gestión de la propiedad (PMS) y a los servidores internos. Los huéspedes solo necesitan acceso a internet. El hotel dispone de un único entorno local de Windows Server.
Implementar Microsoft NPS en una máquina virtual dedicada de Windows Server. Configurar dos SSIDs en la infraestructura inalámbrica: "Hotel_Staff" (WPA2-Enterprise, 802.1X) y "Hotel_Guest" (abierto o WPA2-Personal, que redirige a un Captive Portal). Para el SSID del personal, NPS valida las credenciales contra Active Directory y devuelve asignaciones dinámicas de VLAN: grupo de AD "Management" → VLAN 10 (acceso completo), "FrontDesk" → VLAN 20 (acceso al PMS), "Housekeeping" → VLAN 30 (solo internet + aplicación de programación). Para los huéspedes, integre el Captive Portal con la plataforma Guest WiFi de Purple para ofrecer una experiencia de inicio de sesión personalizada, recopilar datos de origen (correo electrónico, consentimiento de marketing) y obtener análisis sobre el tiempo de permanencia y las visitas recurrentes. El modelo de dos SSIDs mantiene el tráfico del personal y de los huéspedes completamente separado en la capa de red.
Preguntas de práctica
Q1. Su organización está migrando 2.000 portátiles Windows de una PSK compartida a 802.1X con PEAP-MSCHAPv2. Su equipo de seguridad advierte que PEAP es vulnerable a la recopilación de credenciales a través de puntos de acceso no autorizados (rogue AP). ¿Cuál es el paso de configuración más importante para mitigar este riesgo y cómo lo despliega a escala?
Sugerencia: Considere qué impide que un cliente confíe en un servidor RADIUS fraudulento que presenta un certificado autofirmado.
Ver respuesta modelo
El paso crítico es aplicar una validación estricta del certificado del servidor en cada dispositivo cliente. Mediante Objetos de Directiva de Grupo (GPO), envíe un perfil de WiFi a los 2.000 portátiles que especifique: (1) el certificado de la CA raíz exacto que emitió el certificado del servidor RADIUS, (2) el nombre de servidor esperado (CN/SAN) y (3) que el cliente no debe solicitar al usuario que confíe en nuevos certificados. Esto garantiza que incluso si un atacante despliega un AP no autorizado con un certificado fraudulento, el cliente rechazará el saludo TLS y se negará a enviar credenciales. Sin esta configuración, PEAP no proporciona ninguna protección significativa contra ataques de AP no autorizados.
Q2. El director de TI de un hospital necesita proporcionar acceso a la red a 300 dispositivos IoT médicos (bombas de infusión, equipos de monitorización) que no son compatibles con 802.1X. Estos dispositivos coexisten con las estaciones de trabajo del personal en la misma infraestructura inalámbrica. ¿Cómo debe gestionar la infraestructura RADIUS estos dispositivos y qué controles de red deben implementarse?
Sugerencia: Piense en el método de autenticación disponible para dispositivos sin interfaz de usuario (headless) y cómo compensar su debilidad inherente.
Ver respuesta modelo
Configure MAC Authentication Bypass (MAB) en el servidor RADIUS para estos dispositivos específicos. Registre la dirección MAC de cada dispositivo en un grupo dedicado de Active Directory o en la base de datos RADIUS. Dado que las direcciones MAC se pueden suplantar fácilmente, el servidor RADIUS debe utilizar la asignación dinámica de VLAN para ubicar todos los dispositivos autenticados por MAB en una VLAN dedicada y altamente restringida (por ejemplo, VLAN 30 - IoT). Esta VLAN debe estar protegida por un cortafuegos para permitir la comunicación únicamente con direcciones IP de servidores médicos específicos y bloquear todo el demás tráfico, incluido el acceso a Internet y el movimiento lateral hacia las VLAN del personal. Las estaciones de trabajo del personal se autentican mediante 802.1X y se ubican en una VLAN independiente. Esta arquitectura cumple con los requisitos de segmentación de red de HIPAA para dispositivos adyacentes a ePHI.
Q3. Usted es el arquitecto de red de una cadena de restaurantes con 50 establecimientos. La autenticación funciona correctamente en 49 de ellos utilizando Cloud RADIUS, pero un establecimiento específico informa de que todos los dispositivos fallan al autenticarse. El portal de gestión de Cloud RADIUS muestra cero solicitudes de autenticación procedentes de ese establecimiento. ¿Cuál es su enfoque de diagnóstico?
Sugerencia: Si el servidor RADIUS no recibe ninguna solicitud, el problema está en la ruta de comunicación entre el autenticador y el servidor, no en la lógica de autenticación en sí.
Ver respuesta modelo
Dado que el servidor RADIUS no recibe ninguna solicitud de este establecimiento, el fallo se encuentra entre los puntos de acceso y el servidor Cloud RADIUS. Pasos de diagnóstico en orden: (1) Verificar la dirección IP y el puerto del servidor RADIUS (UDP 1812) configurados en los AP o en el controlador inalámbrico del establecimiento (un error tipográfico aquí es la causa más común). (2) Comprobar las reglas del cortafuegos local o del router en ese establecimiento para confirmar que se permite el tráfico UDP 1812 saliente hacia el rango de IP de Cloud RADIUS. (3) Verificar que el Secreto Compartido (Shared Secret) configurado en los AP coincide con el secreto configurado para ese establecimiento en el portal de Cloud RADIUS (una discrepancia hace que el servidor RADIUS descarte silenciosamente los paquetes). (4) Comprobar si la conexión a Internet del establecimiento funciona (Cloud RADIUS requiere conectividad a Internet fiable). Realizar una captura de paquetes en el AP o en el router ascendente confirmará si se están enviando paquetes RADIUS y si se están recibiendo respuestas.
Continúe leyendo esta serie
PSK por dispositivo según el fabricante: comparación de iPSK, DPSK, MPSK y PPSK (y compatibilidad con WPA3)
Una comparación exhaustiva de las implementaciones de PSK por dispositivo en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet y Ubiquiti UniFi. Descubra cómo afecta WPA3-SAE a las estrategias de claves por dispositivo y cuándo implementar modos de transición en lugar de migrar a 802.1X.
Comparativa de métodos de autenticación de Captive Portal
Esta guía de referencia técnica autorizada evalúa las ventajas y desventajas arquitectónicas, operativas y de cumplimiento de cinco métodos principales de autenticación de Captive Portal. Proporciona a los arquitectos de red, directores de TI y directores de marketing los datos cuantitativos y los marcos de decisión necesarios para equilibrar la fricción en el registro de invitados con los requisitos de recopilación de datos en los recintos empresariales.
¿Qué es la autenticación por dirección MAC? Cuándo usarla y cuándo evitarla
Esta guía de referencia técnica autorizada aborda la autenticación por dirección MAC en entornos WiFi empresariales: cómo funciona la autenticación MAC basada en RADIUS en la Capa 2, sus vulnerabilidades de seguridad inherentes (incluido el spoofing de MAC y el impacto de la aleatorización de MAC a nivel de sistema operativo) y los contextos operativos precisos donde sigue siendo una herramienta válida para gestionar dispositivos IoT y headless. Proporciona orientación de despliegue práctica para responsables de TI y arquitectos de red en sectores como hostelería, retail, sanidad y espacios públicos, con ejemplos prácticos reales, marcos de decisión y contexto de integración para la plataforma de analítica y WiFi de invitados de Purple.