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

# Alta Disponibilidade do Servidor RADIUS: Ativo-Ativo vs Ativo-Passivo ## Purple Technical Briefing — Guião do Podcast (~10 minutos) --- **PARTE 1 — INTRODUÇÃO E ENQUADRAMENTO (aprox. 1 minuto)** Bem-vindo ao Purple Technical Briefing. Sou o vosso anfitrião e hoje vamos abordar uma das decisões de infraestrutura mais consequentes para qualquer organização que opere WiFi empresarial: a alta disponibilidade do servidor RADIUS. Se é um arquiteto de rede ou diretor de TI responsável pela infraestrutura de autenticação num grupo hoteleiro, numa cadeia de retalho, num estádio ou numa instalação do setor público, este briefing dar-lhe-á os enquadramentos e os detalhes técnicos específicos de que necessita para tomar a decisão certa — e evitar os erros que causam falhas de autenticação no pior momento possível. Permitam-me enquadrar o cenário. O RADIUS — Remote Authentication Dial-In User Service — é o guardião da sua rede. Sempre que um colaborador se liga via 802.1X, ou um convidado se autentica através do seu captive portal, o RADIUS é o motor que verifica as credenciais e autoriza o acesso. É a espinha dorsal das implementações empresariais IEEE 802.1X e WPA3. E, ao contrário da maioria dos serviços de TI que se degradam de forma controlada 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 — ANÁLISE TÉCNICA DETALHADA (aprox. 5 minutos)** Comecemos pelos fundamentos. O RADIUS opera sobre UDP — tipicamente a porta 1812 para autenticação e 1813 para contabilização. A natureza sem estado do UDP é, na verdade, uma vantagem para o design de HA: como cada pedido de autenticação é autónomo, qualquer servidor num cluster pode processar qualquer pedido sem precisar de saber o que aconteceu antes. Esta é a propriedade arquitetural que torna as implementações ativo-ativo tão elegantes. Existem dois modelos principais de alta disponibilidade que precisa de compreender. **Ativo-Passivo** é a abordagem tradicional. Existe um servidor RADIUS primário que lida com todo o tráfego de autenticação e um servidor secundário em standby, que recebe dados replicados mas não processa pedidos. Quando o primário falha, o Network Access Device — o seu ponto de acesso, o seu switch, o seu gateway VPN — deteta a falha e redireciona o tráfego para o secundário. Quanto tempo demora essa transição (failover)? É aqui que os detalhes importam. O NAS envia um pedido RADIUS e aguarda. O tempo limite (timeout) padrão do pacote é tipicamente de dois segundos. Depois disso, tenta novamente — normalmente três tentativas por servidor. Com dois servidores configurados, o tempo máximo de deteção de failover é de cerca de seis a doze segundos numa implementação bem otimizada. No pior cenário, com três servidores e temporizadores padrão, esse tempo pode estender-se até aos dezoito segundos. Para um hóspede de hotel que tenta ligar-se no check-in, ou um funcionário de retalho que tenta processar uma transação, essa é uma janela dolorosa. **Ativo-Ativo** é a abordagem mais sofisticada e, para a maioria das implementações empresariais, é a escolha certa. Ambos — ou todos — os servidores RADIUS processam pedidos de autenticação em simultâneo. O tráfego é distribuído pelo cluster por rotação round-robin ou através de um balanceador de carga dedicado. Quando um nó falha, os nós restantes absorvem o seu tráfego imediatamente. Não existe atraso na deteção de failover porque não há failover no sentido tradicional: o balanceador de carga simplesmente deixa de enviar pedidos para o nó com problemas, normalmente no espaço de um a dois segundos, com base nos intervalos de verificação de estado. Os benefícios de desempenho acumulam-se. Num local de grande dimensão — pense num estádio com capacidade para 60.000 pessoas ou num centro de conferências que acolhe uma grande exposição — pode registar milhares de pedidos de autenticação em simultâneo quando as portas se abrem ou quando ocorre um intervalo entre sessões. Um único servidor RADIUS, mesmo com boas especificações, pode tornar-se um gargalo. Um cluster ativo-ativo escala horizontalmente: adicione outro nó e adicionará capacidade proporcional. Agora, falemos sobre a camada de base de dados, porque é aqui que muitas implementações se deparam com problemas. A autenticação RADIUS em si é maioritariamente stateless — o servidor verifica as credenciais num diretório e devolve um Aceitar ou Rejeitar. Mas a monitorização (accounting) do RADIUS é stateful: acompanha o início da sessão, atualizações intermédias e eventos de fim de sessão. Se utiliza a monitorização para faturação, registo de conformidade ou gestão de sessões, precisa que esses dados sejam consistentes em todos os nós. A abordagem padrão consiste em apoiar o seu cluster RADIUS numa base de dados replicada. O FreeRADIUS, o servidor RADIUS de código aberto mais implementado no mundo, integra-se com o MySQL e o MariaDB. Para implementações ativo-ativo, 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 uma replicação síncrona semelhante com uma gestão operacional ligeiramente mais simples. Ambas eliminam o risco de perda de dados em caso de falha do nó. A replicação assíncrona — primária-réplica padrão do MySQL — é mais barata, mas introduz um atraso de replicação que pode resultar na perda de registos de monitorização se a primária falhar antes de as alterações serem replicadas. Deixe-me abordar a questão da distribuição geográfica, porque esta é cada vez mais relevante para operadores multi-site. Se gere uma cadeia de retalho com 200 lojas, ou um grupo hoteleiro com propriedades em vários países, a questão não é apenas "como torno o meu servidor RADIUS redundante?" — é "onde devem os meus servidores RADIUS estar localizados em relação aos meus pontos de acesso?" O retorno (backhauling) do tráfego de autenticação de um site remoto para um centro de dados central introduz latência de WAN e um ponto único de falha no link de WAN. Se esse link falhar, o site remoto não conseguirá autenticar ninguém, independentemente de quão redundante seja o seu cluster RADIUS central. A solução passa por implementar instâncias RADIUS locais em cada site — o que cria uma sobrecarga operacional significativa — ou utilizar um serviço de cloud RADIUS com nós de extremidade (edge) distribuídos geograficamente. As plataformas de cloud RADIUS resolvem o problema de HA ao nível da arquitetura. Em vez de construir e gerir uma infraestrutura redundante, o fornecedor opera o RADIUS em múltiplas zonas de disponibilidade e regiões. O failover entre nós ocorre de forma automática, normalmente em menos de um segundo, porque é gerido pelo balanceamento de carga interno da plataforma e não pelos temporizadores de nova tentativa do NAS. Os compromissos de SLA dos fornecedores de cloud RADIUS empresariais são tipicamente de 99,99% de tempo de atividade (uptime) — o que representa menos de 53 minutos de inatividade por ano. Existe também aqui uma dimensão importante de conformidade. O PCI DSS exige controlos de autenticação fortes para ambientes de dados de titulares de cartões. O GDPR trata os registos de autenticação como dados pessoais, exigindo um tratamento adequado e controlos de residência de dados. Os fornecedores de cloud RADIUS detêm tipicamente 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 implementações locais (on-premise) dão-lhe total controlo sobre a localização dos dados, o que é relevante em ambientes de saúde sob estruturas de governação de dados do NHS, ou em instalações governamentais com requisitos de soberania de dados. --- **PARTE 3 — RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS (aprox. 2 minutos)** Permita-me apresentar-lhe dois cenários do mundo real que ilustram estes princípios na prática. Primeiro: um grupo hoteleiro europeu com 45 propriedades em seis países. A sua equipa de TI de três engenheiros executava o FreeRADIUS em máquinas virtuais em cada propriedade — 45 instâncias separadas para atualizar, monitorizar e manter. Quando um certificado TLS expirou numa propriedade, causou uma interrupção total do WiFi dos hóspedes durante uma grande conferência. A correção exigiu que um engenheiro acedesse remotamente para renovar manualmente o certificado — um processo que demorou 40 minutos enquanto os hóspedes não conseguiam ligar-se. Após a migração para um serviço de cloud RADIUS com gestão centralizada de políticas, a equipa eliminou completamente a manutenção por site. A rotação de certificados passou a ser automática. Os três engenheiros recuperaram cerca de 40 por cento do tempo anteriormente despendido em operações de RADIUS. Mais importante ainda, a arquitetura ativo-ativo da plataforma em múltiplas regiões de cloud fez com que a falha de um único nó — que anteriormente teria causado uma interrupção no site — passasse a ser um não-evento. Segundo cenário: um estádio desportivo nacional que acolhe 60.000 adeptos para um grande evento. A equipa de rede tinha implementado uma configuração RADIUS ativo-passivo com um servidor primário e um standby ativo. Durante um teste de carga pré-evento, descobriram que o servidor primário estava a ficar saturado durante o pico de autenticação quando as portas abriam — processando 8.000 pedidos de autenticação por minuto. O secundário passivo estava inativo enquanto o primário tinha dificuldades. A solução foi reconfigurar os dispositivos NAS para utilizarem o balanceamento de carga round-robin em ambos os servidores, convertendo eficazmente a implementação para ativa-ativa. O rendimento de autenticação duplicou imediatamente. Adicionaram também um terceiro servidor para fornecer margem para o pico de carga e configuraram a replicação do Galera Cluster para a base de dados de accounting. O resultado foi uma implementação que conseguia absorver a perda de qualquer nó individual sem qualquer impacto visível para o utilizador. Agora, as armadilhas. O erro mais comum é tratar o servidor RADIUS secundário como uma cópia de segurança de configurar e esquecer. As configurações divergem. Os certificados expiram no secundário enquanto o primário está a funcionar bem. Quando o primário eventualmente falha e o secundário assume o controlo, este também falha — por uma razão completamente diferente. A solução é simples: teste a sua tolerância a falhas regularmente, pelo menos trimestralmente, e trate ambos os nós como sistemas de produção. A segunda armadilha é negligenciar o atraso de replicação da base de dados. Se estiver a utilizar replicação assíncrona e o seu nó de base de dados primário falhar, poderá perder registos de accounting de sessões que estavam ativas no momento da falha. Para a conformidade com o PCI DSS, esta é uma lacuna grave. Utilize replicação síncrona — Galera ou NDB — para qualquer implementação em que a integridade dos dados de accounting seja um requisito de conformidade. --- **PARTE 4 — PERGUNTAS E RESPOSTAS RÁPIDAS (aprox. 1 minuto)** Deixe-me responder às perguntas que ouço com mais frequência por parte 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 partilhado e um backend de base de dados replicado. Esse é o seu limite mínimo. Para qualquer valor acima de 500 utilizadores concorrentes, mude para ativo-ativo. "Posso utilizar um balanceador de carga de hardware para RADIUS?" Sim, mas o RADIUS utiliza UDP e muitos balanceadores de carga estão otimizados para TCP. Certifique-se de que o seu balanceador de carga suporta o balanceamento de carga UDP com verificações de estado. O HAProxy Enterprise possui um módulo UDP RADIUS dedicado. O F5 BIG-IP lida com isso nativamente. "Como posso gerir a confiança de certificados EAP num cluster de 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, verá falhas de autenticação após o failover. "O RADIUS na nuvem funciona com o Active Directory local?" Sim, através de um conetor leve ou proxy LDAP que consulta o seu AD local sem o expor 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 concluir com as principais decisões que precisa de tomar. Se estiver a gerir menos de 500 utilizadores simultâneos num único local com uma equipa estável para gerir a infraestrutura, o modelo ativo-passivo com um procedimento de failover bem testado é uma escolha defensável. Mantenha-o simples, teste-o regularmente e utilize replicação síncrona de base de dados. Se estiver a gerir um património multi-local, um espaço de alta densidade ou se a largura de banda da sua equipa for limitada, o modelo ativo-ativo é a arquitetura correta — e o cloud RADIUS é o caminho mais rápido para lá chegar sem construir a infraestrutura por si mesmo. Independentemente do modelo que escolher, os princípios são os mesmos: distribuir em vez de duplicar, automatizar as decisões de failover e testar os seus cenários de falha antes que estes o testem a si. Para saber mais sobre como a plataforma da Purple lida com a autenticação RADIUS à escala — incluindo a integração com 802.1X, WPA3 enterprise e portais de WiFi de convidados — visite purple.ai. Até à próxima. --- *Fim do guião. Tempo aproximado de leitura a 150 palavras por minuto: 10 minutos.*