Alta disponibilidad de servidores RADIUS: Active-Active frente a Active-Passive

# Alta disponibilidad del servidor RADIUS: Activo-Activo frente a Activo-Pasivo ## Dossier técnico de Purple - Guion de podcast (~10 minutos) --- **PARTE 1 - INTRODUCCIÓN Y CONTEXTO (aprox. 1 minuto)** Bienvenidos al dossier técnico de Purple. Soy su anfitrión, y hoy abordamos una de las decisiones de infraestructura más importantes para cualquier organización que gestione WiFi empresarial: la alta disponibilidad del servidor RADIUS. Si es usted arquitecto de redes o 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 dossier 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ítanme ponerles en situación. 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 mediante su Captive Portal, RADIUS es el motor que comprueba las credenciales y autoriza el acceso. Es la columna vertebral de los despliegues empresariales de 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 accede a 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 con lo fundamental. RADIUS funciona sobre UDP - normalmente el puerto 1812 para autenticación y el 1813 para contabilidad. La naturaleza sin estado de UDP es en realidad una ventaja para el diseño de alta disponibilidad: como cada solicitud de autenticación es independiente, cualquier servidor de un clúster puede gestionar cualquier solicitud sin necesidad de saber qué ha ocurrido 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 comprender. **Activo-Pasivo** es el enfoque tradicional. Dispone de un servidor RADIUS primario que gestiona todo el tráfico de autenticación y un servidor secundario en modo de espera, que recibe datos replicados pero no procesa solicitudes. Cuando el primario falla, el dispositivo de acceso a la red - su punto de acceso, su switch, su puerta de enlace VPN - detecta el fallo y redirige el tráfico al secundario. ¿Cuánto tiempo tarda esa conmutación por error? Aquí es donde importan los detalles. El NAS envía una solicitud de RADIUS y espera. El tiempo de espera de paquete por defecto suele ser de dos segundos. Después de eso, reintenta - normalmente tres intentos por servidor. Con dos servidores configurados, nos encontramos ante un tiempo máximo de detección de conmutación por error de entre seis y doce segundos en un despliegue bien optimizado. En el peor de los casos, con tres servidores y temporizadores por defecto, ese tiempo puede alargarse hasta los dieciocho segundos. Para el huésped de un hotel que intenta conectarse al registrarse, o el empleado de una tienda que intenta procesar una transacción, se trata de un intervalo doloroso. **Active-Active** es el enfoque más sofisticado y, para la mayoría de las implementaciones empresariales, es el adecuado. Ambos - o todos - los servidores RADIUS procesan las solicitudes de autenticación simultáneamente. El tráfico se distribuye a lo largo del 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 conmutación por error porque no hay conmutación por error en el sentido tradicional: el equilibrador de carga simplemente deja de enviar solicitudes al nodo en mal estado, normalmente en un plazo de uno a dos segundos en función de los intervalos de comprobación de estado. Los beneficios de rendimiento se multiplican. En un gran recinto - como un estadio con capacidad para 60.000 personas o un centro de conferencias que alberga una gran exposición - se pueden ver miles de solicitudes de autenticación simultáneas cuando se abren las puertas o se produce un descanso entre sesiones. Un único servidor RADIUS, incluso uno con buenas especificaciones, puede convertirse en un cuello de botella. Un clúster activo-activo 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 contra un directorio y devuelve un Accept o un Reject. Pero el registro de conexiones RADIUS (accounting) tiene estado: realiza el seguimiento de los eventos de inicio de sesión, actualizaciones intermedias y finalización de 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 es 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 activo-activo, dispone de dos opciones principales: MySQL NDB Cluster, que proporciona replicación síncrona multi-maestro 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 el primario falla antes de que se repliquen los cambios. Permítame abordar la cuestión de la distribución geográfica, ya que es cada vez más relevante para los operadores multisitio. 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 deberían ubicarse mis servidores RADIUS en relación con mis puntos de acceso?" El retorno de tráfico de autenticación desde un sitio remoto a un centro de datos central introduce latencia en la 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 la redundancia que tenga su clúster de RADIUS central. La solución consiste en desplegar instancias de RADIUS locales en cada sitio - lo que genera una carga operativa significativa - o bien utilizar un servicio de cloud RADIUS con nodos perimetrales distribuidos geográficamente. Las plataformas de cloud RADIUS resuelven el problema de la alta disponibilidad a nivel de arquitectura. 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 se gestiona mediante el equilibrio de carga interno de la plataforma en lugar de depender de los temporizadores de reintento del NAS. Los compromisos de SLA de los proveedores empresariales de cloud RADIUS suelen ofrecer un 99.99% de tiempo de actividad - lo que equivale a menos de 53 minutos de inactividad al año. También existe una importante dimensión de cumplimiento normativo. PCI-DSS exige controles estrictos de autenticación para los entornos de datos de titulares de tarjetas. El GDPR trata los registros de autenticación como datos personales, lo que requiere un tratamiento adecuado y controles de residencia de datos. Los proveedores de cloud RADIUS suelen poseer certificaciones SOC 2 Tipo II y ofrecen acuerdos de tratamiento de datos que cumplen con el GDPR con opciones de residencia de datos regionales. Los despliegues locales le otorgan 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 establecimientos en seis países. Su equipo de TI, formado 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, causó una interrupción total de la red WiFi para invitados durante una conferencia importante. Para solucionarlo, un ingeniero tuvo que conectarse en remoto y renovar manualmente el certificado - un proceso que llevó 40 minutos durante los cuales los invitados no pudieron conectarse. Tras migrar a un servicio de 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 de su tiempo, que antes dedicaban a operaciones de RADIUS. Y lo que es más importante, la arquitectura activo-activo de la plataforma en múltiples regiones de la nube significó que un fallo en un solo nodo - que antes habría provocado una caída del servicio en el sitio - se convirtió en un evento sin impacto.Segundo escenario: un estadio deportivo nacional que alberga a 60 000 aficionados para un evento importante. El equipo de red había implementado 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 8000 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 por turnos (round-robin) en ambos servidores, convirtiendo eficazmente la implementación 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 una implementación capaz de absorber la pérdida de cualquier nodo individual sin ningún impacto visible para el usuario. Ahora, los errores comunes. El error más frecuente es tratar el servidor RADIUS secundario como una copia de seguridad que "se configura y se olvida". Las configuraciones varían con el tiempo. 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 tolerancia a fallos con regularidad, al menos trimestralmente, y trate ambos nodos como sistemas de producción. El segundo error común 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 la replicación síncrona (Galera o NDB) para cualquier implementación en la que 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 redes. "¿Cuál es la configuración mínima viable de alta disponibilidad (HA)?" Dos servidores RADIUS con tolerancia a fallos 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 (HA)?" 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, experimentará fallos de autenticación tras la tolerancia a fallos. "¿Funciona RADIUS en la nube con Active Directory local?" Sí, a través de un conector ligero o un proxy LDAP que realiza consultas en 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 concurrentes en un único sitio con un equipo estable para administrar la infraestructura, un modelo activo - pasivo con un procedimiento de failover bien probado es una opción defendible. Manténgalo simple, pruébelo regularmente y utilice la replicación síncrona de bases de datos. Si gestiona un patrimonio multisitio, un espacio de alta densidad o si el ancho de banda de su equipo es limitado, la arquitectura activo - activo es la adecuada - y el RADIUS en la nube 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: distribuya en lugar de duplicar, automatice las decisiones de failover y pruebe 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.*