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

# Alta disponibilidad del servidor RADIUS: Activo-Activo vs. Activo-Pasivo ## Resumen técnico de Purple — Guion de podcast (~10 minutos) --- **PARTE 1 — INTRODUCCIÓN Y CONTEXTO (aprox. 1 minuto)** Bienvenido al resumen técnico de Purple. Soy su anfitrión, y hoy abordaremos una de las decisiones de infraestructura más trascendentales para cualquier organización que opere WiFi empresarial: la alta disponibilidad del servidor RADIUS. Si usted es un arquitecto de redes o director de TI responsable de la infraestructura de autenticación en un grupo hotelero, una cadena de tiendas de retail, un estadio o una instalación del sector público, este resumen 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 causan caídas de autenticación en el peor momento posible. Permítame contextualizar la 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 verifica las credenciales y autoriza el acceso. Es la columna vertebral de las implementaciones empresariales IEEE 802.1X y WPA3. Y a diferencia de la mayoría de los servicios de TI que se degradan gradualmente 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)** Comencemos con los fundamentos. RADIUS opera sobre UDP — típicamente el puerto 1812 para autenticación y el 1813 para contabilidad (accounting). La naturaleza sin estado de UDP es en realidad una ventaja para el diseño de alta disponibilidad: debido a que cada solicitud de autenticación es independiente, cualquier servidor en un clúster puede procesar cualquier solicitud sin necesidad de saber qué ocurrió antes. Esta es la propiedad arquitectónica que hace que las implementaciones activo-activo sean tan elegantes. Ahora bien, existen dos modelos principales de alta disponibilidad que debe comprender. **Activo-Pasivo** es el enfoque tradicional. Cuenta con un servidor RADIUS primario que maneja todo el tráfico de autenticación y un servidor secundario en modo de espera (standby), que recibe datos replicados pero no procesa solicitudes. Cuando el primario falla, el dispositivo de acceso a la red (NAS) — su punto de acceso, su switch, su gateway VPN — detecta la falla y redirige el tráfico al secundario. ¿Cuánto tiempo toma 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 (timeout) 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 failover es de aproximadamente seis a doce segundos en una implementación bien optimizada. En el peor de los casos, con tres servidores y temporizadores predeterminados, ese tiempo puede extenderse a dieciocho segundos. Para un huésped de hotel que intenta conectarse al hacer el check-in, o un asociado de retail que intenta procesar una transacción, esa es una ventana de espera muy molesta. **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 solicitudes de autenticación de forma simultánea. El tráfico se distribuye a lo largo del clúster ya sea mediante rotación round-robin o por un balanceador 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 existe una conmutación por error en el sentido tradicional: el balanceador de carga simplemente deja de enviar solicitudes al nodo con problemas, normalmente en un plazo de uno a dos segundos según los intervalos de verificación de estado. Los beneficios de rendimiento se multiplican. En un recinto grande —piense en un estadio de 60,000 asientos 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 cuando ocurre un receso de sesión. Un solo servidor RADIUS, incluso uno con buenas especificaciones, puede convertirse en un cuello de botella. Un clúster active-active escala horizontalmente: agregue otro nodo y agregará 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í misma es en gran medida sin estado: el servidor verifica las credenciales contra un directorio y devuelve un Aceptar o Rechazar. Pero el registro de conexiones (accounting) de RADIUS tiene estado: realiza un seguimiento del inicio de la sesión, las actualizaciones provisionales y los eventos de finalización de la sesión. Si utiliza el registro de conexiones para facturación, registro de cumplimiento o gestión de sesiones, necesita que esos datos sean consistentes 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 implementado en el mundo, se integra con MySQL y MariaDB. Para implementaciones active-active, tiene 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 falla del nodo. La replicación asíncrona —la réplica primaria estándar de MySQL— es más económica pero introduce un retraso de replicación que puede resultar en 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, porque esto es cada vez más relevante para los operadores de múltiples sitios. Si administra una cadena minorista con 200 tiendas, o un grupo hotelero con propiedades en varios países, la pregunta no es solo "¿cómo hago que mi servidor RADIUS sea redundante?", sino "¿dónde deberían ubicarse mis servidores RADIUS en relación con mis puntos de acceso?" El redireccionamiento (backhauling) del tráfico de autenticación desde un sitio remoto a un centro de datos central introduce latencia de WAN y un punto único de falla en el enlace WAN. Si ese enlace se cae, el sitio remoto no puede autenticar a nadie, sin importar qué tan redundante sea su clúster RADIUS central. La solución es implementar instancias locales de RADIUS en cada sitio —lo que genera una carga operativa significativa— o utilizar un servicio de cloud RADIUS con nodos perimetrales distribuidos geográficamente. Las plataformas de cloud RADIUS resuelven el problema de alta disponibilidad (HA) a nivel arquitectónico. En lugar de que usted construya y administre una infraestructura redundante, el proveedor opera RADIUS en múltiples zonas de disponibilidad y regiones. La conmutación por error (failover) entre nodos ocurre de forma automática, normalmente en menos de un segundo, porque es gestionada por el equilibrio de carga interno de la plataforma y no por 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 —eso es menos de 53 minutos de inactividad al año. También existe una dimensión de cumplimiento importante aquí. PCI DSS requiere controles de autenticación sólidos para los entornos de datos de titulares de tarjetas. El GDPR trata los registros de autenticación como datos personales, lo que exige 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 de GDPR con opciones de residencia de datos regionales. Las implementaciones locales (on-premise) le brindan un control total sobre la ubicación de los datos, lo cual es fundamental en entornos de atención médica 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 guiarlo 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 de tres ingenieros ejecutaba FreeRADIUS en máquinas virtuales en cada propiedad —45 instancias independientes que parchar, monitorear y mantener. Cuando un certificado TLS expiró en una propiedad, provocó una interrupción total del WiFi para huéspedes durante una conferencia importante. La solución requirió que un ingeniero se conectara de forma remota y renovara manualmente el certificado —un proceso que tomó 40 minutos mientras los huéspedes no podían conectarse. Después de 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 se volvió automática. Los tres ingenieros recuperaron aproximadamente el 40 por ciento de su tiempo que antes dedicaban a las operaciones de RADIUS. Más importante aún, la arquitectura activo-activo de la plataforma en múltiples regiones de la nube significó que la falla de un solo nodo —que antes habría causado una interrupción en el sitio— se convirtiera en un no-evento. 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 uno de reserva (hot standby). Durante una prueba de carga previa al evento, descubrieron que el servidor principal se estaba saturando 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 balanceo de carga 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 agregaron un tercer servidor para proporcionar margen de maniobra 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 que podía 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 al servidor RADIUS secundario como un respaldo de "configurar y olvidar". Las configuraciones se desvían. Los certificados caducan en el secundario mientras el principal funciona bien. Cuando el principal finalmente falla y el secundario toma el control, este también falla, por una razón completamente diferente. La solución es simple: pruebe su failover con regularidad, al menos trimestralmente, y trate a 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 su nodo de base de datos principal falla, puede perder registros de contabilidad de las sesiones que estaban activas en el momento de la falla. Para el cumplimiento de PCI DSS, esta es una brecha grave. Utilice replicación síncrona (Galera o NDB) para cualquier implementación donde la integridad de los datos de contabilidad sea un requisito de cumplimiento. --- **PARTE 4 — PREGUNTAS Y RESPUESTAS RÁPIDAS (aprox. 1 minuto)** Permítanme responder a 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 (HA)?" Dos servidores RADIUS con failover 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 usar un balanceador de carga de hardware para RADIUS?" Sí, pero RADIUS utiliza UDP y muchos balanceadores de carga están optimizados para TCP. Asegúrese de que su balanceador de carga admita el balanceo de carga UDP con verificaciones de estado. HAProxy Enterprise tiene un módulo UDP RADIUS dedicado. F5 BIG-IP lo maneja de forma nativa. "¿Cómo manejo la confianza de 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 de conexión (handshakes) EAP-TLS y PEAP; si los nodos presentan certificados diferentes, verá fallas de autenticación después del failover. "¿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 opera con menos de 500 usuarios concurrentes en un solo sitio con un equipo estable para administrar la infraestructura, el modelo 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 opera un patrimonio de múltiples sitios, un recinto de alta densidad o si el ancho de banda de su equipo es limitado, el modelo activo-activo es la arquitectura adecuada — y cloud RADIUS es el camino más rápido para lograrlo sin tener que construir la infraestructura usted mismo. Cualquiera que sea el modelo que elija, los principios son los mismos: distribuir en lugar de duplicar, automatizar las decisiones de failover y probar sus escenarios de falla antes de que ellos lo pongan a prueba a usted. Para obtener más información sobre cómo la plataforma de Purple maneja 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.*