Servidor RADIUS Redundante para PPPoE: Guia Completo

Visão Geral da Redundância RADIUS

Para provedores de internet (ISPs) que operam redes PPPoE, a disponibilidade do serviço de autenticação é o coração da operação. O protocolo RADIUS (Remote Authentication Dial-In User Service) atua como o validador de credenciais para cada conexão iniciada pelo cliente. Em uma arquitetura padrão, se o servidor RADIUS falha ou fica indisponível devido a uma sobrecarga ou falha de hardware, o concentrador PPPoE (BRAS/BNG) não consegue validar os usuários, resultando na queda massiva de todos os clientes conectados e na impossibilidade de novas conexões.

A implementação de uma redundância RADIUS visa eliminar esse ponto único de falha através de uma arquitetura de cluster. Em vez de um servidor isolado, configuramos um conjunto de instâncias do FreeRADIUS que operam de forma coordenada. O conceito fundamental não é apenas ter dois servidores, mas garantir que o cliente (o roteador de borda ou BNG) e o banco de dados estejam em sincronia. Quando o primeiro servidor (Primary) falha, o segundo servidor (Secondary) assume o processamento das requisições de Access-Request sem que o usuário final perceba a interrupção do tráfego de dados.

Existem duas camadas críticas de redundância que trabalhamos neste tutorial:

• Redundância de Serviço (Control Plane): Configuração do roteador de borda para enviar pacotes RADIUS para múltiplos endereços IP. Se o primeiro IP não responder dentro de um timeout definido, o roteador tenta o próximo da lista.
• Redundância de Dados (Data Plane): Utilização de um banco de dados MySQL/MariaDB replicado. Não adianta o serviço RADIUS estar ativo se o segundo servidor não possuir a mesma base de usuários, planos e limites de banda que o primeiro.

Nesta arquitetura, utilizaremos o modelo de Master-Slave para o banco de dados e o protocolo RADIUS para a comunicação entre o NAS (Network Access Server) e os servidores de autenticação. O objetivo final é alcançar um estado de Alta Disponibilidade (HA), onde a manutenção de um dos nós do cluster pode ser realizada sem impacto no churn de clientes ou na experiência de navegação do usuário final.

Conceitos de Alta Disponibilidade PPPoE

A implementação de alta disponibilidade (HA) em ambientes de provedor de internet (ISP) visa eliminar o ponto único de falha (Single Point of Failure - SPOF) na camada de autenticação. Em uma arquitetura PPPoE convencional, o concentrador (BRAS/BNG) consulta um servidor RADIUS para validar credenciais e aplicar políticas de banda. Se este servidor ficar indisponível, todos os clientes conectados enfrentarão quedas de sessão ou impossibilidade de novas reconexões, impactando diretamente o SLA do provedor.

Para garantir a continuidade, utilizamos o conceito de cluster de autenticação. Este modelo baseia-se em dois pilares fundamentais: a redundância do serviço de processamento e a consistência do estado da base de dados. No nível de serviço, o FreeRADIUS deve operar em um arranjo onde múltiplos nós são capazes de responder a requisições Access-Request de forma independente. No nível de rede, o concentrador PPPoE deve ser configurado com uma lista de servidores RADIUS (primário e secundário), permitindo o failover automático caso o primeiro nó não responda dentro do timeout definido.

A complexidade técnica reside na sincronização de dados. Não basta ter dois servidores FreeRADIUS; é imperativo que ambos enxerguem a mesma base de usuários, planos e status de conexão. Isso é geralmente alcançado através de um cluster de banco de dados (como MySQL/MariaDB com Galera Cluster) ou através de mecanismos de replicação de banco de dados. Sem a sincronia do backend, um cliente autenticado no Nó A poderá ter sua sessão derrubada ao ser redirecionado para o Nó B, caso as informações de Accounting não tenham sido replicadas em tempo real.

