Re: Um gerenciador de provedor que não precise de maquina para instalação
Citação:
Postado originalmente por
andrecarlim
Nativo no mk-auth não! Mas eu fiz meu scripts que lêem o banco e geram um arquivo para importar dentro de qualquer mk!
Enviado via XT1563 usando
UnderLinux App
Nativo, sim!
MK-Auth tem uma API PHP, que pode ser acessada de dentro da RB por uso do fetch e ela retorna um script do RouterOS que ao ser armazenado em um arquivo e executado insere os secrets e profiles (PPPoE), leases, etc. (não lembro se tem para hotspot).
Tem um script PHP para cada tipo de dados (PPPoE, DHCP, ARP, etc.).
Re: Um gerenciador de provedor que não precise de maquina para instalação
Bom saber! Agora ensina aew como faz, eu não fazia ideia que isso era possível no mk-auth...
Enviado via XT1563 usando UnderLinux App
Re: Um gerenciador de provedor que não precise de maquina para instalação
Citação:
Postado originalmente por
andrecarlim
Bom saber! Agora ensina aew como faz, eu não fazia ideia que isso era possível no mk-auth...
Enviado via XT1563 usando
UnderLinux App
Basta criar um script que faça fetch de uma URL no seguinte formato:
Código :
http://<IP_DO_MKAUTH>/api/<API_DESEJADA>.php?key=<TOKEN>&ramal=<RAMAL>
<IP_DO_MKAUTH> é auto explicativo.
<API_DESEJADA> pode ser:
- mkt_arp (entrada ARP para cada cliente e seu IP)
- mkt_dhcp (lease no servidor DHCP para cada cliente)
- mkt_hotspot (profiles e users/clientes do Hotspot)
- mkt_ip (endereços IP da RB - não parece ter a ver com clientes, nos meus testes o script veio vazio, apenas com a parte de remover IPs adicionados anteriormente pela API, como é feito em todas, então não entendi bem)
- mkt_pgaviso (IPs de clientes atrasados na address-list pgaviso)
- mkt_pgcorte (IPs de clientes bloqueados na address-list pgcorte)
- mkt_pppoe (profiles e secrets/clientes do PPPoE)
- mkt_queues (queues dos clientes)
- mkt_wifi (entrada na access-list para cada autorizar/bloquear conexão do cliente ao rádio MikroTik)
<TOKEN> é obtido no MK-Auth, no final da página "Dados da Empresa".
<RAMAL> é o IP da RB onde os clientes são autenticados/controlados. O IP deve corresponder ao utilizado ao cadastrar a RB em "Controle de Servidores". Pode ser usado "todos", caso queira obter as informações para todas RBs cadastradas.
Até hoje somente utilizei mkt_pgcorte, mkt_pgaviso e mkt_pppoe. As duas primeiras são muito simples, pois uma vez que você tem o IP do cliente atrasado ou bloqueado na respectiva address list, basta fazer as regras do firewall para bloqueio ou redirecionamento baseado na lista.
Já em relação à mkt_pppoe, precisa criar na RB um pool chamado Local-1. Esse pool é usado como local-address nos profiles. O problema é que não faz sentido ter vários IPs nesse pool, senão vai usar 2 IPs para cada cliente (a cada cliente autenticado é usado 1 IP desse pool para a RB, além do IP do cliente), então o ideal seria colocar apenas 1 endereço nele. No entanto, fazendo isso os clientes não autenticam, pois a RB não consegue determinar o endereço local (estranhamento aparece no log que o problema é no remote-address, vai entender esse monte de bugs do RouterOS...).
A solução para isso é inserir, no script ou no scheduler, logo após receber e cadastrar os profiles e secrets, um novo comando alterando nos profiles o local-address para o IP desejado, no lugar do pool Local-1.
Além do pool Local-1, é preciso criar um chamado Remoto-1. Esse é o pool de onde o IP dos clientes é obtido. No entanto, ele é simbólico, uma vez que o IP dos clientes é definido no campo remote-address dos secrets cadastrados, com base nos endereços que constam no MK-Auth.
Uma observação: os secrets vêm desabilitados por padrão. Isso é útil para quem usa MK-Auth em cloud, ou talvez até mesmo local, e queira ativar esses secrets para autenticação local apenas no caso de perder comunicação com o Radius (por meio do Netwatch). Ou pode também ativar todos eles logo após serem cadastrados, no scheduler ou no script, assim a autenticação será sempre local.
Outras APIs talvez tenham que fazer pré-configurações e ajustes, semelhante ao caso da mkt_pppoe.
Ah, sim, no script, o fetch e a execução do script são feitos conforme o seguinte:
Código :
/tool fetch mode=http url="URL_DA_API_CONFORME_DESCRITO" src-path=<API_DESEJADA>.php dst-path=<API_DESEJADA>.rsc;
:if ( [/file find name=<API_DESEJADA>.rsc] != "" ) do={
/import <API_DESEJADA>.rsc;
/file remove <API_DESEJADA>.rsc;
};
Por meio do scheduler, isso aí é repetido a cada um dado tempo. Para o caso de apenas fallback para ocorrência de perda de comunicação com o Radius, o tempo re reiteração da execução pode ser alto, 6 ou 12 horas, por exemplo. Já se for para a forma de autenticação principal ser localmente, tem que ser mais frequente para manter a consistência com inserções de alterações de clientes.
Re: Um gerenciador de provedor que não precise de maquina para instalação
Exatamente o mk funciona totalmente independente, caso o RADUIS venha a cair. Todos os usuários pppoe ja ficam cadastrados em ambos. Caso a vpn caia, o mk através de script, ativa todos os usuarios.
Citação:
Postado originalmente por
dmarcio
@
FMANDU Bom dia.
Então se a VPS cair nada acontece com o mikrotik? E se reiniciar o mikrotik com a VPS caída, os usuários autenticam? O MK funciona independente mesmo o servidor Radius estar off? Tenho essa dúvida...
Mas me diz aí onde está hospedando essa VPS?
Um abraço.
Márcio.
Re: Um gerenciador de provedor que não precise de maquina para instalação
Pela quantidade de clientes sai vantajoso instalar um sistema em nuvens podendo como será nas nuvens pode configurar um período mais longo das alterações rádios tipo 30 minutos ou mais (como temos o mk auth local virtualizado) deixamos essas alterações em tempo real
Enviado via Moto G (4) usando UnderLinux App