Planos Night e Turbo: Procurando uma solução efetiva!

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

 

 

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

Join MK-AUTH

Enviar-me um email quando as pessoas responderem –

Respostas

  • seria muito bom, esses recursos estão entre os que mais ocorre problemas e preciso fazer o plano turbo funcionar em todos os provedores pois é em cima dele que irei fazer o controle de franquia para incluir no sistema, obrigado pela ajuda Jossy...
  • 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.

     


  • Nesse caso ainda é preciso colocar manualmente os ips que usam plano turbo na address list do mirkotik?

    Alisson Jonas da Silva disse:

    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.

     


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

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

     

  • acompanhando...........ops!! (aqui aguardando solução do Pedro)
  • 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:

    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:

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

     

  • É automatizado e os parâmetros fazem parte do processo de autenticação.
  • 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:

    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:

    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:

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

     

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

This reply was deleted.