Outro conceito crítico é o balanceamento de carga e a gestão de latência. Em arquiteturas avançadas, utiliza-se um Load Balancer (como HAProxy ou Keepalived) à frente do cluster RADIUS. O concentrador PPPoE aponta para um único IP Virtual (VIP). O Load Balancer distribui as requisições entre os nós ativos, garantindo que, se um servidor RADIUS sofrer uma sobrecarga de CPU ou falha de processo, o tráfego seja redirecionado instantaneamente para um nó saudável, mantendo a transparência da falha para o usuário final.

Pré-requisitos para o Cluster FreeRADIUS

Para implementar uma arquitetura de alta disponibilidade para autenticação PPPoE, não basta apenas instalar o software em dois servidores. É necessário garantir que a camada de dados, a camada de rede e a camada de aplicação estejam perfeitamente sincronizadas para evitar que o cliente perca a conexão durante um failover. Abaixo, listamos os requisitos técnicos essenciais para este projeto.

• Servidores Linux Ubuntu ou Debian: Recomenda-se a versão 22.04 LTS ou superior para ambos os nós do cluster, garantindo suporte a bibliotecas modernas de criptografia e estabilidade de kernel.
• Instância de Banco de Dados Centralizada ou Replicada: Um servidor MySQL ou MariaDB operando em modo Master-Slave (Replicação) é indispensável para que o segundo nó do FreeRADIUS tenha acesso imediato aos mesmos dados de usuários e planos de acesso.
• Acesso Root ou Sudo: É obrigatório possuir privilégios administrativos em todos os servidores envolvidos para manipulação de arquivos de configuração sensíveis e gerenciamento de serviços do sistema.
• Configuração de IP Estático: Cada nó do cluster e o servidor de banco de dados devem possuir endereços IP fixos e imutáveis para evitar que o NAS (Network Access Server) perca o destino das requisições RADIUS.
• Conectividade de Baixa Latência: Os servidores devem estar interconectados via rede local ou VPN de alta performance, pois o atraso na sincronização do banco de dados pode causar timeouts de autenticação no PPPoE.
• Pacotes de Dependências Base: É necessário que o ambiente possua os pacotes mysql-client, libmysqlclient-dev e freeradius-mysql instalados para permitir a comunicação nativa entre o protocolo RADIUS e o motor de banco de dados.
• Firewall Configurado (Portas UDP 1812 e 1813): O tráfego de autenticação e contabilidade deve estar liberado nas portas UDP 1812 (Authentication) e UDP 1813 (Accounting), além da porta 3306 para a comunicação entre os nós e o banco de dados.

Preparação do Ambiente e Instalação

Para estabelecer um cluster funcional, iniciaremos a preparação dos nós que comporão a arquitetura. É fundamental que ambos os servidores (Primário e Secundário) possuam uma distribuição baseada em Debian ou Ubuntu para garantir a paridade de pacotes e bibliotecas durante o processo de replicação.

1. Atualize os repositórios do sistema para garantir que as dependências de compilação e os binários do FreeRADIUS estejam nas versões mais recentes disponíveis no seu mirror.

   
   sudo apt update && sudo apt upgrade -y
   

   O comando apt update atualiza a lista de pacotes, enquanto o upgrade aplica as atualizações de segurança pendentes.

2. Instale o pacote principal do FreeRADIUS junto com o módulo de integração para MySQL (MariaDB). Esta etapa é vital para que o servidor consiga consultar as tabelas de usuários e perfis de conexão no banco de dados centralizado.

   
   sudo apt install freeradius freeradius-mysql freeradius-utils mariadb-client -y
   

   A flag -y responde automaticamente "sim" para todas as confirmações de instalação, agilizando o processo em automações.

3. Configure o suporte ao módulo SQL no arquivo de configuração do FreeRADIUS. Você deve editar o arquivo sql.conf para apontar para o servidor de banco de dados que servirá como Single Source of Truth para o cluster.

   
   sudo nano /etc/freeradius/3.0/mods-available/sql
   

   Dentro deste arquivo, localize a seção [sql] e ajuste os parâmetros server, login e password com as credenciais do seu banco de dados central.

