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

# 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 anfitrião e hoje estamos abordando uma das decisões de infraestrutura mais consequentes para qualquer organização que opera WiFi corporativo: a alta disponibilidade de servidor 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á as estruturas e os detalhes técnicos específicos de que você precisa 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. Sempre que um funcionário se conecta via 802.1X, ou um visitante se autentica através do seu Captive Portal, o RADIUS é o motor que verifica as credenciais e autoriza o acesso. É a espinha dorsal das implantações corporativas IEEE 802.1X e WPA3. E, ao contrário da maioria dos serviços de TI que degradam graciosamente 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 Dispositivo de Acesso à Rede — seu ponto de acesso, seu switch, seu gateway de VPN — detecta a falha e redireciona o tráfego para o secundário. Quanto tempo leva 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ê está olhando para um tempo máximo de detecção de failover de cerca de seis a doze segundos em uma implantação bem ajustada. Em um cenário de pior caso, com três servidores e temporizadores 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 meio de rotação round-robin ou por um balanceador de carga dedicado. Quando um nó falha, os nós restantes absorvem seu 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-check). Os benefícios de desempenho se multiplicam. Em um local de grande porte — pense em um estádio de 60.000 lugares ou em 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 ocorre um intervalo de sessão. 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 (sem estado) — o servidor verifica as credenciais em um diretório e retorna um Accept ou Reject. Mas a bilhetagem (accounting) do RADIUS é stateful (com estado): ela rastreia o início da sessão, atualizações provisórias e eventos de encerramento de sessão. Se você estiver usando a bilhetagem 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 implantado no mundo, integra-se com MySQL e MariaDB. Para implantações active-active, você tem duas opções principais: MySQL NDB Cluster, que fornece replicação multi-master síncrona 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 na 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 bilhetagem perdidos se o primário falhar antes que as alterações sejam replicadas. Permita-me abordar a questão da distribuição geográfica, pois isso é cada vez mais relevante para operadores multi-site. Se você administra uma rede de varejo com 200 lojas ou um grupo hoteleiro com propriedades em vários países, a questão não é apenas "como tornar meu servidor RADIUS redundante?" — é "onde meus servidores RADIUS devem estar localizados em relação aos meus pontos de acesso?" O backhaul do tráfego de autenticação de um site remoto para um data centre 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 gera uma sobrecarga operacional significativa — ou usar um serviço de cloud RADIUS com nós de borda distribuídos geograficamente. As plataformas de cloud RADIUS resolvem o problema de HA no nível arquitetônico. Em vez de você construir e gerenciar uma infraestrutura redundante, o provedor opera o RADIUS em múltiplas 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 temporizadores de repetição do NAS. Os compromissos de SLA dos provedores corporativos de cloud RADIUS são normalmente de 99,99% de uptime — o que representa menos de 53 minutos de inatividade por ano. Há também uma dimensão de conformidade importante 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 cloud RADIUS geralmente possuem certificações SOC 2 Type II e oferecem acordos de processamento de dados em conformidade com o 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 é fundamental 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 apresentar 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 das propriedades, causou uma interrupção completa do WiFi dos hóspedes durante uma grande conferência. A correção exigiu que um engenheiro fizesse acesso remoto e renovasse manualmente o certificado — um processo que levou 40 minutos enquanto os hóspedes não conseguiam se conectar. Após a migração para um serviço de cloud RADIUS 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% 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 significou que uma falha em um único nó — que antes causaria uma interrupção no site — tornou-se um não evento. Segundo cenário: um estádio esportivo 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 se 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. O rendimento da 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 do tipo "configurar e esquecer". As configurações divergem. Os certificados expiram no secundário enquanto o primário funciona perfeitamente. Quando o primário eventualmente falha e o secundário assume, ele também falha — 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 o 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 back-end 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 suporte 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 de 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 seu AD local sem expô-lo diretamente à internet. Este é 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 for limitada, o ativo-ativo é a arquitetura correta — e o RADIUS em nuvem é o caminho mais rápido para chegar lá sem precisar 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 guest WiFi — visite purple.ai. Até a próxima. --- *Fim do roteiro. Tempo aproximado de leitura a 150 palavras por minuto: 10 minutos.*