Problema da pgcorte por address-list está na radreply

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

Para adicionar comentários, você deve ser membro de MK-AUTH.

Join MK-AUTH

Votos 0
Enviar-me um email quando as pessoas responderem –

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

  • 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:

    galera usem bloqueio via Radius Pool, esta funcionado eu fiz os testes aqui

  • 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:

    galera usem bloqueio via Radius Pool, esta funcionado eu fiz os testes aqui

  • 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

  • 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 !!!

  • 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 !!!

This reply was deleted.