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).
Respostas
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
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 .....