Página 2 de 2 PrimeiroPrimeiro 12
+ Responder ao Tópico



  1. #21

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Www.scut.com.br

    Enviado via MotoG3 usando UnderLinux App

  2. #22

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Citação Postado originalmente por sgnetararuama Ver Post
    Mais o que mais se vê no fórum é o pessoal reclamando que a nova versão ficou um pouco inviável, por consumir processamento demais.
    A maioria tinha que trocar as RB´s, pois mikrotik não tinha meio termo, ou era fraca ou forte demais, hoje ja algumas versões intermediarias.
    Eu tenho RB 750 segurando quase 50 clientes online, com consumo médio de 20 Mb e tenho RB 750GL segurando 100 clientes, com consumo médio de 60Mb, tudo usando PPPoE.
    Com certeza com webmikrotik eu não consigo isto, pelo que vi de amigos que usam
    Temos 850G com 30 mega de consumo e cerca de 130 online em média. Processamento 25 a 30%

  3. #23

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Olha estou usando o Webmikortik é show, o suporte dos caras é nota 10.

  4. #24

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Uso o MK Auth em nuvem a dois anos com uma empresa que contratei. Nunca tive uma queda na VPN que faz a conexão. E mesmo que caia a conexão temos todos os usuários pppoe cadastrado no MK, exportado do MK AUTH. Com a mudança do servidor local para a nuvem, tive uma redução na conta de energia e nunca mais tive que me preocupar em servidor travando, ou qualquer problema de Hardware no mesmo. Aqui é tudo tranquilo.

  5. #25

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Citação Postado originalmente por FMANDU Ver Post
    Uso o MK Auth em nuvem a dois anos com uma empresa que contratei. Nunca tive uma queda na VPN que faz a conexão. E mesmo que caia a conexão temos todos os usuários pppoe cadastrado no MK, exportado do MK AUTH. Com a mudança do servidor local para a nuvem, tive uma redução na conta de energia e nunca mais tive que me preocupar em servidor travando, ou qualquer problema de Hardware no mesmo. Aqui é tudo tranquilo.
    Cara, tu tocou num ponto fundamental... Não centralizar. Quando usei este que você usa hoje, quando se falava em servidor remoto, em nuvem muitos caiam em cima. Diziam que tinha que ser centralizado, ter tudo na ponta dos dedos para qualquer eventualidade.
    E daí meu, quando parava um servidor local era aquela correria até colocar novamente no ar. Cliente telefonando e a gente trabalhando para resolver... Ufa.
    Até que descobri o Webmikrotik em 2008, um dos primeiros a trabalhar com o conceito de servidor remoto. Nunca mais me incomodei com gerenciador atrapalhando a rede.

    E vejo que hoje muitos desenvolvedores optaram por usar servidor remoto.
    Cansei de dizer aqui, até ao ponto de uns me acusarem de estar ganhando em cima. kkk, ledo engano. É que quando via críticas até de quem nunca tinha usado, não podia me calar.
    Talvez não seja "aquele" gerenciador super dotado. Mas tem tudo para que o dia/dia seja tranquilo. Não dá para ficar perdendo tempo e energia em volta de gerenciador. Ele precisa ser transparente para nós no dia/dia.
    E vários gerenciadores hoje já são assim. Nunca diria que o webmikrotik é o melhor. Longe disso. Mas é fácil de um funcionário treinar a operação dele. Todas as informações sobre o cliente na ponta dos dedos. E automatização das principais rotinas.
    Outra crítica é que não tem suporte 24x7. Mas para que? eu pergunto. Uma vez que o mikrotik que é o servidor de internet continua trabalhando? Trabalha de forma independente. Então este negócio que já ouvi dizer que ficou com o provedor parado porque não conseguiu suporte no fim de semana não se sustenta.

    Eu tenho um conceito sobre gerenciadores. O melhor é aquele que te atende no que precisa. O que é bom para um pode não ser o ideal para outro.
    Mas daí a dizer que tal ou tal gerenciador é um lixo, porcaria, etc etc é um total desrespeito a classe dos desenvolvedores de sistemas.
    O webmikrotik foi um dos que mais recebeu este tipo de crítica. E enquanto isso eu aqui usando "de boa". Iria eu dizer que talvez o problema seja lá no servidor mikrotik do sujeito? Eu não, não conheço como está usando. Só sei que a reclamação de provedor parado por causa dele não é verdadeira. Então só me restava defender polidamente o que uso e respeitar os outros gerenciadores, mesmo ouvido de vez em quando usuários vindo reclamar de alguma coisa relacionada com os gerenciadores que usam.
    Pouquíssimos foram os gerenciadores que nunca ouvi nada contra.
    Cada um tem seus méritos, senão não estariam aí no mercado com seus produtos por tanto tempo.
    O que seria do azul se todos gostassem do amarelo?

    E já vi pessoas que optam por um sistema mais complexo e depois na prática levam um tempão para começar a usar porque o sistema é "complexo". E quando usam não aproveitam a maioria dos recursos.

  6. #26

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Creio que essa seja a verdadeira vantagem de usar um sistema em nuvem...


    Citação Postado originalmente por FMANDU Ver Post
    Uso o MK Auth em nuvem a dois anos com uma empresa que contratei. Nunca tive uma queda na VPN que faz a conexão. E mesmo que caia a conexão temos todos os usuários pppoe cadastrado no MK, exportado do MK AUTH. Com a mudança do servidor local para a nuvem, tive uma redução na conta de energia e nunca mais tive que me preocupar em servidor travando, ou qualquer problema de Hardware no mesmo. Aqui é tudo tranquilo.

  7. #27

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Cara pra vc que está com poucos clientes, começando, sugiro o mikweb que é o que eu ainda utilizo, simples, funcional e de baixo custo. O único problema que me incomoda (e muito) é o sistema financeiro que é fraco demais, não te dá visão além do valor que tem a receber. Depois que passei dos 100 clientes percebi a necessidade de ter um sistema com financeiro um pouco melhor, objetivando maior controle das contas a receber e a pagar (mikweb tem, mas muito fraco), controle de estoque, e outras coisas que qualquer ERP meia boca tem...

    O Webmikrotik aparenta ter um sistema um pouco melhor no geral, mas infelizmente não cheguei a usar devido o atendimento deles não ter solucionado um problema na importação dos usuários da minha RB, entre outros problemas relacionado a atendimento até acabar o prazo para teste. Quem sabe você tem mais sorte do que eu...

  8. #28

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Entao, hoje estou com um pouco mais de 230 clientes, minha vps não chega a 10% de processamento, meu serviço cloud é bem barato e estável, e esta no brasil, latência baixíssima. Depois do meu ultimo estresse com placa mae queimando no CPD, resolvi partir pra nuvem e mesmo que vps pare, meus clientes continuam ativos como se nada tivesse acontecido.

    Citação Postado originalmente por dmarcio Ver Post
    Creio que essa seja a verdadeira vantagem de usar um sistema em nuvem...

  9. #29

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    @FMANDU Bom dia.

    Então se a VPS cair nada acontece com o mikrotik? E se reiniciar o mikrotik com a VPS caída, os usuários autenticam? O MK funciona independente mesmo o servidor Radius estar off? Tenho essa dúvida...

    Mas me diz aí onde está hospedando essa VPS?

    Um abraço.
    Márcio.



    Citação Postado originalmente por FMANDU Ver Post
    Entao, hoje estou com um pouco mais de 230 clientes, minha vps não chega a 10% de processamento, meu serviço cloud é bem barato e estável, e esta no brasil, latência baixíssima. Depois do meu ultimo estresse com placa mae queimando no CPD, resolvi partir pra nuvem e mesmo que vps pare, meus clientes continuam ativos como se nada tivesse acontecido.

  10. #30

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Nativo no mk-auth não! Mas eu fiz meu scripts que lêem o banco e geram um arquivo para importar dentro de qualquer mk!

    Enviado via XT1563 usando UnderLinux App

  11. #31

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Citação Postado originalmente por andrecarlim Ver Post
    Nativo no mk-auth não! Mas eu fiz meu scripts que lêem o banco e geram um arquivo para importar dentro de qualquer mk!

    Enviado via XT1563 usando UnderLinux App


    Nativo, sim!




    MK-Auth tem uma API PHP, que pode ser acessada de dentro da RB por uso do fetch e ela retorna um script do RouterOS que ao ser armazenado em um arquivo e executado insere os secrets e profiles (PPPoE), leases, etc. (não lembro se tem para hotspot).



    Tem um script PHP para cada tipo de dados (PPPoE, DHCP, ARP, etc.).

  12. #32

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Bom saber! Agora ensina aew como faz, eu não fazia ideia que isso era possível no mk-auth...

    Enviado via XT1563 usando UnderLinux App

  13. #33

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Citação Postado originalmente por andrecarlim Ver Post
    Bom saber! Agora ensina aew como faz, eu não fazia ideia que isso era possível no mk-auth...

    Enviado via XT1563 usando UnderLinux App
    Basta criar um script que faça fetch de uma URL no seguinte formato:

    Código :
    http://<IP_DO_MKAUTH>/api/<API_DESEJADA>.php?key=<TOKEN>&ramal=<RAMAL>

    <IP_DO_MKAUTH> é auto explicativo.

    <API_DESEJADA> pode ser:
    - mkt_arp (entrada ARP para cada cliente e seu IP)
    - mkt_dhcp (lease no servidor DHCP para cada cliente)
    - mkt_hotspot (profiles e users/clientes do Hotspot)
    - mkt_ip (endereços IP da RB - não parece ter a ver com clientes, nos meus testes o script veio vazio, apenas com a parte de remover IPs adicionados anteriormente pela API, como é feito em todas, então não entendi bem)
    - mkt_pgaviso (IPs de clientes atrasados na address-list pgaviso)
    - mkt_pgcorte (IPs de clientes bloqueados na address-list pgcorte)
    - mkt_pppoe (profiles e secrets/clientes do PPPoE)
    - mkt_queues (queues dos clientes)
    - mkt_wifi (entrada na access-list para cada autorizar/bloquear conexão do cliente ao rádio MikroTik)

    <TOKEN> é obtido no MK-Auth, no final da página "Dados da Empresa".

    <RAMAL> é o IP da RB onde os clientes são autenticados/controlados. O IP deve corresponder ao utilizado ao cadastrar a RB em "Controle de Servidores". Pode ser usado "todos", caso queira obter as informações para todas RBs cadastradas.

    Até hoje somente utilizei mkt_pgcorte, mkt_pgaviso e mkt_pppoe. As duas primeiras são muito simples, pois uma vez que você tem o IP do cliente atrasado ou bloqueado na respectiva address list, basta fazer as regras do firewall para bloqueio ou redirecionamento baseado na lista.

    Já em relação à mkt_pppoe, precisa criar na RB um pool chamado Local-1. Esse pool é usado como local-address nos profiles. O problema é que não faz sentido ter vários IPs nesse pool, senão vai usar 2 IPs para cada cliente (a cada cliente autenticado é usado 1 IP desse pool para a RB, além do IP do cliente), então o ideal seria colocar apenas 1 endereço nele. No entanto, fazendo isso os clientes não autenticam, pois a RB não consegue determinar o endereço local (estranhamento aparece no log que o problema é no remote-address, vai entender esse monte de bugs do RouterOS...).

    A solução para isso é inserir, no script ou no scheduler, logo após receber e cadastrar os profiles e secrets, um novo comando alterando nos profiles o local-address para o IP desejado, no lugar do pool Local-1.

    Além do pool Local-1, é preciso criar um chamado Remoto-1. Esse é o pool de onde o IP dos clientes é obtido. No entanto, ele é simbólico, uma vez que o IP dos clientes é definido no campo remote-address dos secrets cadastrados, com base nos endereços que constam no MK-Auth.

    Uma observação: os secrets vêm desabilitados por padrão. Isso é útil para quem usa MK-Auth em cloud, ou talvez até mesmo local, e queira ativar esses secrets para autenticação local apenas no caso de perder comunicação com o Radius (por meio do Netwatch). Ou pode também ativar todos eles logo após serem cadastrados, no scheduler ou no script, assim a autenticação será sempre local.

    Outras APIs talvez tenham que fazer pré-configurações e ajustes, semelhante ao caso da mkt_pppoe.

    Ah, sim, no script, o fetch e a execução do script são feitos conforme o seguinte:

    Código :
    /tool fetch mode=http url="URL_DA_API_CONFORME_DESCRITO" src-path=<API_DESEJADA>.php dst-path=<API_DESEJADA>.rsc;
     
     :if ( [/file find name=<API_DESEJADA>.rsc] != "" ) do={
     /import <API_DESEJADA>.rsc;
     /file remove <API_DESEJADA>.rsc;
    };

    Por meio do scheduler, isso aí é repetido a cada um dado tempo. Para o caso de apenas fallback para ocorrência de perda de comunicação com o Radius, o tempo re reiteração da execução pode ser alto, 6 ou 12 horas, por exemplo. Já se for para a forma de autenticação principal ser localmente, tem que ser mais frequente para manter a consistência com inserções de alterações de clientes.
    Última edição por TsouzaR; 03-09-2016 às 01:56.

  14. #34

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Exatamente o mk funciona totalmente independente, caso o RADUIS venha a cair. Todos os usuários pppoe ja ficam cadastrados em ambos. Caso a vpn caia, o mk através de script, ativa todos os usuarios.

    Citação Postado originalmente por dmarcio Ver Post
    @FMANDU Bom dia.

    Então se a VPS cair nada acontece com o mikrotik? E se reiniciar o mikrotik com a VPS caída, os usuários autenticam? O MK funciona independente mesmo o servidor Radius estar off? Tenho essa dúvida...

    Mas me diz aí onde está hospedando essa VPS?

    Um abraço.
    Márcio.

  15. #35

    Padrão Re: Um gerenciador de provedor que não precise de maquina para instalação

    Pela quantidade de clientes sai vantajoso instalar um sistema em nuvens podendo como será nas nuvens pode configurar um período mais longo das alterações rádios tipo 30 minutos ou mais (como temos o mk auth local virtualizado) deixamos essas alterações em tempo real

    Enviado via Moto G (4) usando UnderLinux App