RADIUS Server High Availability: Active-Active vs Active-Passive

# Alta disponibilidad del servidor RADIUS: Activo-Activo frente a Activo-Pasivo ## Informe técnico de Purple — Guion de podcast (~10 minutos) --- **PARTE 1 — INTRODUCCIÓN Y CONTEXTO (aprox. 1 minuto)** Bienvenido al informe técnico de Purple. Soy su anfitrión, y hoy abordamos una de las decisiones de infraestructura más trascendentales para cualquier organización que gestione WiFi empresarial: la alta disponibilidad del servidor RADIUS. Si es un arquitecto de redes o un director de TI responsable de la infraestructura de autenticación en un grupo hotelero, una cadena de tiendas, un estadio o una instalación del sector público, este informe le proporcionará los marcos de trabajo y los detalles técnicos específicos que necesita para tomar la decisión correcta, y evitar los errores que provocan caídas de autenticación en el peor momento posible. Permítame situarle en el contexto. RADIUS (Remote Authentication Dial-In User Service) es el guardián de su red. Cada vez que un empleado se conecta a través de 802.1X, o un invitado se autentica a través de su Captive Portal, RADIUS es el motor que comprueba las credenciales y autoriza el acceso. Es la columna vertebral de los despliegues empresariales IEEE 802.1X y WPA3. Y a diferencia de la mayoría de los servicios de TI que se degradan de forma progresiva cuando fallan, RADIUS es binario: o funciona, o nadie entra en la red. Esa asimetría es lo que hace que la alta disponibilidad sea tan crítica. --- **PARTE 2 — ANÁLISIS TÉCNICO DETALLADO (aprox. 5 minutos)** Empecemos por lo fundamental. RADIUS funciona sobre UDP, normalmente en el puerto 1812 para la autenticación y en el 1813 para la contabilidad (accounting). La naturaleza sin estado de UDP es en realidad una ventaja para el diseño de alta disponibilidad: dado que cada solicitud de autenticación es independiente, cualquier servidor de un clúster puede gestionar cualquier solicitud sin necesidad de saber qué ocurrió antes. Esta es la propiedad arquitectónica que hace que los despliegues activo-activo sean tan elegantes. Ahora bien, existen dos modelos principales de alta disponibilidad que debe conocer. **Activo-Pasivo** es el enfoque tradicional. Dispone de un servidor RADIUS principal que gestiona todo el tráfico de autenticación y de un servidor secundario en modo de espera (standby), que recibe los datos replicados pero no procesa las solicitudes. Cuando el principal falla, el dispositivo de acceso a la red (NAS) —su punto de acceso, su switch o su pasarela VPN— detecta el fallo y redirige el tráfico al secundario. ¿Cuánto tarda esa conmutación por error (failover)? Aquí es donde los detalles importan. El NAS envía una solicitud RADIUS y espera. El tiempo de espera de paquete predeterminado suele ser de dos segundos. Después de eso, reintenta; por lo general, tres intentos por servidor. Con dos servidores configurados, el tiempo máximo de detección de conmutación por error es de unos seis a doce segundos en un despliegue bien optimizado. En el peor de los casos, con tres servidores y temporizadores predeterminados, ese tiempo puede prolongarse hasta los dieciocho segundos. Para un huésped de hotel que intenta conectarse al hacer el registro de entrada, o un empleado de tienda que intenta procesar una transacción, esa espera resulta muy molesta. **Active-Active** es el enfoque más sofisticado y, para la mayoría de las implementaciones empresariales, es el adecuado. Ambos servidores RADIUS (o todos ellos) procesan las solicitudes de autenticación de forma simultánea. El tráfico se distribuye por todo el clúster, ya sea mediante rotación round-robin o a través de un equilibrador de carga dedicado. Cuando un nodo falla, los nodos restantes absorben su tráfico de inmediato. No hay retraso en la detección de la conmutación por error porque no existe una conmutación por error en el sentido tradicional: el equilibrador de carga simplemente deja de enviar solicitudes al nodo que presenta problemas, normalmente en un plazo de uno a dos segundos, según los intervalos de comprobación de estado. Los beneficios de rendimiento se multiplican. En un recinto de gran tamaño (piense en un estadio con capacidad para 60.000 personas o en un centro de conferencias que alberga una gran exposición), se pueden registrar miles de solicitudes de autenticación simultáneas cuando se abren las puertas o se produce un descanso en las sesiones. Un único servidor RADIUS, incluso uno con buenas especificaciones, puede convertirse en un cuello de botella. Un clúster active-active escala horizontalmente: añada otro nodo y añadirá capacidad proporcional. Ahora hablemos de la capa de base de datos, porque aquí es donde muchas implementaciones tienen problemas. La autenticación RADIUS en sí es en gran medida sin estado (el servidor comprueba las credenciales con un directorio y devuelve un Accept o un Reject). Sin embargo, el registro de conexiones (accounting) de RADIUS tiene estado: realiza un seguimiento del inicio de la sesión, de las actualizaciones provisionales y de los eventos de finalización de la sesión. Si utiliza el registro de conexiones para la facturación, el registro de cumplimiento o la gestión de sesiones, necesita que esos datos sean coherentes en todos los nodos. El enfoque estándar consiste en respaldar su clúster RADIUS con una base de datos replicada. FreeRADIUS, el servidor RADIUS de código abierto más implantado del mundo, se integra con MySQL y MariaDB. Para implementaciones active-active, dispone de dos opciones principales: MySQL NDB Cluster, que proporciona replicación síncrona multimaestro con conmutación por error en menos de un segundo, o Galera Cluster, que ofrece una replicación síncrona similar con una gestión operativa ligeramente más sencilla. Ambos eliminan el riesgo de pérdida de datos en caso de fallo del nodo. La replicación asíncrona (la réplica primaria estándar de MySQL) es más barata, pero introduce un retraso de replicación que puede dar lugar a la pérdida de registros de conexiones si la primaria falla antes de que se repliquen los cambios. Permítame abordar la cuestión de la distribución geográfica, ya que cada vez es más relevante para los operadores con múltiples sedes. Si gestiona una cadena de tiendas con 200 establecimientos o un grupo hotelero con propiedades en varios países, la pregunta no es solo "¿cómo hago para que mi servidor RADIUS sea redundante?", sino "¿dónde deben ubicarse mis servidores RADIUS en relación con mis puntos de acceso?" El retorno del tráfico de autenticación (backhauling) desde un sitio remoto a un centro de datos central introduce latencia de WAN y un punto único de fallo en el enlace WAN. Si ese enlace se cae, el sitio remoto no puede autenticar a nadie, independientemente de lo redundante que sea su clúster RADIUS central. La solución consiste en desplegar instancias RADIUS locales en cada sitio —lo que genera una sobrecarga operativa significativa— o en utilizar un servicio cloud RADIUS con nodos perimetrales distribuidos geográficamente. Las plataformas cloud RADIUS resuelven el problema de la alta disponibilidad a nivel arquitectónico. En lugar de que usted tenga que crear y gestionar una infraestructura redundante, el proveedor opera RADIUS en múltiples zonas de disponibilidad y regiones. La conmutación por error entre nodos se realiza de forma automática, normalmente en menos de un segundo, ya que la gestiona el equilibrio de carga interno de la plataforma y no los temporizadores de reintento del NAS. Los compromisos de SLA de los proveedores de cloud RADIUS empresariales suelen ser del 99,99 % de tiempo de actividad, lo que equivale a menos de 53 minutos de inactividad al año. También existe una dimensión de cumplimiento importante en este aspecto. PCI DSS exige controles de autenticación estrictos para los entornos de datos de titulares de tarjetas. El GDPR trata los registros de autenticación como datos personales, lo que requiere un manejo adecuado y controles de residencia de datos. Los proveedores de cloud RADIUS suelen contar con certificaciones SOC 2 Tipo II y ofrecen acuerdos de procesamiento de datos conformes al GDPR con opciones de residencia de datos regionales. Los despliegues locales le ofrecen un control total sobre la ubicación de los datos, algo fundamental en entornos sanitarios bajo los marcos de gobernanza de datos del NHS, o en instalaciones gubernamentales con requisitos de soberanía de datos. --- **PARTE 3 — RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES (aprox. 2 minutos)** Permítame guiarle a través de dos escenarios del mundo real que ilustran estos principios en la práctica. Primero: un grupo hotelero europeo con 45 propiedades en seis países. Su equipo de TI, compuesto por tres ingenieros, ejecutaba FreeRADIUS en máquinas virtuales en cada propiedad —45 instancias independientes que parchear, monitorizar y mantener—. Cuando caducó un certificado TLS en una de las propiedades, provocó una interrupción total del servicio de WiFi para huéspedes durante una conferencia importante. La solución requirió que un ingeniero se conectara en remoto y renovara manualmente el certificado, un proceso que llevó 40 minutos mientras los huéspedes no podían conectarse. Tras migrar a un servicio cloud RADIUS con gestión de políticas centralizada, el equipo eliminó por completo el mantenimiento por sitio. La rotación de certificados pasó a ser automática. Los tres ingenieros recuperaron aproximadamente el 40 por ciento del tiempo que antes dedicaban a las operaciones de RADIUS. Y lo que es más importante, la arquitectura activo-activo de la plataforma en múltiples regiones de la nube hizo que el fallo de un solo nodo —que antes habría provocado la caída de un sitio— dejara de ser un problema.Segundo escenario: un estadio deportivo nacional que alberga a 60.000 aficionados para un gran evento. El equipo de red había desplegado una configuración RADIUS activo-pasivo con un servidor principal y otro de reserva en caliente. Durante una prueba de carga previa al evento, descubrieron que el servidor principal se saturaba durante el pico de autenticación cuando se abrían las puertas, procesando 8.000 solicitudes de autenticación por minuto. El secundario pasivo estaba inactivo mientras el principal tenía dificultades. La solución fue reconfigurar los dispositivos NAS para utilizar un equilibrio de carga round-robin en ambos servidores, convirtiendo eficazmente el despliegue en activo-activo. El rendimiento de la autenticación se duplicó de inmediato. También añadieron un tercer servidor para proporcionar margen para la carga máxima y configuraron la replicación de Galera Cluster para la base de datos de contabilidad. El resultado fue un despliegue que podía absorber la pérdida de cualquier nodo individual sin ningún impacto visible para el usuario. Ahora, los errores comunes. El fallo más habitual es tratar al servidor RADIUS secundario como una copia de seguridad de "configurar y olvidar". Las configuraciones divergen. Los certificados caducan en el secundario mientras el principal funciona correctamente. Cuando el principal finalmente falla y el secundario toma el control, este también falla, por un motivo completamente diferente. La solución es sencilla: pruebe la conmutación por error con regularidad, al menos trimestralmente, y trate a ambos nodos como sistemas de producción. El segundo error es descuidar el retraso de replicación de la base de datos. Si utiliza una replicación asíncrona y el nodo de la base de datos principal falla, puede perder registros de contabilidad de las sesiones que estaban activas en el momento del fallo. Para el cumplimiento de PCI DSS, esta es una brecha grave. Utilice replicación síncrona (Galera o NDB) para cualquier despliegue donde la integridad de los datos de contabilidad sea un requisito de cumplimiento. --- **PARTE 4 — PREGUNTAS Y RESPUESTAS RÁPIDAS (aprox. 1 minuto)** Permítame abordar las preguntas que escucho con más frecuencia de los arquitectos de red. "¿Cuál es la configuración mínima viable de alta disponibilidad?" Dos servidores RADIUS con conmutación por error activo-pasivo, sincronización de secreto compartido y un backend de base de datos replicado. Ese es el mínimo. Para cualquier escenario con más de 500 usuarios concurrentes, pase a activo-activo. "¿Puedo utilizar un equilibrador de carga de hardware para RADIUS?" Sí, pero RADIUS utiliza UDP y muchos equilibradores de carga están optimizados para TCP. Asegúrese de que su equilibrador de carga admita el equilibrio de carga UDP con comprobaciones de estado. HAProxy Enterprise tiene un módulo UDP RADIUS dedicado. F5 BIG-IP lo gestiona de forma nativa. "¿Cómo gestiono la confianza de los certificados EAP en un clúster de alta disponibilidad?" Todos los nodos deben presentar el mismo certificado de servidor o, como mínimo, certificados de la misma cadena de CA. Los clientes validan el certificado del servidor durante los saludos EAP-TLS y PEAP; si los nodos presentan certificados diferentes, verá fallos de autenticación tras la conmutación por error. "¿Funciona el RADIUS en la nube con Active Directory local?" Sí, a través de un conector ligero o un proxy LDAP que consulta su AD local sin exponerlo directamente a internet. Este es el patrón de integración estándar para entornos híbridos. --- **PARTE 5 — RESUMEN Y PRÓXIMOS PASOS (aprox. 1 minuto)** Permítame concluir con las decisiones clave que debe tomar. Si gestiona menos de 500 usuarios simultáneos en una sola ubicación con un equipo estable para administrar la infraestructura, la configuración activo-pasivo con un procedimiento de failover bien probado es una opción defendible. Manténgalo simple, pruébelo con regularidad y utilice la replicación síncrona de bases de datos. Si gestiona un patrimonio multi-sitio, un recinto de alta densidad o si el ancho de banda de su equipo es limitado, la arquitectura activo-activo es la adecuada — y cloud RADIUS es el camino más rápido para lograrlo sin tener que construir la infraestructura usted mismo. Independientemente del modelo que elija, los principios son los mismos: distribuir en lugar de duplicar, automatizar las decisiones de failover y probar sus escenarios de fallo antes de que ellos le pongan a prueba a usted. Para obtener más información sobre cómo la plataforma de Purple gestiona la autenticación RADIUS a escala — incluyendo la integración con 802.1X, WPA3 enterprise y portales de WiFi para invitados — visite purple.ai. Hasta la próxima. --- *Fin del guion. Tiempo aproximado de lectura a 150 palabras por minuto: 10 minutos.*