Boa noite pessoal instalei o mkauth 18.02 em uma maquina e voltei o backup e funcionou tudo certo, mas o mkauth nao esta bloqueando os clientes fiz alguns testes:
1- O MKAUTH pinga nas rbs que autentica os clientes,
2- O MKAUTH envia com sucesso um teste de ssh para as rbs,
3- O modo de bloqueio é o radius por list,
4- Fiz um teste mandando o MKAUTH desligar ou reiniciar a rb e funcionou.
5- A versão do Mikrotik varia da 6.40 até a 6.43.2.
Diante dos testes não encontrei o problema de não bloquear os clientes, na verdade pude perceber que ele não "DERRUBA" a conexão dos clientes e não envia o ip do cliente para o address list para o mesmo conectar novamente e ai sim ficar bloqueado.
Alguém já consegui resolver?
Respostas
Bom dia pessoal, vou deixar a minha msg em negrito para destacar o que vou escrever, o meu problema aqui foi resolvido e NÃO era nada no MKAUTH e sim em um nat que passou despercebido, então peço desculpas pelo post pois o problema era na rede e não no sistema.
Muito obrigado a todos que me ajudaram, vlw msm.
Até mais
vc precisa configurar assim amigo. e la no seu MK auth vc vai criar o servidor com ip da loopback.
Rodrigo Juliano Lira disse:
amigo isso que ta usando é via ospf?
Paulo Perina disse:
Boa Tarde Paulo
Problema está que o ip que está chegando na controladora com a solicitação para "derrubar" a conexão não é o mesmo que está configurado no radius no campo address . Daí a controladora (mikrotik) ignora, afinal ela tem cadastrado no radius dela o ip final 236.250 e não o ip final 236.22. Pode fazer um teste: configure o ip 236.22 no radius do mikrotik e na RB final 236.22 crie uma regra redirecionando o tráfego das portas 3799 para o ip do teu mk-auth(230.250). O ssh funciona normal pq ele não é influenciado por isso, o único problema fica que cliente não bloqueia automaticamente e não desbloqueia caso ele já esteja autenticado, tem que ficar derrubando direto na controladora :(. Solução ideal seria que o ip do teu mk-auth ficasse transparente para todas as controladoras. Sem passar por NAT.
OBS: eu utilizo sub-rede para cada conexão com a rb, e o mkauth esta também em uma sub-rede ligada nesta rb que tem o ip 236.22.
Paulo Perina disse:
Bom dia, o MKAUTH esta comunicando e pingando normalmente na rb, fiz um teste de ssh e também funcionou, fiz o teste que solicitaram e a saída foi essa:
Bom dia Paulo.
se precisar consultoria técnica me chama no zap que resolvo teu problema.
(55) 99678-4739
Paulo Perina disse:
Bom dia Paulo
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, esse problema não tem solução?
Será que esse problema meu nao tem conserto?
-
1
-
2
-
3
de 3 Próximo