Olá,
Vejo que muita gente está com problemas de seus clientes não serem bloqueados com a address-list pgcorte.
Também tenho clientes com o mesmo problema, e ao investigar o porquê, identifiquei que o erro está na forma como o mk-auth adiciona o cliente bloqueado na tabela radreply do Freeradius. O campo "op" está sendo cadastrado como "==", sendo que o correto é ":=". Eu fiz a correção no campo e reconectei os clientes bloqueados, e todos reconectaram-se caindo na pgcorte como de costume.
A correção disso deve ser bem simples, provavelmente uma string de query e pronto, mas essa correção precisa ser feita pelo mk-auth e disponibilizada via atualização, já que o código é obfuscado e eu não tenho acesso para alterá-lo.
Att,
Rômulo Silva
Respostas
Bom dia a todos,
Quem queira entender pode continuar lendo, quem e preguicoso ou precisa com urgencia pode ir direto ate em baixo ;)
Depois de quebrar muito a cabeca procurando de varias maneiras, com query SQL no cron, com a linguagem unlang do freeradius, etc..
Achei uma maneira de ajeitar esse problema (mudando no lugar certo 2 letras para 6 !! ;) sem essa gambeara de formatar fazer downgrade e sei la
O problema realmente e porque o pedro usou operador errado na tabela radreply, a versao 2.x do freeradius (que nao e mais desemvolvida ha 10 anos)
aceitava erroneamente o operador "==" que nao tem sentido nenhum na tabela radreply, isso foi corrigido no freeradius 3.x.
CFR:
https://wiki.freeradius.org/config/Operators
http://freeradius.1045715.n5.nabble.com/FreeRadius-3-0-12-Select-ra...
http://freeradius.1045715.n5.nabble.com/Not-Receiving-radreply-Attr...
http://lists.freeradius.org/pipermail/freeradius-users/2015-July/07...
(sim, o Alan Dekok, fundador do freeradius, e um nerd chato mais ele ta certissimo ja tive argumento com ele uns 20 anos atras eu estava errado)
O certo seria o pedro ajeitar na fonte do codigo php compilado para inserir "=" ou ":=" ou "+=" na tabela radreply no lugar de "==".
Ate isso acontecer achei outra maneira:
Ja que so sao permitidos os operadores "=", ":=" e "+=" no radreply, mudei a query SQL do propio freeradius para sempre responder com o operador "+=".
Ate agora nao achei nenhuma circunstancia no mkauth que possa usar ou precisar de outro operador nas query SQL da tabela radreply.
Usando o operador "+=" permite atribuir varias address list para um usuario.
Para os preguicosos, tem sorte, simplifiquei o negocio, e so digitar essas linha no terminal root:
sed -i /etc/freeradius/3.0/mods-config/sql/main/mysql/queries.conf -e "s/authorize_reply_query = \"SELECT id, username, attribute, value, op/authorize_reply_query = \"SELECT id, username, attribute, value, \\\\\"+=\\\\\"/"
Reiniciar o servidor RADIUS:
/etc/init.d/freeradius restart
Pronto, pode relaxar.. ;)
Bom dia,
Boa noticia, depois de muita pesquisa e quebrar muito a cabeca consegui resolver isso de maneira linda e efficaz sem formatar e para qualquer iso ou versao atualizada!
Quem precisar do fix pode enviar messagem pelo whatsapp: +55 (86) 999 21 45 38
sera que nesta atualização nova que foi corrigido alguns bugs foi resolvido, 22-03-2020
Gilson Barbosa disse:
Aqui parou faz tempo por address-list, então passamos para pool, agora por pool também não funciona mais (estamos usando versão 19.01 :: K4.9, o jeito vai ser voltar para a versão antiga mesmo...
O cliente ficar caindo, é erro de configuração das regras da RB.
Já processamento, vai depender de como vc vai fazer, quanto mais regras tiver que processar, mais vai consumir os recursos.
Eu só faço 2 regras de nat, direcionando http e https, e não crio um nat para a faixa do pool de bloqueio, assim o cliente não navega, e caso ele tente abrir alguma página, vai ser redirecionado.
Tenho clientes que possuem com várias regras, liberando dns, liberando acesso a http e https para depois fazer o redirecionamento, e depois drop, enfim, várias regras, que dependendo da caixa, chegam a aumentar em 20% o processamento de BRAS mais básicas em determinados horários.
Arianderson Matos de Oliveira disse:
Bom dia, você verificou o mikrotik se o cliente que ta bloqueado não fica caindo aumentando o processamento do servidor?
Diogo pereira de oliveira disse:
pode explica melhor ou informa um forum que tem essa explicação, obrigado.
Diogo pereira de oliveira disse:
galera usem bloqueio via Radius Pool, esta funcionado eu fiz os testes aqui
Tenho os 2 sistemas aqui, 19.01 k3.1 e o k4.9.
Fiz os testes mudando para Address-List, e verificando a tabela radreply, não vi diferença nos dados, porém o k4.9 realmente não envia o atributo para o BRAS quando o campo OP está com o valor ==.
Já no k3.1 envia normal. Alguém já tentou fazer a captura de pacotes para ver se o erro não é do freeradius?
A versão k3.1 usa o freeradius 2.2.5 e o k4.9 usa o freeradius 3.0.12.
Cabo Net Provedor de Internet disse:
Na verdade, tentem conseguir uma ISO antiga do sistema que resolve. 18.01 funcionando perfeitamente.
Obs*** Pedro Filho !! DE QUALQUER FORMA, MESMO ASSIM,TOMA ALGUMA PROVIDENCIA POR GENTILEZA !!!
-
1
-
2
-
3
de 3 Próximo