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

Para adicionar comentários, você deve ser membro de MK-AUTH.

Join MK-AUTH

Enviar-me um email quando as pessoas responderem –

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

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

This reply was deleted.