4. Habilite o módulo SQL no ambiente de execução do FreeRADIUS através da criação de um link simbólico. Isso instrui o serviço a carregar as configurações do módulo durante o boot.

   
   sudo ln -s /etc/freeradius/3.0/mods-available/sql /etc/freradius/3.0/mods-enabled/sql
   

   O comando ln -s cria um link simbólico, garantindo que qualquer alteração feita em mods-available seja refletida instantaneamente no diretório de módulos ativos.

5. Verifique a integridade da instalação executando o FreeRADIUS em modo de depuração (debug mode). Este passo é crucial para identificar erros de sintaxe ou falhas de conexão com o banco de dados antes de colocar o serviço em produção.

   
   sudo freeradius -X
   

   A flag -X inicia o processo em primeiro plano e exibe logs detalhados de cada etapa da autenticação, permitindo visualizar se o módulo SQL foi carregado com sucesso.

Configuração do Cluster FreeRADIUS

Para que o cluster funcione, os nós devem ser configurados para consultar o mesmo backend de dados e responder aos mesmos NAS (Network Access Servers). A redundância não reside no serviço em si, mas na capacidade de múltiplos processos FreeRADIUS operarem de forma idêntica.

1. Configuração do módulo SQL. Em ambos os servidores, você deve editar o arquivo de configuração do módulo SQL para garantir que o driver e os parâmetros de conexão apontem para o cluster de banco de dados centralizado.

   nano /etc/freeradius/3.0/mods-available/sql
   
   	
   Ajuste as diretivas driver = mysql e server = [IP_DO_CLUSTER_MYSQL] para que o FreeRADIUS saiba onde buscar as credenciais dos assinantes.
   	

2. Definição dos Clients (NAS). O arquivo clients.conf deve ser idêntico em todos os nós do cluster. Isso garante que o seu concentrador PPPoE (BRAS/BNG) reconheça ambos os servidores como fontes válidas de autenticação.

   nano /etc/freeradius/3.0/clients.conf

   Adicione o IP do seu concentrador e a secret (senha compartilhada) comum:

   
   client concentrador_pppoe {
       ipaddr = 10.0.0.1
       secret = senha_ultra_segura
   }
   

    

3. Habilitação do módulo SQL. Após configurar o arquivo no diretório mods-available, você deve criar um link simbólico para a pasta mods-enabled para que o serviço carregue o driver na inicialização.

   ln -s /etc/freeradius/3.0/mods-available/sql /etc/freradius/3.0/mods-enabled/sql

   O comando ln -s cria o link simbólico necessário para ativar o módulo no runtime do serviço.

4. Teste de sintaxe e inicialização. Antes de reiniciar o serviço via systemctl, execute o FreeRADIUS em modo de depuração (debug mode) para validar se as consultas ao banco de dados estão funcionando sem erros de permissão ou conexão.

   freeradius -X

   A flag -X inicia o processo em primeiro plano com logs detalhados. Procure pela mensagem Module: Instantiating SQL module no final do log para confirmar o sucesso.

Sincronização de Banco de Dados MySQL

Para que o cluster FreeRADIUS funcione de forma transparente, os nós de autenticação devem acessar exatamente a mesma base de dados. Em uma arquitetura de alta disponibilidade para ISPs, não basta apenas replicar os arquivos de configuração; é mandatório que os dados de usuários, perfis e logs de conexão (radacct) estejam sincronizados em tempo real. A solução técnica mais robusta para este cenário é a implementação de Replicação Master-Slave (ou Source-Replica) do MySQL/MariaDB.

Neste modelo, o servidor primário (Master) processa todas as escritas (inserções de novos clientes ou alterações de planos), enquanto o servidor secundário (Slave) replica essas alterações de forma assíncrona. Isso garante que, caso o nó principal falhe, o nó de contingência possua a base de usuários atualizada para responder às requisições PPPoE.

Siga os passos abaixo para configurar a replicação básica entre os nós do cluster:

1. Configure o servidor Master para permitir conexões de replicação e gere um identificador único de servidor. No arquivo de configuração do MySQL (geralmente em /etc/mysql/mysql.conf.d/mysqld.cnf), adicione ou edite as seguintes diretivas:

   server-id = 1
   log_bin = /var/log/mysql/mysql-bin.log
   binlog_do_db = radius_db

   A flag server-id define o ID único do nó, essencial para evitar loops de replicação. O parâmetro binlog_do_db instrui o servidor a gravar apenas as alterações referentes ao banco do RADIUS no log binário, otimizando o tráfego de rede.

