MK-AUTH

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

Opa boa tarde oq vc fez para q eles fossem para o address-list os meus não estão indo

Será  que esse problema meu nao tem conserto?

Bom dia, esse problema não tem solução?

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

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

RSS

parcerias

© 2020   Criado por Pedro Filho.   Ativado por

Badges - Divulgar  |  Relatar erro no site  |  Termos de serviço