Login Radius — credenciais que autorizam o cliente a usar a internet
O Login do Cliente é o conjunto usuário+senha que o equipamento do cliente (ONU/roteador) usa pra autenticar no servidor Radius da rede. Sem Radius autorizando, cliente fica sem internet — mesmo com contrato ativo. Esta wiki cobre como o login é criado, sincronizado com o Radius, bloqueado por inadimplência, e revogado em cancelamento.
1 Listagem de Logins
Cliente → Login de contrato
Listagem central dos logins ativos. Cada linha mostra: login, contrato/cliente, plano, IP, MAC do equipamento, último consumo, situação (online/offline).
2 Consumo
Cliente → Login consumo
Histórico de consumo de banda por login — útil para SLA, faturamento de excedente, troubleshooting de problemas de velocidade. Geralmente populado pelo Radius accounting.
3 Login em Degustação
Cliente → Login degustação
Login configurado como trial — funciona por X dias com plano completo, depois pede contratação. Marketing/aquisição de clientes.
4 Equipamento
Cliente → Login equipamento
Cadastro do equipamento físico vinculado ao login (ONU, modem, roteador, ATA telefonia). Inclui MAC, modelo, serial, firmware. Importante para troubleshooting técnico de campo.
5 Histórico de Login
Cliente → Login histórico
Auditoria de alterações no login — mudança de plano, troca de senha, atualização de equipamento. Auditoria essencial.
6 Reply Atributos (Radius)
Cliente → Login reply
Atributos Radius retornados ao equipamento durante a autenticação — IP, gateway, DNS, velocidade up/down, VLAN, política de QoS. Configuração avançada pra cenários especiais.
Como funciona o Radius no Quaza
| Etapa |
O que acontece |
| 1. Authentication Request |
Equipamento do cliente envia user/pass para o servidor Radius. |
| 2. Lookup |
Radius consulta o banco do Quaza pelos dados do contratoLogin. |
| 3. Validação |
Senha bate? Contrato ativo? Login não bloqueado? |
| 4. Reply |
Se OK: retorna IP + atributos (velocidade, etc.). Se não: rejeita. |
| 5. Accounting |
Equipamento envia consumo periódico (start/interim/stop) — populando histórico. |
Pré-requisitos
- Cliente cadastrado (Cliente
).
- Contrato criado (Contrato
).
- Pool de IPs configurado em Rede.
- Servidor Radius integrado com Quaza.
PADRÃO OPERACIONAL — FLUXO COMUM
──────────────────────────────────
1. Cadastro inicial / configuração
│
▼
2. Permissões definidas por papel
│
▼
3. Operação normal:
┌──────────────────────────────────┐
│ - input do operador / cron │
│ - validação automática │
│ - persistência no banco │
│ - log de auditoria │
│ - notificação (se aplicável) │
└──────────────┬───────────────────┘
│
▼
4. Revisão / supervisão
│
┌──────┴──────┐
▼ ▼
OK normal Desvio detectado
│ │
▼ ▼
Histórico Ação corretiva +
alerta ao supervisor
Documentos relacionados
Glossário
| Termo |
Significado |
| Quaza |
Sistema ERP/BSS pra ISP — gestão integrada de cliente, financeiro, fiscal, técnico. |
| Contrato |
Vínculo formal entre cliente e empresa, define o que está sendo prestado. |
| Fatura |
Documento de cobrança gerado a partir do contrato. |
| Auditoria |
Revisão sistemática de registros para detectar inconsistências. |
| Permissão |
Direito de acesso/edição vinculado a papel ou usuário. |
| API REST |
Interface programática que permite integração com sistemas externos. |
| Cron / crontab |
Agendador de tarefas que roda em horários definidos. |
| Webhook |
Notificação automática que sistema externo recebe quando evento ocorre. |
| Centro de custo |
Dimensão transversal — filial, projeto, setor. |
| Conciliação |
Processo de garantir que extrato bancário bate com Quaza. |
Pegadinhas frequentes
1. Falta de validação pós-configuração. Cadastro feito sem teste real = pega o erro quando vai pra produção. Sempre teste com dado dummy antes.
2. Permissões mal definidas. Operador com acesso de admin = risco. Defina papéis claros.
3. Não treinar equipe nova. Funcionário novo opera no escuro, faz besteira por desconhecimento.
4. Mudar configuração sem registrar. Quem mudou, quando, por quê — perde-se rastro.
5. Ignorar alertas/notificações. Alerta que ninguém olha não serve.
6. Operações em massa sem dry-run. Antes de aplicar a 1000 registros, teste com 5.
FAQ
Como começar a usar este módulo?
Configure os pré-requisitos listados acima, faça um teste em ambiente seguro (ou com poucos registros), valide com a equipe, e só então ative em produção.
Preciso de permissão especial pra acessar?
Sim. Cada papel (operador/supervisor/admin) tem permissões distintas. Confirme com o administrador do Quaza.
Posso integrar com sistemas externos?
Via API REST do Quaza. Webhooks notificam eventos importantes. Consulte a equipe técnica para credenciais.
O que acontece se houver erro?
Os logs ficam no painel de tarefas/auditoria. Configure alertas (email/Slack) para falhas críticas — não confie em ninguém olhar log manualmente.
Como acompanhar mudanças?
Cada registro tem histórico (timestamp, usuário, ação). Use o filtro de auditoria pra rastrear modificações suspeitas.
O módulo funciona multi-filial?
Sim — via centro de custo (filial) atribuído ao lançamento. Relatórios filtram por filial.
Boas práticas operacionais
Esta seção reúne hábitos que provedores experientes adotam pra evitar problemas recorrentes neste módulo. Aplicação consistente faz diferença grande no longo prazo — diferença entre operação caótica e operação previsível.
Revisão periódica
Reserve 30 minutos por semana pra revisar o estado do módulo: o que rodou, o que falhou, o que ficou pendente. Anomalia detectada cedo custa 10x menos que descoberta tarde.
Documentação de procedimentos
Crie checklists internos pra operações recorrentes — abertura/fechamento do mês, processamento em lote, correção de inconsistências. Não dependa de quem "sabe de cabeça" — funcionário pode sair, ficar doente, ter dia ruim.
Backup antes de operações em massa
Qualquer mudança que afete 100+ registros deve ser precedida de backup ou export. Restaurar uma alteração massiva equivocada é caro; prevenir é simples.
Comunicação com cliente
Mudanças que impactam o cliente (preço, cobrança, regra) devem ser comunicadas com antecedência. Cliente surpreendido reclama; cliente avisado entende.
Indicadores acompanhados
Defina 2-3 indicadores que medem a saúde do módulo. Acompanhe semanalmente. Quando algum sai do range esperado, investigue antes de virar problema visível.