Alta Disponibilidade de Servidor RADIUS: Ativo-Ativo vs Ativo-Passivo

# Alta Disponibilidade de Servidor RADIUS: Ativo-Ativo vs Ativo-Passivo ## Purple Technical Briefing - Roteiro de Podcast (~10 minutos) --- **PARTE 1 - INTRODUÇÃO E CONTEXTO (aprox. 1 minuto)** Bem-vindo ao Purple Technical Briefing. Eu sou o seu host e hoje vamos abordar uma das decisões de infraestrutura mais importantes para qualquer organização que opera WiFi corporativo: a alta disponibilidade de servidores RADIUS. Se você é um arquiteto de rede ou diretor de TI responsável pela infraestrutura de autenticação em um grupo hoteleiro, uma rede de varejo, um estádio ou uma instalação do setor público, este briefing fornecerá os frameworks e os detalhes técnicos específicos necessários para tomar a decisão certa - e evitar os erros que causam interrupções de autenticação no pior momento possível. Deixe-me contextualizar. O RADIUS - Remote Authentication Dial-In User Service - é o guardião da sua rede. Cada vez que um funcionário se conecta via 802.1X, ou um visitante se autentica através do seu Captive Portal, o RADIUS é o mecanismo que verifica as credenciais e autoriza o acesso. É a espinha dorsal das implantações corporativas de IEEE 802.1X e WPA3. E ao contrário da maioria dos serviços de TI que degradam gradualmente quando falham, o RADIUS é binário: ou funciona, ou ninguém entra na rede. Essa assimetria é o que torna a alta disponibilidade tão crítica. --- **PARTE 2 - MERGULHO TÉCNICO PROFUNDO (aprox. 5 minutos)** Vamos começar com os fundamentos. O RADIUS opera sobre UDP - normalmente a porta 1812 para autenticação e 1813 para tarifação (accounting). A natureza sem estado (stateless) do UDP é na verdade uma vantagem para o design de HA: como cada solicitação de autenticação é autocontida, qualquer servidor em um cluster pode processar qualquer solicitação sem precisar saber o que aconteceu antes. Esta é a propriedade arquitetônica que torna as implantações ativo-ativo tão elegantes. Agora, existem dois modelos principais de alta disponibilidade que você precisa entender. **Ativo-Passivo** é a abordagem tradicional. Você tem um servidor RADIUS primário processando todo o tráfego de autenticação e um servidor secundário em modo de espera (standby), recebendo dados replicados, mas sem processar solicitações. Quando o primário falha, o Network Access Device - seu ponto de acesso, seu switch, seu gateway VPN - detecta a falha e redireciona o tráfego para o secundário. Quanto tempo demora esse failover? É aqui que os detalhes importam. O NAS envia uma solicitação RADIUS e aguarda. O tempo limite padrão do pacote (timeout) é normalmente de dois segundos. Depois disso, ele tenta novamente - geralmente três tentativas por servidor. Com dois servidores configurados, você verá um tempo máximo de detecção de failover de cerca de seis a doze segundos em uma implantação bem ajustada. Em um pior cenário com três servidores e cronômetros padrão, isso pode se estender para dezoito segundos. Para um hóspede de hotel tentando se conectar no check-in, ou um associado de varejo tentando processar uma transação, essa é uma janela dolorosa. **Active-Active** é a abordagem mais sofisticada e, para a maioria das implantações corporativas, é a escolha certa. Ambos - ou todos - os servidores RADIUS processam solicitações de autenticação simultaneamente. O tráfego é distribuído pelo cluster por rotação round-robin ou por um balanceador de carga dedicado. Quando um nó falha, os nós restantes absorvem o tráfego imediatamente. Não há atraso na detecção de failover porque não há failover no sentido tradicional: o balanceador de carga simplesmente para de enviar solicitações para o nó instável, normalmente dentro de um a dois segundos com base nos intervalos de verificação de integridade (health checks). Os benefícios de desempenho se acumulam. Em um local de grande porte - como um estádio de 60.000 lugares ou um centro de convenções que sedia uma grande exposição - você pode ver milhares de solicitações de autenticação simultâneas quando as portas se abrem ou quando ocorre um intervalo entre as sessões. Um único servidor RADIUS, mesmo que bem especificado, pode se tornar um gargalo. Um cluster active-active escala horizontalmente: adicione outro nó e você adicionará capacidade proporcional. Agora, vamos falar sobre a camada de banco de dados, porque é aqui que muitas implantações enfrentam problemas. A autenticação RADIUS em si é amplamente stateless - o servidor verifica as credenciais em um diretório e retorna um Aceitar ou Rejeitar. Mas a tarifação RADIUS é stateful: ela rastreia o início da sessão, atualizações intermediárias e eventos de encerramento de sessão. Se você estiver usando a tarifação para faturamento, registro de conformidade ou gerenciamento de sessão, precisará que esses dados sejam consistentes em todos os nós. A abordagem padrão é dar suporte ao seu cluster RADIUS com um banco de dados replicado. O FreeRADIUS, o servidor RADIUS de código aberto mais amplamente implantado no mundo, se integra ao MySQL e ao MariaDB. Para implantações active-active, você tem duas opções principais: MySQL NDB Cluster, que fornece replicação síncrona multi-master com failover em menos de um segundo, ou Galera Cluster, que oferece replicação síncrona semelhante com gerenciamento operacional um pouco mais simples. Ambos eliminam o risco de perda de dados em caso de falha do nó. A replicação assíncrona - o padrão MySQL primary-replica - é mais barata, mas introduz um atraso de replicação que pode resultar em registros de tarifação perdidos se o principal falhar antes que as alterações sejam replicadas. Deixe-me abordar a questão da distribuição geográfica, porque isso é cada vez mais relevante para operadoras de múltiplos locais. Se você gerencia uma rede de varejo com 200 lojas ou um grupo hoteleiro com propriedades em vários países, a pergunta não é apenas "como torno meu servidor RADIUS redundante?" - é "onde meus servidores RADIUS devem estar localizados em relação aos meus pontos de acesso?" O transporte de tráfego de autenticação de um site remoto para um data center central introduz latência de WAN e um ponto único de falha no link de WAN. Se esse link cair, o site remoto não conseguirá autenticar ninguém, independentemente de quão redundante seja o seu cluster RADIUS central. A solução é implantar instâncias locais de RADIUS em cada site - o que cria uma sobrecarga operacional significativa - ou usar um serviço de RADIUS em nuvem com nós de borda distribuídos geograficamente. As plataformas de RADIUS em nuvem resolvem o problema de alta disponibilidade no nível arquitetônico. Em vez de você criar e gerenciar uma infraestrutura redundante, o provedor opera o RADIUS em várias zonas de disponibilidade e regiões. O failover entre os nós ocorre automaticamente, normalmente em menos de um segundo, porque é gerenciado pelo balanceamento de carga interno da plataforma, e não pelos cronômetros de nova tentativa do NAS. Os compromissos de SLA dos provedores corporativos de RADIUS em nuvem são tipicamente de 99,99% de tempo de atividade - o que representa menos de 53 minutos de inatividade por ano. Há também uma dimensão importante de conformidade aqui. O PCI-DSS exige controles de autenticação fortes para ambientes de dados de portadores de cartão. O GDPR trata os logs de autenticação como dados pessoais, exigindo manuseio adequado e controles de residência de dados. Os provedores de RADIUS em nuvem geralmente possuem certificações SOC 2 Tipo II e oferecem acordos de processamento de dados do GDPR com opções regionais de residência de dados. As implantações locais oferecem controle total sobre a localização dos dados, o que é importante em ambientes de saúde sob estruturas de governança de dados do NHS, ou em instalações governamentais com requisitos de soberania de dados. - **PARTE 3 - RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS (aprox. 2 minutos)** Deixe-me orientar você por dois cenários do mundo real que ilustram esses princípios na prática. Primeiro: um grupo hoteleiro europeu com 45 propriedades em seis países. Sua equipe de TI de três engenheiros executava o FreeRADIUS em máquinas virtuais em cada propriedade - 45 instâncias separadas para aplicar patches, monitorar e manter. Quando um certificado TLS expirou em uma propriedade, causou uma interrupção completa no WiFi de convidados durante uma grande conferência. A correção exigiu que um engenheiro se conectasse remotamente e renovasse o certificado manualmente - um processo que levou 40 minutos enquanto os convidados não conseguiam se conectar. Após a migração para um serviço de RADIUS em nuvem com gerenciamento centralizado de políticas, a equipe eliminou totalmente a manutenção por site. A rotação de certificados tornou-se automática. Os três engenheiros recuperaram cerca de 40 por cento do tempo anteriormente gasto em operações de RADIUS. Mais importante ainda, a arquitetura ativo-ativo da plataforma em várias regiões de nuvem fez com que uma falha em um único nó - que antes teria causado uma interrupção no site - se tornasse um não evento. Segundo cenário: um estádio de esportes nacional recebendo 60.000 torcedores para um grande evento. A equipe de rede havia implantado uma configuração RADIUS ativo-passivo com um servidor primário e um standby ativo. Durante um teste de carga pré-evento, eles descobriram que o servidor primário estava ficando saturado durante o pico de autenticação quando os portões abriam - processando 8.000 solicitações de autenticação por minuto. O secundário passivo estava ocioso enquanto o primário enfrentava dificuldades. A solução foi reconfigurar os dispositivos NAS para usar o balanceamento de carga round-robin em ambos os servidores, convertendo efetivamente a implantação para ativo-ativo. A taxa de transferência de autenticação dobrou imediatamente. Eles também adicionaram um terceiro servidor para fornecer margem para a carga de pico e configuraram a replicação do Galera Cluster para o banco de dados de tarifação. O resultado foi uma implantação que poderia absorver a perda de qualquer nó único sem qualquer impacto visível para o usuário. Agora, as armadilhas. O erro mais comum é tratar o servidor RADIUS secundário como um backup de tipo "definir e esquecer". As configurações divergem. Os certificados expiram no secundário enquanto o primário está funcionando perfeitamente. Quando o primário eventualmente falha e o secundário assume o controle, ele falha também - por um motivo completamente diferente. A correção é simples: teste seu failover regularmente, pelo menos trimestralmente, e trate ambos os nós como sistemas de produção. A segunda armadilha é negligenciar o atraso de replicação do banco de dados. Se você estiver usando replicação assíncrona e seu nó de banco de dados primário falhar, poderá perder registros de tarifação de sessões que estavam ativas no momento da falha. Para a conformidade com PCI-DSS, essa é uma lacuna grave. Use replicação síncrona - Galera ou NDB - para qualquer implantação onde a integridade dos dados de tarifação seja um requisito de conformidade. - **PARTE 4 - PERGUNTAS E RESPOSTAS RÁPIDAS (aprox. 1 minuto)** Deixe-me responder às perguntas que mais ouço dos arquitetos de rede. "Qual é a configuração mínima viável de HA?" Dois servidores RADIUS com failover ativo-passivo, sincronização de segredo compartilhado e um backend de banco de dados replicado. Esse é o seu limite mínimo. Para qualquer cenário acima de 500 usuários simultâneos, mude para ativo-ativo. "Posso usar um balanceador de carga de hardware para RADIUS?" Sim, mas o RADIUS usa UDP, e muitos balanceadores de carga são otimizados para TCP. Certifique-se de que seu balanceador de carga ofereça suporte a balanceamento de carga UDP com verificações de integridade. O HAProxy Enterprise possui um módulo UDP RADIUS dedicado. O F5 BIG-IP lida com isso nativamente. "Como faço para lidar com a confiança do certificado EAP em um cluster HA?" Todos os nós devem apresentar o mesmo certificado de servidor ou, no mínimo, certificados da mesma cadeia de CA. Os clientes validam o certificado do servidor durante os handshakes EAP-TLS e PEAP - se os nós apresentarem certificados diferentes, você verá falhas de autenticação após o failover. "O RADIUS em nuvem funciona com o Active Directory local?" Sim, por meio de um conector leve ou proxy LDAP que consulta o seu AD local sem expô-lo diretamente à internet. Esse é o padrão de integração padrão para ambientes híbridos. - **PARTE 5 - RESUMO E PRÓXIMOS PASSOS (aprox. 1 minuto)** Deixe-me encerrar com as principais decisões que você precisa tomar. Se você estiver operando com menos de 500 usuários simultâneos em um único local com uma equipe estável para gerenciar a infraestrutura, o modelo ativo-passivo com um procedimento de failover bem testado é uma escolha defensável. Mantenha as coisas simples, teste regularmente e use replicação síncrona de banco de dados. Se você estiver operando uma propriedade com vários locais, um local de alta densidade ou se a largura de banda da sua equipe estiver limitada, o ativo-ativo é a arquitetura certa - e o RADIUS em nuvem é o caminho mais rápido para chegar lá sem construir a infraestrutura por conta própria. Qualquer que seja o modelo escolhido, os princípios são os mesmos: distribuir em vez de duplicar, automatizar as decisões de failover e testar seus cenários de falha antes que eles testem você. Para saber mais sobre como a plataforma da Purple lida com autenticação RADIUS em escala - incluindo integração com 802.1X, WPA3 enterprise e portais de WiFi para visitantes - visite purple.ai. Até a próxima. --- *Fim do roteiro. Tempo aproximado de leitura a 150 palavras por minuto: 10 minutos.*