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

# Alta disponibilidad del servidor RADIUS: Activo-Activo frente a 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 importantes 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 el detalle técnico específico que necesita para tomar la decisión correcta y evitar los errores que causan interrupciones de autenticación en el peor momento posible. Permítame contextualizar. 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 de IEEE 802.1X y WPA3. Y a diferencia de la mayoría de los servicios de TI que se degradan de forma gradual cuando fallan, RADIUS es binario: o funciona, o nadie puede entrar 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 la autenticación y el 1813 para la contabilidad. La naturaleza sin estado de UDP es en realidad una ventaja para el diseño de HA: debido a que cada solicitud de autenticación es independiente, cualquier servidor de 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 gestiona todo el tráfico de autenticación y un servidor secundario en estado de espera, que recibe los 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 la falla y redirige el tráfico al secundario. ¿Cuánto tiempo tarda esa conmutación por error? Aquí es donde los detalles importan. El NAS envía una solicitud de 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 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 registro de entrada, 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 por detección de failover porque no hay un failover 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 convenciones que alberga una gran exposición - puede ver miles de solicitudes de autenticación simultáneas cuando se abren las puertas o se produce un receso. Un solo servidor RADIUS, incluso uno con buenas especificaciones, puede convertirse en un cuello de botella. Un clúster active-active se 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í es en gran medida sin estado (stateless) - el servidor verifica las credenciales con un directorio y devuelve un Accept o Reject. Pero el registro de conexiones (accounting) de RADIUS tiene estado (stateful): realiza el seguimiento del inicio de sesión, las actualizaciones intermedias y los eventos de finalización de sesión. Si utiliza el accounting 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 del 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 failover 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 ante la falla de un nodo. La replicación asíncrona - la estándar de réplica primaria de MySQL - es más barata pero introduce un retraso de replicación que puede resultar en la pérdida de registros de accounting 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 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 de la WAN. Si ese enlace se cae, el sitio remoto no puede autenticar a nadie, sin importar qué tan redundante sea su clúster de RADIUS central. La solución consiste en implementar instancias locales de RADIUS en cada sitio - lo que genera una carga operativa significativa - o en utilizar un servicio de cloud RADIUS con nodos perimetrales distribuidos geográficamente. Las plataformas de cloud RADIUS resuelven el problema de alta disponibilidad a nivel arquitectónico. En lugar de que usted construya y administre una infraestructura redundante, el proveedor opera RADIUS a través de múltiples zonas de disponibilidad y regiones. La conmutación por error entre nodos ocurre de forma automática, generalmente en menos de un segundo, porque es gestionada por el balanceo de carga interno de la plataforma en lugar de los temporizadores de reintento del NAS. Los compromisos de SLA de los proveedores de cloud RADIUS empresariales suelen ser de 99.99% de tiempo de actividad - eso es menos de 53 minutos de inactividad al año. Aquí también hay una dimensión de cumplimiento importante. 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 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 de GDPR con opciones de residencia de datos regionales. Las implementaciones on-premise le brindan un control total sobre la ubicación de los datos, lo cual es importante 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 para parchar, monitorear y mantener. Cuando expiró un certificado TLS en una propiedad, provocó una interrupción completa del WiFi para invitados 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. Lo más importante es que la arquitectura activo-activo de la plataforma a través de múltiples regiones de la nube significó que una falla en un solo nodo - que antes habría causado una caída del 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 respaldo en caliente. 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 servidor secundario pasivo permanecía inactivo mientras el principal tenía dificultades. La solución fue reconfigurar los dispositivos NAS para utilizar un balanceo de carga de tipo round-robin en ambos servidores, convirtiendo de manera efectiva la implementación a activo-activo. El rendimiento de la autenticación se duplicó de inmediato. También agregaron un tercer servidor para proporcionar un margen de maniobra para la carga pico 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 tipo "configurar y olvidar". Las configuraciones varían. Los certificados caducan en el servidor secundario mientras el principal funciona correctamente. 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 los 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í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 failover activo-pasivo, sincronización de secreto compartido y un backend de base de datos replicado. Ese es su punto de partida. 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 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 de conexión EAP-TLS y PEAP. Si los nodos presentan certificados diferentes, experimentará fallas de autenticación después del failover. "¿Funciona cloud RADIUS con un 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 simultáneos en una sola sede y cuenta con un equipo estable para administrar la infraestructura, un esquema activo - pasivo con un procedimiento de failover bien probado es una opción justificable. Manténgalo simple, pruébelo regularmente y utilice replicación síncrona de bases de datos. Si gestiona un patrimonio multisede, un recinto de alta densidad o si el ancho de banda de su equipo es limitado, activo - activo es la arquitectura adecuada; y 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 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.*