2. Crie um usuário de replicação no servidor Master com privilégios específicos para que o Slave possa ler os logs binários. Execute o seguinte comando no console do MySQL:

   CREATE USER 'repl_user'@'%' IDENTIFIED BY 'sua_senha_segura';
   GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
   FLUSH PRIVILEGES;

   O usuário repl_user utiliza o host '%' para permitir conexões vindas de qualquer IP do cluster, enquanto o comando GRANT REPLICATION SLAVE concede a permissão mínima necessária para a sincronização.

3. No servidor Slave, configure o identificador de servidor diferente do Master e aponte para o endereço do nó principal. Edite o arquivo /etc/mysql/mysql.conf.d/mysqld.cnf:

   server-id = 2
   relay-log = /var/log/mysql/mysql-relay-bin.log

   O server-id deve ser obrigatoriamente diferente do Master. O relay-log é o arquivo onde o Slave armazena temporariamente as transações recebidas do Master antes de aplicá-las localmente.

4. Inicie o processo de sincronização no Slave, apontando para o Master. No console do MySQL do Slave, execute:

   CHANGE MASTER TO
   MASTER_HOST='192.168.1.10',
   MASTER_USER='repl_user',
   MASTER_PASSWORD='sua_senha_segura',
   MASTER_LOG_FILE='mysql-bin.000001',
   MASTER_LOG_POS=154;
   START SLAVE;

   As flags MASTER_LOG_FILE e MASTER_LOG_POS são críticas; elas indicam exatamente de qual ponto do log binário o Slave deve começar a ler. Você obtém esses valores executando SHOW MASTER STATUS; no servidor Master.

Verificação da Autenticação Redundante

Após configurar o cluster e a sincronização do banco de dados, é fundamental validar se o processo de failover está operando conforme o esperado. A verificação consiste em testar a resposta de cada nó individualmente e, em seguida, simular a queda de um deles para garantir que o NAS (Network Access Server), como um concentrador PPPoE, consiga alternar para o segundo servidor sem derrubar as sessões ativas dos clientes.

O primeiro passo é realizar um teste de autenticação direta em cada nó do cluster utilizando o utilitário radclient. Este comando envia um pacote de requisição para o servidor e aguarda o pacote de resposta (Access-Accept ou Access-Reject).

1. Execute o teste de autenticação no primeiro nó do cluster (Node 01) utilizando um usuário existente no banco MySQL:

   radclient -x 127.0.0.1:1812 auth test_user password

   A flag -x habilita o modo debug, permitindo visualizar todo o fluxo de atributos do pacote RADIUS.
2. Repita o procedimento no segundo nó do cluster (Node 02), garantindo que o banco de dados sincronizado responda corretamente:

   radclient -x [IP_DO_NODE_02]:1812 auth test_user password

   O objetivo aqui é confirmar que a replicação do MySQL está íntegra e que o segundo servidor possui a mesma base de usuários.
3. Simule uma falha de serviço no Node 01 para observar o comportamento do concentrador PPPoE:

   systemctl stop freeradius

   Neste momento, monitore os logs do seu concentrador ou do próprio Node 02 para verificar se as novas requisições de autenticação estão sendo processadas pelo nó sobrevivente.
4. Verifique o log de autenticação no Node 02 durante a simulação de queda:

   tail -f /var/log/freeradius/radius.log

   Procure por mensagens de Access-Accept para os usuários que tentarem reconectar enquanto o Node 01 estiver offline.

O resultado esperado para um teste de sucesso deve apresentar o seguinte padrão de saída no terminal ao utilizar o radclient:

Received Access-Accept
Packet Type: Access-Accept
Attributes:
    User-Name = test_user
    Reply-Message = Access-Accept

Se o comando retornar Access-Reject ou um timeout, o problema pode estar na configuração de clients.conf (onde o IP do NAS deve estar liberado para ambos os nós) ou na latência de replicação do banco de dados.

