dica para o freeradius

Sobre o MKAuth

O designe dele poderia ser melhor, mas pelo visto o criador do mesmo
não está nem ai pra fazer algo mais comperecível e elegante.

O principal e mais antigo problema do freeradius quando se habilita a função:

simulverifyquery

Esta função fica em : “mods-config/sql/main/mysql/queries.conf” (se usar mysql)
e pode ser editada.

A função completa:

simulverifyquery = "
SELECT
radacctid, acctsessionid, username, nasipaddress, nasportid, framedipaddress,
callingstationid, framedprotocol
FROM ${acct_table1}
WHERE username = ‘%{SQL-User-Name}’
AND acctstoptime IS NULL"

Esta função consulta a tabela radacct apenas pelo username (WHERE username = ‘%{SQL-User-Name}’)
quando não foi encerrado a conexão (acctstoptime IS NULL).
Não levando em consideração a possibilidade de uma falha no concentrador / radius ou mesmo
uma falha de comunicação entra o Concentrador e o Radius.

Uma forma simples de corrigir isso seria adicionando a verificação do MAC, permitindo que
mesmo com uma sessão em aberto, se a requisição estiver vindo com o mesmo MAC, permita a
autenticação, evitando assim que um cliente não consiga conectar mesmo que seja uma
requisição legítima pós falha.

Uma correção que criei, apenas adiciona nessa query a comparação com o MAC, negando apenas
se o MAC for diferente.

Adicionando essa linha na query: " AND CallingStationId != ‘%{Calling-Station-Id}’ "
ficando assim:

simulverifyquery = "
SELECT
radacctid, acctsessionid, username, nasipaddress, nasportid, framedipaddress,
callingstationid, framedprotocol
FROM ${acct_table1}
WHERE username = ‘%{SQL-User-Name}’
AND CallingStationId != ‘%{Calling-Station-Id}’
AND acctstoptime IS NULL"

Faz com que a sessão que tenha uma nova requisição partindo do mesmo MAC consiga conectar
sem necessidade de verificação extra.

A sessão anterior vai sim ficar em aberto e isso não é um problema em si.

O ERP para informar se uma sessão está em aberto ainda, precisa melhorar a forma que consulta a
tabela radacct, precisa levar em sondideração as colunas “acctstarttime”, “acctupdatetime”,
“acctstoptime” e “acctinterval”.

Verificando a última atualização “acctupdatetime” o intervalo da atualização “acctinterval”
comparando com a hora atual, consegue tem uma informação mais refinada com base no “Interim Update”

Um exemplo, o concentrador está configurado para um atualizar as informações de 5 em 5 minutos
(acct-interim-interval = 300 no accel-ppp e Interim Update no mikrotik), vai está constando na
tabela radacct a data e hora da ultima atualização, e o intervalo entre cada atualização.
Só com isso já se sabe em quanto tempo ocorre a atualização, usando essa informação pode comparar
com a hora atual e verificar se passou do tempo do intervalo da ultima atualização com a hora da
ultima atualização, são 3 dados a se comparar, ultima atualização, intervalo entre atualização e
hora atual. uma simples consulta na tabela radacct de forma mais eficiente, daria mais precisão
a imformação se o cliente está conectado ou não.

Cabe ao desenvlvedor melhorar isso.

Podendo completar essa precisão com uma requisição CoA sem parametro.
O ERP envia um comando “radcliente” tipo CoA sem parametro na porta 3799
(incomming no mikrotik , dae-server no accel-ppp ou simplesmente DM/CoA do radius)
exemplo : “echo User-Name=[user-name do pppoe/ipoe] | radclient [ip do concentrador] CoA [secret]”
Tratando o retorno: Se não retornar nada, sessão está ativa, por tanto conectado.
Se retornar “Error-Cause = Session-Context-Not-Found” , cliente não está conextado.
Forma simples e rápida de ter exatidão, eu utilizei uma extensão do PHP para o radius
então eu apenas criei uma função usando essa extensão para enviar o comendo sem nem precisar
usar um comando no sistema, quer dizer que ainda é muito mais rapido, a precisão é 100%.

O problema de verificar uma rotina agendada de verificação.

O Interim Update não é fixo em 5 minutos, pode variar dependendo do administrador.
Então se basear em 5 minutos fixo como está no mkauth atualmente para encerrar
“sessões presas” periodicamente não ajuda em nada, podendo encerrar sessões que ainda
estão conectadas, apenas não chegou no tempo de atualizar ainda, tem que ser consultado
em “acctinterval” pois este pode ser individual, pode ter tempo diferente por sessão.
Essa opção por sí só é desastrosa e não se faz necessário se a correção na função
“simulverifyquery” for feita como foi descrita aqui (adicionando a comparação do MAC).

