MK-AUTH

MK-AUTH não está bloqueando Clientes em atraso automaticamente!!

Boa noite amigos,

Estou utilizando a versão 18.02 e o meu MK-AUTH é Cloud, entrei em contato com a empresa do Cloud e o mesmo informou que não resolveria este problema.

Os clientes em atraso aparecem em vermelho normalmente no sistema, porém eu tenho que ir no mikrotik e derrubar manualmente a conexão do cliente, quando ele loga novamente já vem bloqueado e o desbloqueio é da mesma forma, assim que o pagamento é confirmado tenho que derrubar a conexão para que ele venha conectar desbloqueado.

Preciso de ajuda e não estou sabendo a quem recorrer... Clientes autenticando em PPPoE e modo de bloqueio é por List. (Obs: Tudo foi configurado pelo fornecedor do Cloud, o teste de chave ssh funciona normalmente).

Exibições: 155

Responder agora

Respostas a este tópico

Bom dia ,

Estamos com o mesmo problema no mk-auth, minha versão é a 18.02, mas não é o cloud. Clientes autenticam em PPPOE e o bloqueio por radius-pool.

Se alguém puder ajudar, agradeço!

Bom dia, quando eu fiz a atualização do meu mkauth para essa mesma versão, também tive o mesmo problema, e porque nessa versao mudou a forma de bloqueio, contratei um especialista ele teve que fazer um script para fazer o bloqueio. So voltou a funcionar depois do script ai toda vez que o cliente vai logar pppoe o script verifica.

#===============================
:global IPMKAUTH "172.31.255.2";
:global KEY "xxxxxxxxxxxxxxxxxxxxxxx";
:global RAMAL "172.31.255.1";
:global done "";
/tool fetch mode=http url="https://$IPMKAUTH/mkt/pgcorte.php\?key=$KEY&ramal=$RAMAL" src-path=mkt_pgcorte.php dst-path=mkt_pgcorte.rsc;
:set done "true";

:if ( [/file find name=mkt_pgcorte.rsc] != "" ) do={
:log warning "Importando PgCorte";
/import mkt_pgcorte.rsc;
/file remove mkt_pgcorte.rsc;
}

Bom dia Felipe

Isso geralmente ocorre quando há uma falha de comunicação entre o Mk-auth e o radius-client do mikrotik. Geralmente isso ocorre por bloqueio na porta 3799 ou quando o teu mk-auth está atrás de nat.

Testes:
Crie essas duas regras de firewall no teu mikrotik (ramal) no topo, antes das outra regras:

/ip firewall filter
add action=accept chain=input log=yes port=3799 protocol=tcp
add action=accept chain=input log=yes port=3799 protocol=udp

Após vai no mk-auth e dê um reparar em um cliente que se autentica nesse ramal. Nos logs deverá aparecer uma saída similar a essa abaixo:

Mar/22/2019 10:17:32 firewall,info input: in:ether1-WAN out:(none), src-mac 4c:5e:0c:2e:55:c8, proto UDP, 192.168.151.2:34670->10.255.210.15:3799, len 76

192.168.151.2:34670 -> Ip do mk-auth -> Conferir se o ip que aparece aqui é o mesmo configurado no radius do mikrotik. Se o teu mk-auth estiver atrás de nat em vez do ip do mk-auth virá o ip do gateway que está fazendo o nat. Ao chegar a solicitação de desconexão o mikrotik (ramal) confere se o ip que está solicitado é o mesmo configurado no radius. Se não for ele descarta e não desconecta o cliente.
10.255.210.15:3799 -> Ip do Ramal

Boa noite amigo, beleza?

Fiz a adição das regras recomendadas, porém não resolveu. Observei que na parte do Incoming a aba está marcada e a porta está 3799, porém não tem nenhum valor nessa aba estando todos em "0".


Rodrigo Juliano Lira disse:

Bom dia Felipe

Isso geralmente ocorre quando há uma falha de comunicação entre o Mk-auth e o radius-client do mikrotik. Geralmente isso ocorre por bloqueio na porta 3799 ou quando o teu mk-auth está atrás de nat.

Testes:
Crie essas duas regras de firewall no teu mikrotik (ramal) no topo, antes das outra regras:

/ip firewall filter
add action=accept chain=input log=yes port=3799 protocol=tcp
add action=accept chain=input log=yes port=3799 protocol=udp

Após vai no mk-auth e dê um reparar em um cliente que se autentica nesse ramal. Nos logs deverá aparecer uma saída similar a essa abaixo:

Mar/22/2019 10:17:32 firewall,info input: in:ether1-WAN out:(none), src-mac 4c:5e:0c:2e:55:c8, proto UDP, 192.168.151.2:34670->10.255.210.15:3799, len 76

192.168.151.2:34670 -> Ip do mk-auth -> Conferir se o ip que aparece aqui é o mesmo configurado no radius do mikrotik. Se o teu mk-auth estiver atrás de nat em vez do ip do mk-auth virá o ip do gateway que está fazendo o nat. Ao chegar a solicitação de desconexão o mikrotik (ramal) confere se o ip que está solicitado é o mesmo configurado no radius. Se não for ele descarta e não desconecta o cliente.
10.255.210.15:3799 -> Ip do Ramal

Bom dia Felipe

Pior que peguei um caso similar aqui com um Mk-auth Versão 19.01 de um amigo. Se mando reparar um cliente que está cadastrado no Ramal que é o gateway do MK-auth ele derruba normal, porém para os outros ramais não funciona. Testei o comando de desconexão manual do radius "sudo echo "User-Name=login_cliente, Framed-IP-Address=ip_cliente" | radclient -t 0 ip_mikrotik:3799 "disconnect" 123456" e funciona normal em qualquer um dos ramais, ou seja, não é comunicação entre o MK_auth e o Mikroitk.

Obs: Analisando através do tcpdump o mk-auth não chega nem a enviar a solicitação para a porta 3799 do ramal.

estou com  esse mesmo problema aqui se alguem pode  ajuda deixo meu zap aqui pra  uma  ajuda  dos amigo aqui aj revisei todo meu mk junto com meu mk auth  aqui  ja nao sei mas  oque posso fzer  aqui .....

Responder à discussão

RSS

parcerias

© 2020   Criado por Pedro Filho.   Ativado por

Badges - Divulgar  |  Relatar erro no site  |  Termos de serviço