Olá Pedro bom dia, tenho observado a algum tempo que meu mk-auth não está conseguindo derrubar a conexão do cliente para que ele possa ver a pgcorte, sendo assim os clientes que era pra ser bloqueado e que usam roteador não ver a pgcorte, antes quando o cliente entrava na lista de bloqueado ou algumas mudanças que realizava no cadastro do cliente o próprio mk-auth se encarregava de derrubar a conexão do cliente para que as novas alterações entrasse em vigor mas ultimamente tenho observado que o meu mk-auth não está fazendo mais isto, o que deve ser, qual a solução?
aqui uso bloqueio via radios;
comunicação ssh testada apartir do mk-auth ok;
o ip do cliente é fixado no cadastro;
cliente conecta via pppoe;
no sistema está para bloquear automaticamente;
minha rede é roteada tendo uma gateway servindo os ramais.
fico grato pela ajuda que dispor
Respostas
clique no botão incoming e ative a opção accept e coloque o valor 3799 em port:
mas já está assim Pedro nunca mudei esta opção veja no print:
Pedro Filho disse:
olha no firewall se não tem algo dropando a 3799...
Carlos Roberto Borges disse:
Não tenho regras adicionais no mikrotik pra fazer o drop da porta 3799 nem nenhuma outra porta, apenas dropo ips do psafe conforme print abaixo:
tenta manualmente e ver se aparece algum erro, troca os que estão destacados pelos dados que vc usa:
sudo echo "User-Name=login_cliente, Framed-IP-Address=ip_cliente" | radclient -t 0 ip_mikrotik:3799 "disconnect" 123456
Carlos Roberto Borges disse:
resolvido, neste print abaixo eu mostro o ramal 10.0.1.2 com o login em destaque que estou usando neste momento, e ao executar o comando no putty não acontece nada com o login ou seja no desconecta veja abaixo:
Boa noite a todos, preciso de um auxilio de alguém ou especialista. Meu problema é o seguinte quando o cliente é desbloqueado ou bloqueado ou preciso usar o comando reparar, não esta derrubando o cliente, tenho que ir manual la na rb concentrador e derrubar o cliente, porem isso acontece somente na ultima que coloquei, o ponto aponto dela já passa por outro concentrador pode ser isso mais as outras estão funcionando, ;( notei que em RADIUS incoming o status aparece em BAD REQUEST, não sei se ficou claro, mais agradeço a força ou auxilio de alguém, obrigado.
Meu corte =e por radius mangle list
se é BAD REQUEST então está chegando o pedido no MikroTik, é preciso ver pq ele não valida, talvez ele não aceite o pedido pq tem um concentrador no caminho e o ip que ele recebe não é o do mk-auth mais sim desse concentrador...
Maycon M disse:
estou com esse mesmo problema .. recebe no BAD REQUEST mas não valida. e o teste que você pediu PEDRO para o amigo Raimundo Vasconcelos aqui não deslogou.
acredito que seja esse problema de é de não estar recebendo o IP do MK-Auth e sim de outro concentrador ..
já quando faço os testes em loguins que estão na rb de borda funciona normalmente. agora em outros concentradores que são empurrados a partir do roteamento não vai.
É Pedro voltei a sofrer novamente com esta questão de o mkauth não conseguir derrubar a conexão de clientes bloqueados fiz os seguintes testes abaixo veja:
* Versão atualizada do mkauth
* Versão 6.34.1 x86 do mikrotik
* Rede cabeada e Roteada com OSPF, MPLS e VPLS, trazendo as autenticações de todos os clientes para este mikrotik na central.
* Ip do ramal 10.1.1.6 bem como ip do cliente fixo 172.21.6.204, todos informados no cadastro do cliente.
* Como pode ser visto no print, o Mkauth consegue pingar ip do ramal bem como ip do cliente.
* Ao executar o comando via putty como pode ser visto print aparece uma mensagem de comunicação veja:
radclient: no response from server for ID 253 socket 3
Veja os prints de configurações:
-
1
-
2
-
3
de 3 Próximo