Eu já tenho diversos clientes rodando MKauth com essa correção e diversos com SGP, passei
para eles tambem essa correção, mas estes só fazem se o cliente solicitar, não deixaram por
padrão, como no mkauth consigo acesso ao terminal, eu consigo aplicar essa correção.

Porem esta é desfeita por alguns procedimentos básicos de mkauth, com atualização e
restaurar backup, simplesmente desmancha o que fiz, causando o mesmo transtorno.

Tenho caso de MKAuth autenticando até huawei, criei uma simples rotina que converte o
controle de banda do Mikrotik para o do Huawei, nada de extraordinário, usei apenas o
Unlag do freeradius mesmo.

Questão do IPoE.

O IPoE não difere em nada em termo de auth, accouting e disconect/CoA
O lado do cliente, nada mais é que um “Cliente DHCP”, no lado do servidor é só
um DHCP Server com accouting.

Como sou desenvolvedor, foquei um pouco mais no IPoE por não ter o Mikrotik
como concorrente direto, eu estava apresentando tanto um Concentrador PPPoE mais eficiente como
um Concentrador IPoE muito mais barato que um Cisco / Huawei / Juniper.

Um dos impecílios que todos alegam é a questão de identificar um cliente apenas com
Circuit-ID ou MAC, todos acostumados a ver um “nome amigável” no usuario PPPoE passaram a ver
números em hexa, então me perguntaram se seria possível por o nome do cliente na lista de conectados.

Sim, é possível, porem esta informação tem que vir do Radius
Eu adicionei um patch no código do accel-ppp e criei um atributo no radius:
ATTRIBUTE SRouter-IPoE-Alias 204 string

Este sendo enviado como reply junto com controle de banda, após a autenticalção,
faz com o que o concentrador accel-ppp (com meu patch) exiba um nome amigável na lista de conectado,
Foi adicionado uma coluna “user-alias” na saída do comando accel-cmd show sessions.

Certamente isso não atende a maioria dos usuarios do MKauth, porem se eu tornar este patch que criei público,
todos que utilizam o MKauth com accel-ppp teriam um IPoE mais amigável na lista de conectados.
Eu fiz diversas modificações no código do accel-ppp para que se tornasse compatível com
sistemas ERP que somente sabiam o que era mikrotik, eu consegui tal compatibilidade, funciona bem.

Caso tenha interesse tenho mais detalhes sobrte diversas melhorias que podem ser feitas
na parte de autenticação do freeradius.

Esta correção que fiz é a forma mais básica possível, tem eficiencia comprovada.
Ainda assim existe uma mais eficiente que também desenvolvi e testei em produção por um bom tempo no
mkauth , esta não deixa uma sessão em aberto, tanto se corrige como envia um disconnect para garantir que não existe uma
sessão duplicada por um clone de MAC.

É uma forma muito mais complexa e muito mais eficiente, não deixa falhas.

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

  • estou trabalhado em uma solução para ter classes configuraveis para cada tipo de roteador...

  • dica valiosa, obrigado...

  • Interessante, eu ja usei o accel-ppp um tempo e acabei voltando para o Mikrotik, seria legal testar esse seu esquema e ver como fica.

    Tambem sou programador em varias linguagens, eu vi que o mkauth tem bugs e por isso nem atualizei o sistema para esses novos updates para nao comprometer o provedor aqui, eu ate pernsei em criar um ERP do zero com o mais atual em progamação backend and frontend usando GoLang para API e Vuejs ou Reactjs no frontend, mas isso seria um trabalho grande para criar tudo do zero... mas concerteza seria algo fora do normal comparado com todos esses ERPs que existe hoje com codigos e abordagens antigas.

  • Bom dia,

    O sistema tem muito a que ser melhorado e otimizado.

    A grande questão é que existem muitos, MUITOS problemas acontecendo e não tem tempo hábil para corrigir e ao menos otimizar o sistema.

     

    Foram muitas atualizações com focos desnecessários e criando problemas grandes que acredito que muito deles, eles nem sabem o porque do tal..

     

    Acredito que não está sendo interessante manter o MK Auth para o Pedro, por isso fica essas demandas enroladas para ser resolvidas.

    Só para comparar, você acha que precisaria desses tanto de addons sendo criado para personalizar o sistema?

    Isso seria diretamente recursos do próprio sistema e não de colaboradores personalizando tal.

This reply was deleted.