Pessoal,
O Pedro deve já estar de saco cheio de meus palpites, mais fazer o quê? lá vai mais um:
Recentemente foi implementado um novo método de bloqueio, que apesar de bem funcional gerou polémica e grande discussão, principalmente quando o Pedro resolveu de vez remover o método antigo do sistema. De toda forma acho que todos vão chegar a conclusão de que ficou melhor e mais profissional, no entanto um problema ainda persiste: Planos Night e Turbo.
Bem pessoal,
Acho que poderiamos aplicar a mesma solução utilizada no novo método de bloqueio, a transferência de parâmetros pelo radius para que o mikrotik possa tratá-los depois.
Um cliente que recebe um parametro com a descrição "night" (mikrotik-mark-id ou mikrotik-Adress-List) poderia ter esse parametro tratado por regras de firewall ou marcação de pacotes para ter controlada sua banda ou avisado do término da sessão.
De fato ficaria mais simples para o mk-auth e a inclusão deste parametros inclusive não traz tanstornos aos usuários da forma atual, no entanto, a definição dos horários e do controle de banda dependeria de definições no mikrotik.
Todavia, se houver interessados em tentar essa alternativa, proponho tentar adptá-la usando programação sql na base dados, de forma a testarmos antes de dar trabalho Pedro.
Acredito que isso pode ser uma solução definitiva para os planos night e turbo. To esperando as "cobaias"!
Respostas
Realmente a solução é ideal, e é muito importante q se mantenha o horário do servidor mikrotik atualizado, pois já ajudaria muito.
Regra que pode ser usada em plano turbo tanto com mikrotik-mark-id quanto address-list:
/ip firewall mangle
add action=mark-packet chain=prerouting comment="DIAS E TEMPO TURBO" \
disabled=no new-packet-mark=turbo1 packet-mark=turbo passthrough=no \
src-address-list=turbo time=1s-6h,sun,mon,tue,wed,thu,fri,sat
EXPLICAÇÃO: Peguei o Addres-List Turbo e Mark-id com nome turbo e tranformei na marcação turbo1 apenas nos dias e horarios escolhidos, que no caso seria todos os dias da 00:01H às 06:00H.
/queue type
add kind=pcq name=turbo pcq-classifier=dst-address pcq-limit=50 pcq-rate=\
1000000 pcq-total-limit=2000
DESCRIÇÃO: Criei um um queue type no qual cada usuario do mesmo receberá uma banda de 2Mb
/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 \
max-limit=0 name=TURBO packet-mark=turbo1 parent=global-out priority=8 \
queue=turbo
E por último a queue-tree que libera o turbo aos clientes.
Dessa forma os dias e horários são setados no Mikrotik, necessitando vir do MK-AUTH apenas os parametros, mas tbm o MK-AUTH pode enviar os parametros apenas no horário determinado pelo mesmo.
Sendo setado horário no Mikrotik a banda é liberada e cortada sem necessidade de desconexao do cliente.
Fiz rápido aqui pois foi a primeira idéia que me veio a cabeça.
A mesma idéia pode ser usada pra o plano Night, alterando pouca coisa.
Alisson Jonas da Silva disse:
Desculpa, li novamente e entendi: "Dessa forma os dias e horários são setados no Mikrotik, necessitando vir do MK-AUTH apenas os parametros, mas tbm o MK-AUTH pode enviar os parametros apenas no horário determinado pelo mesmo."
Agora só falta o Pedro fazer com o que o MK-AUTH passe os parametros para o mikrotik...
Aguardando entao essas mudanças no sistema e se possível fazer com que os logins adcionais compartilhem a velocidade da conta principal...
Lucas,
Acho que vc entedeu sim a semântica da coisa, no entanto, enviar comandos radius ao mikrotik depois que o cliente já está autenticado (parametros CoA) também é meio problemático, tal forma que talvez o mais prático seja enviar parametros no momento da autenticação mesmo.
* Utilizar comando (CoA) para o usário já autenticado pode trazer as mesmas desvantagens do uso do ssh, porque sempre será necessário especificar o NAS e ainda correr o risco de falha na comunicação, principalmente porque a porta 3799 "ouve" atravez de protocolo udp que não possui controle de erro.
Lucas Alexandre disse:
Olá Jossy, boa noite!
No caso da solução proposta por Alisson, esses parâmetros seriam passados por SSH né? O ip do cliente seria passado como parâmetro para as address list turbo ou pgnight (de acordo com cada caso). Bem, já foi discutido muito aqui no fórum sobre a problemática de passar parâmetros pelo ssh, mas acho que nesse caso seria algo que resolveria o problema em questão e as conexões ao SSH do mikrotik não seriam muitas, já que a grande maioria dos clientes dos provedores são de perfil simples.
Jhonne Jossy disse:
Não lucas! Os parametros seriam repassados via radius mesmo, no momento da autenticação, o Alíssom colcou em prática (muito bem por sinal) a idéia inicial relatada no tópico.
Lucas Alexandre disse:
Agora...
Será preciso instalar um servidor NTP no mk-auth e ensinar o pessoal configurar, senão já viu neh, o mikrotik fica com a hora errada e quem paga o pato é o Pedro.
-
1
-
2
-
3
de 3 Próximo