[resolvido] MKAUTH 18.02 nao bloqueia clientes
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?
Exibições: 1450
As respostas para este tópico estão encerradas.
Respostas a este tópico
-
Permalink Responder até Luiz Henrique Brizola em
-
Opa boa tarde oq vc fez para q eles fossem para o address-list os meus não estão indo
-
-
Permalink Responder até Paulo Perina em
-
Será que esse problema meu nao tem conserto?
-
-
-
Bom dia, esse problema não tem solução?
-
-
Permalink Responder até Rodrigo Juliano Lira em
-
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=udpApó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 -
-
Permalink Responder até Adriano DIGITAL CENTER INF em
-
Bom dia Paulo.se precisar consultoria técnica me chama no zap que resolvo teu problema.
(55) 99678-4739
Paulo Perina disse:Bom dia, esse problema não tem solução?
-
-
-
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:
-
-
-
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:
-
-
-
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.
-
-
Permalink Responder até Elton Pereira dos Santos em
-
amigo isso que ta usando é via ospf?
Paulo Perina disse:Sim agora estao indo para o address list.
Uso varios ramais.
Todos os clientes eu seto no ramal especifico.
Ja reparei e nao deu certo
Adriano Alves DIGITAL CENTER INF disse:Eles estão indo para o addres list?
Outra coisa usa mais de um ramal ?
Já experimentou setar o cliente no ramal específico?
Vai na lista de bloqueados e seleciona todos e reparar. -
-
-
vc precisa configurar assim amigo. e la no seu MK auth vc vai criar o servidor com ip da loopback.
Rodrigo Juliano Lira 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.
-
-
-
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
-
- ‹ Anterior
- 1
- 2
- Próximo ›
Bem-vindo a
MK-AUTH
parcerias
© 2020 Criado por Pedro Filho.
Ativado por
Badges - Divulgar | Relatar erro no site | Termos de serviço
