Como funciona integração com MK-Auth: servidor, MikroTik e corte
Como funciona integração com MK-Auth: antes de qualquer ajuste, a base do sistema é copiada e restaurada num servidor de teste; depois o servidor é fechado para a internet e cada concentrador MikroTik passa a autenticar, limitar a velocidade e cortar a sessão pelo que está no cadastro. Como o MK-Auth roda dentro do provedor, a máquina faz parte do trabalho tanto quanto a rede.
Resumo
- O MK-Auth roda num servidor do próprio provedor e responde ao RouterOS a cada login PPPoE.
- A cópia restaurada com sucesso é sempre o primeiro passo, antes de tocar no servidor ou nos concentradores.
- No MikroTik, a integração mexe em três lugares, os servidores RADIUS, a desconexão remota e os perfis PPP.
- O provedor recebe a rotina de cópia, a lista de acessos e o passo a passo para reerguer o servidor.
Por que o MK-Auth muda a ordem do trabalho?
Porque o sistema roda numa máquina do próprio provedor, e um erro nela para a autenticação da base inteira. Por isso a integração começa pela máquina e só depois chega aos concentradores.
O MK-Auth é um ERP de provedor instalado num servidor local e muito usado com concentradores MikroTik [CONFIRMAR na documentação do fornecedor]. Ele guarda clientes, planos e cobranças e faz o papel de servidor RADIUS: cada login PPPoE que chega ao concentrador é perguntado a ele.
Na integração com MK-Auth, a Táquion Tech faz a cópia e a restauração antes de qualquer comando no servidor ou no RouterOS. Num sistema em nuvem, o fornecedor cuida da máquina; aqui, se ela para, nenhum cliente novo conecta até alguém reerguê-la.
| Ponto | MK-Auth instalado no provedor | Sistema hospedado pelo fornecedor |
|---|---|---|
| Máquina | Atualização, disco e acesso são do provedor | Ficam com o fornecedor do sistema |
| Caminho até a rede | Curto, dentro da rede de gerência | Atravessa a internet até cada POP |
| Maior risco | Perder o servidor sem cópia restaurável | Perder o link até a nuvem |
| Primeiro passo | Cópia testada da base | Caminho fechado e teste de queda do link |
A lógica de eventos comum a qualquer sistema de gestão está em como funciona integração com ERP de provedor. Este guia trata do que é próprio de quem roda o MK-Auth em casa.
Como funciona integração com MK-Auth, etapa por etapa
São cinco etapas, e cada uma só começa quando a anterior deixou um resultado conferido. O peso relativo de cada uma no tempo total aparece na última coluna.
| Etapa | O que acontece | Resultado que libera a próxima | Peso no tempo |
|---|---|---|---|
| 1. Cópia e restauração | Banco e configurações copiados para outro local e restaurados num servidor de teste | Sistema de teste abrindo com os clientes e planos da base | Curto, ou longo se não houver cópia |
| 2. Leitura | Versão do sistema operacional, disco, serviços abertos e concentradores anotados | Lista do que corrigir, aprovada pelo provedor | Curto |
| 3. Fechamento do servidor | Painel, SSH e banco restritos à gerência ou VPN, senhas trocadas e atualização em janela | Painel inacessível de fora e acesso da equipe funcionando | Médio |
| 4. Concentradores | Segredo próprio, desconexão remota, velocidade pelo plano e perfis locais limpos em cada MikroTik | Login, corte e velocidade conferidos com cliente de teste | O mais longo |
| 5. Entrega | Relatório do que mudou, rotina de cópia agendada e passo a passo de restauração | Equipe capaz de restaurar o servidor sem ajuda | Curto |
O prazo total depende do número de concentradores e do estado da máquina [PREENCHER prazo típico da Táquion Tech]. Os fatores de valor ficam no guia de quanto custa integração com MK-Auth.
O que o provedor deixa pronto antes da primeira etapa
A primeira etapa depende de acessos e de um lugar para a cópia ficar. Sem eles, nada mais anda.
- Acesso ao servidor: VPN ou rede de gerência até a máquina do MK-Auth e um usuário com permissão de administrador.
- Destino da cópia: outro servidor, um armazenamento na rede ou um serviço externo, nunca o mesmo disco.
- Máquina de teste: um servidor ou uma máquina virtual onde a cópia possa ser restaurada sem afetar a base.
- Lista de concentradores: endereço, versão do RouterOS e POP de cada MikroTik que autentica no sistema.
- Cliente de teste: um login por concentrador, com plano vendido hoje, que possa ser bloqueado à vontade.
O caminho de um login e de um corte entre MK-Auth e MikroTik
No login, o MikroTik pergunta e o MK-Auth responde com velocidade e endereço; no corte, é o MK-Auth que chama o MikroTik para derrubar a sessão. O diagrama mostra os dois sentidos.
1 · Login
Cliente conecta
O roteador do cliente abre a sessão PPPoE no concentrador MikroTik do POP.
2 · Pergunta
RouterOS consulta o MK-Auth
O concentrador manda usuário e senha ao servidor, assinados com o segredo daquele equipamento.
3 · Resposta
Plano devolvido
O MK-Auth aceita o login e devolve o endereço e o limite no atributo Mikrotik-Rate-Limit, que vira uma fila dinâmica.
4 · Corte
Status muda para bloqueado
O MK-Auth envia um pedido de desconexão ao RouterOS, que derruba a sessão aberta na mesma hora.
5 · Aviso
Página de pagamento
Na reconexão, o bloqueado recebe endereço ou lista que leva a navegação à página de aviso [CONFIRMAR na documentação do fornecedor].
Se o passo 4 falhar, o status muda no sistema e o cliente segue navegando até reiniciar o roteador. É a falha mais comum em MK-Auth antigo, e quase sempre está na desconexão remota desligada.
O corte do seu MK-Auth derruba a sessão na hora?
Um Especialista confere a desconexão remota em cada MikroTik, limpa os perfis locais e testa o corte com cliente de teste.
Exemplo: o que se configura em cada MikroTik
O bloco mostra a parte do RouterOS que a integração ajusta, com o servidor do MK-Auth num endereço de documentação. O segredo é exclusivo de cada concentrador.
# Servidor do MK-Auth (192.0.2.10), com segredo exclusivo deste concentrador
/radius add service=ppp address=192.0.2.10 secret=SEGREDO-POP-NORTE src-address=192.0.2.1 timeout=1s
# PPP autenticando e contabilizando pelo RADIUS, com atualização a cada 5 minutos
/ppp aaa set use-radius=yes accounting=yes interim-update=5m
# Pedido de desconexão aceito na porta 3799
/radius incoming set accept=yes port=3799
# A porta 3799 só aceita o servidor do MK-Auth
/ip firewall filter add chain=input protocol=udp dst-port=3799 src-address=192.0.2.10 action=accept
/ip firewall filter add chain=input protocol=udp dst-port=3799 action=dropDepois desse ajuste, os perfis PPP locais com limite próprio são removidos ou zerados, para não passarem por cima do que o MK-Auth manda. A limpeza acontece em janela, porque mexe em clientes conectados.
O restante do endurecimento do RouterOS, como serviços e acessos de gerência, está no guia de como proteger o MikroTik.
Cópia que volta: como funciona o teste de restauração
O teste pega a cópia, sobe num servidor separado e confere se o sistema abre com a base completa. Só a cópia que passou por esse teste conta como pronta.
- Cópia: banco e arquivos de configuração do MK-Auth exportados e enviados para o destino combinado.
- Servidor de teste: máquina separada, sem ligação com os concentradores, na mesma versão do sistema [CONFIRMAR na documentação do fornecedor].
- Restauração: a cópia é carregada e o sistema é aberto pelo painel, como se fosse o servidor principal.
- Conferência: número de clientes, planos e logins comparado com a produção, e um cliente de teste conferido por amostra.
- Registro: data, tamanho da cópia, tempo total da restauração e o que precisou de ajuste anotados no relatório.
O tempo total da restauração é um número precioso. Ele diz quanto tempo a base ficaria sem autenticar se o servidor parasse hoje e ajuda a decidir se vale ter um segundo servidor pronto.
E se o servidor nunca teve cópia?
Então a primeira etapa cresce, porque a cópia precisa ser criada e testada antes de tudo, mesmo que o pedido fosse só corrigir o corte. Mexer num servidor sem cópia arrisca a base inteira por um ajuste pequeno.
Se um concentrador também perdeu a configuração, o guia sobre recuperar configuração do MikroTik mostra os caminhos antes de refazer tudo do zero.
Erros comuns em cada etapa e o sinal que deixam
Cada etapa tem um atalho tentador que cobra a conta depois. A tabela mostra o atalho e o sinal que aparece quando ele foi tomado.
| Atalho | Etapa | Sinal de que aconteceu |
|---|---|---|
| Cópia no mesmo disco | Cópia e restauração | A cópia some junto com o servidor quando o disco falha |
| Cópia nunca restaurada | Cópia e restauração | Na hora da necessidade, o arquivo está vazio, incompleto ou é de outra versão |
| Painel liberado para fora | Fechamento do servidor | Tentativas de login de endereços estranhos no registro do sistema |
| Atualizar sem plano de volta | Fechamento do servidor | Serviço que não sobe depois da janela e ninguém sabe voltar |
| Mesmo segredo em todos os MikroTik | Concentradores | Um vazamento vale para a rede inteira, sem saber de qual equipamento saiu |
| Ajustar a fila do cliente à mão | Concentradores | Velocidade certa hoje e errada na próxima reconexão |
Quando os sintomas chegam todos de uma vez, com clientes caindo juntos, o problema deixa de ser de integração e vira emergência. O guia sobre PPPoE caindo para todos os clientes mostra a ordem de verificação.
O que o provedor recebe no fim da integração com MK-Auth?
O provedor recebe o servidor fechado e copiado, os concentradores obedecendo ao cadastro e os documentos para manter tudo assim. O mais importante é o passo a passo de restauração, escrito para a equipe.
- Relatório do que mudou: cada ajuste no servidor e em cada concentrador, com data e resultado do teste.
- Rotina de cópia: onde a cópia fica, com que frequência roda e como conferir se rodou.
- Passo a passo de restauração: o caminho para reerguer o MK-Auth numa máquina nova, com o tempo medido no teste.
- Lista de acessos: usuários do servidor, do painel e dos concentradores, com o acesso do fornecedor removível quando o provedor pedir.
A integração com MK-Auth exige repetir o teste de restauração de tempos em tempos, porque uma cópia que funcionava pode falhar depois de uma atualização. Quem faz esse teste depois da entrega fica combinado por escrito [CONFIRMAR oferta].
Os registros de conexão saem da contabilização que o MK-Auth recebe dos concentradores e precisam ser guardados pelo prazo legal [CONFIRMAR na norma]. A rotina de cópia inclui esses registros.
Perguntas frequentes
Dá para rodar o MK-Auth em máquina virtual?
Dá, e isso facilita a cópia e a restauração, porque a máquina inteira pode ser copiada além do banco [CONFIRMAR na documentação do fornecedor]. A mudança segue o mesmo teste de restauração antes de os concentradores apontarem para a máquina nova.
Quanto tempo o servidor fica fora durante a integração?
Na maior parte do trabalho, nenhum, porque cópia, leitura e testes não param o sistema. A atualização do servidor e a limpeza de perfis acontecem em janela de pouco uso, com plano de volta.
Um segundo servidor do MK-Auth vale a pena?
Vale quando o tempo medido no teste de restauração é maior do que o provedor aceita ficar sem autenticar. O teste dá esse número, e a decisão fica com o provedor.
O RouterOS 7 muda alguma coisa na integração?
Os conceitos são os mesmos, mas alguns comandos e padrões mudaram entre as versões 6 e 7 [CONFIRMAR na versão do equipamento]. Por isso a versão de cada concentrador é anotada na leitura e o teste é feito em cada um.
A equipe do provedor consegue manter tudo depois?
Consegue, com a rotina de cópia, o passo a passo de restauração e a lista de acessos. O que mais se perde com o tempo é o teste periódico da cópia, que precisa ter um dono na equipe.
Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]
Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.
A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.
Fontes
- RADIUS no RouterOS (documentação MikroTik): atributo Mikrotik-Rate-Limit, servidores cadastrados e recebimento de pedidos de desconexão
- RFC 5176: Dynamic Authorization Extensions to RADIUS: pedido de desconexão que o MK-Auth envia ao concentrador no corte por atraso
- RFC 2865: Remote Authentication Dial In User Service (RADIUS): troca de pergunta e resposta entre o RouterOS e o servidor a cada login PPPoE