Troubleshooting de Conexão e Timeout

A implementação de um cluster RADIUS para PPPoE introduz camadas adicionais de complexidade, especialmente no que diz respeito ao tempo de resposta. Em redes de ISPs, um atraso de poucos segundos na autenticação pode causar quedas em massa de sessões PPPoE, gerando um efeito cascata de reconexões no concentrador (BRAS/BNG).

• Sintoma: Clientes PPPoE desconectam e não conseguem reautenticar, apresentando erro de "Timeout" no log do concentrador.

  Boas Práticas de Segurança e Performance

  Manter um cluster FreeRADIUS operacional exige atenção constante tanto à integridade dos dados quanto à velocidade de resposta. Em uma infraestrutura de ISP, qualquer latência no processo de autenticação reflete diretamente na percepção de qualidade do cliente PPPoE.

  • Restrição de Origem via Client Config: Nunca permita que qualquer IP envie requisições ao seu servidor. No arquivo clients.conf, utilize a diretiva client especificando o IP exato do seu concentrador (BRAS/BNG). Isso evita que ataques de negação de serviço (DoS) via pacotes RADIUS inundem seu processo de autenticação.
  • Uso de Shared Secrets Fortes: O secret definido entre o NAS (Network Access Server) e o RADIUS deve ser complexo. Utilize strings longas com caracteres especiais para mitigar ataques de força bruta que tentam interceptar o hash do pacote RADIUS.
  • Otimização de Queries MySQL: Como o cluster depende de um banco de dados centralizado ou sincronizado, certifique-se de que as tabelas radacct (contabilidade) e radcheck (usuários) possuam índices adequados. A falta de índices em tabelas de log de conexão causará lentidão extrema conforme o número de usuários cresce.
  • Implementação de Timeout e Retries no NAS: Configure o seu roteador/concentrador para realizar tentativas de retransmissão (retries) de forma inteligente. Um timeout muito curto pode derrubar conexões legítimas em momentos de pico, enquanto um timeout muito longo pode travar a fila de autenticação do concentrador.
  • Monitoramento de Latência de Autenticação: Utilize ferramentas como o Zabbix ou Prometheus para monitorar o tempo de resposta das requisições Access-Request. Um aumento súbito no tempo de processamento é o primeiro sinal de que o banco de dados MySQL está sofrendo gargalo de I/O.
  • Segregação de Rede (VLAN de Gerência): O tráfego RADIUS deve trafegar por uma rede de gerência isolada da rede de tráfego de dados dos clientes. Isso impede que um usuário final, através de técnicas de spoofing, consiga interagir com o protocolo de autenticação da sua infraestrutura.
  • Backup e Disaster Recovery: Além da replicação do banco de dados, mantenha backups periódicos dos arquivos de configuração /etc/raddb/. Em caso de corrupção de disco no nó principal, a configuração precisa estar disponível para restauração imediata no nó secundário.

  FAQ sobre Servidores RADIUS

  Qual a diferença entre redundância de nível de aplicação e redundância de nível de rede no RADIUS?

  A redundância de nível de aplicação refere-se à configuração do NAS (Network Access Server), como um concentrador PPPoE ou MikroTik, onde você define uma lista de IPs de servidores RADIUS (Primary e Secondary). Já a redundância de nível de rede utiliza tecnologias como Keepalived ou VRRP para criar um IP Virtual (VIP) único. No primeiro cenário, o roteador precisa conhecer todos os servidores; no segundo, o roteador aponta apenas para o VIP, e o cluster gerencia qual nó está ativo, simplificando drasticamente a gestão de configurações nos concentradores da sua rede.

  Como o FreeRADIUS lida com a latência entre os nós do cluster?

  O FreeRADIUS não sincroniza estados de sessão em tempo real de forma nativa entre instâncias independentes, ele depende da consistência do banco de dados. Se a latência entre os nós e o banco MySQL for alta, o tempo de resposta do pacote Access-Request pode exceder o timeout configurado no concentrador PPPoE. Para mitigar isso, é fundamental que o banco de dados esteja em um ambiente de baixa latência (mesmo segmento de rede ou same availability zone) e que o timeout no roteador seja ajustado para suportar pequenos picos de processamento durante a sincronização de escrita.

  É seguro utilizar o mesmo Secret entre todos os servidores do cluster?

  Sim, o uso do mesmo Shared Secret é obrigatório para que o concentrador PPPoE consiga autenticar as requisições em qualquer um dos nós do cluster de forma transparente. No entanto, a segurança reside na proteção desse segredo. Recomenda-se que o segredo seja complexo e que o tráfego RADIUS trafegue preferencialmente por uma VLAN de gerenciamento isolada. Se o seu ambiente exigir conformidade rigorosa, considere implementar o RadSec (RADIUS over TLS), que encapsula as mensagens RADIUS em túneis TLS, protegendo o segredo e os atributos do usuário contra interceptação.

  O que acontece com as sessões ativas se o servidor primário cair?

  Em uma arquitetura PPPoE, a queda do servidor RADIUS primário não derruba as sessões que já foram autenticadas e estão em estado Established, pois o controle do túnel PPPoE é feito pelo concentrador (BRAS/BNG). Contudo, o cliente não conseguirá realizar reautenticação (re-auth) ou renovação de leases se o segundo nó do cluster não tiver acesso imediato ao banco de dados sincronizado. Por isso, a sincronização do MySQL deve ser síncrona ou semi-síncrona para garantir que o novo nó conheça o estado atual das contas e limites de banda.

  Conclusão e Próximos Passos

  Implementar uma arquitetura de FreeRADIUS redundante é um divisor de águas para a estabilidade de ISPs que operam com tecnologias PPPoE. Ao migrar de um servidor único para um cluster sincronizado, você elimina o ponto único de falha que poderia derrubar milhares de conexões simultâidades em caso de uma simples reinicialização ou falha de hardware. Esta configuração garante que o processo de Access-Request enviado pelo seu concentrador (BRAS/BNG) seja processado mesmo que um dos nós do cluster esteja indisponível.

  No entanto, a configuração de alta disponibilidade é um processo contínuo de refinamento. Uma infraestrutura robusta não se resume apenas ao funcionamento do serviço RADIUS, mas à capacidade de monitorar e escalar essa operação conforme a base de assinantes cresce. O sucesso da sua implementação depende da integridade da replicação do banco de dados e da baixa latência entre os nós do cluster.

  Para evoluir sua infraestrutura de autenticação, sugerimos os seguintes passos técnicos:

  • Implementação de Load Balancer Externo: Considere utilizar o Keepalived ou HAProxy para gerenciar um IP Virtual (VIP). Isso permite que o seu concentrador PPPoE aponte para um único endereço IP, enquanto o balanceador decide, via algoritmos de Round Robin ou Least Connections, qual servidor RADIUS está apto a responder.
  • Monitoramento Ativo com Zabbix ou Prometheus: Não espere o cliente reclamar da queda. Configure alertas para monitorar o uso de CPU, latência de consultas SQL e, principalmente, o volume de pacotes Access-Reject, que pode indicar ataques de força bruta ou falhas na sincronização do banco.
  • Segurança de Camada de Transporte: Se os seus servidores RADIUS estiverem em redes distintas ou atravessando links de longa distância, implemente RadSec (RADIUS over TLS). O uso de certificados digitais para cifrar o tráfego RADIUS previne o sniffing de credenciais de usuários dentro da sua rede de transporte.
  • Auditoria e Logs Centralizados: Utilize uma stack de ELK (Elasticsearch, Logstash, Kibana) para centralizar os logs de autenticação de todos os nós do cluster. Isso facilita o troubleshooting de erros intermitentes que podem ocorrer apenas em um dos nós da rede.

  A jornada para uma rede resiliente exige disciplina técnica. Comece validando sua configuração atual, monitore os gargalos de performance e, à medida que sua demanda crescer, escale horizontalmente adicionando novos nós ao seu cluster FreeRADIUS, sempre mantendo a consistência de dados como prioridade máxima.