Procurando uma solução que fosse ao mesmo tempo simples de ser implementada e de grande eficiência comparados aos gateways mais sofisticados que empregam bancos de dados e etc, cheguei a esta solução ideal para ser usada em provedores wireless ou a cabo. Ela ainda está em desenvolvimento e dada a sua enorme simplicidade de seu conceito pode servir de base para projetos mais elaborados.
O controle de banda é essencial para provedores, especialmente a provedores wireless onde o tráfego precisa ser restringido no que tange velocidade no nó que vai do gateway até o cliente e não apenas do gateway para fora, sob pena dos APs ou bridges travarem por excesso de tráfego. Eu particularmente prefiro implementar APs baseados em PCs onde em um único AP coloco todos os serviços necessários... DNS, proxy Squid e autenticação, mas essa não é a realidade da maioria dos pequenos provedores que não raro pertencem a pessoas que sequer são da área de TI e que adquirem equipamentos baseados no "vox populi".
Esta técnica de controle de banda é muito eficiente, pois permite que você coloque um grande quantidade de clientes em bridges de baixíssimo custo, eu mesmo fiz isso em um condomínio onde ficam pendurados 71 clientes em um AP Ovislink WL-5460AP que é considerado um AP ordinário, mas que de ordinário só tem seu gabinete que parece uma saboneteira!
Primeiramente vamos criar as classes raízes do controle de banda. Podemos colocar estas linha no nosso /etc/rc.d/rc.local:
/sbin/tc qdisc del dev eth0 root #2> /dev/null
/sbin/tc qdisc add dev eth0 root handle 1 cbq bandwidth 100Mbit avpkt 1000 cell 8
/sbin/tc class change dev eth0 root cbq weight 10Mbit allot 1514
/sbin/tc qdisc del dev ppp0 root #2> /dev/null
/sbin/tc qdisc add dev ppp0 root handle 1 cbq bandwidth 2Mbit avpkt 1000 cell 8
/sbin/tc class change dev ppp0 root cbq weight 200Kbit allot 1514
Em meu caso ppp0 é uma PPPoE de um serviço ADSL de 2Mb/s.
Agora criaremos um script para controlar a banda de cada uma das estações de nossa rede. Este script deve ser iniciado junto com a máquina e após as interfaces de rede estarem levantadas
#!/bin/bash
#IP 192.168.10.10 128K download 100K upload
/sbin/tc class add dev eth0 parent 1: classid 1:a cbq bandwidth 100Mbit rate 128Kbit weight 12Kbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded isolated
/sbin/tc qdisc add dev eth0 parent 1:a handle a tbf rate 128Kbit buffer 10Kb/8 limit 12Kb mtu 1500
/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 200 handle a fw classid 1:a
/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.10.10 classid 1:a
/sbin/tc class add dev ppp0 parent 1: classid 1:a cbq bandwidth 2Mbit rate 100Kbit weight 10Kbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded isolated
/sbin/tc qdisc add dev ppp0 parent 1:a handle a tbf rate 100Kbit buffer 10Kb/8 limit 15Kb mtu 1500
/sbin/tc filter add dev ppp0 parent 1:0 protocol ip prio 200 handle a fw classid 1:a
#IP 192.168.11.10 512K download 100K upload
/sbin/tc class add dev eth0 parent 1: classid 1:b cbq bandwidth 100Mbit rate 512Kbit weight 51Kbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded isolated
/sbin/tc qdisc add dev eth0 parent 1:b handle b tbf rate 512Kbit buffer 10Kb/8 limit 15Kb mtu 1500
/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 200 handle b fw classid 1:b
/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.11.10 classid 1:b
/sbin/tc class add dev ppp0 parent 1: classid 1:b cbq bandwidth 2Mbit rate 100Kbit weight 10Kbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded isolated
/sbin/tc qdisc add dev ppp0 parent 1:b handle b tbf rate 100Kbit buffer 10Kb/8 limit 15Kb mtu 1500
/sbin/tc filter add dev ppp0 parent 1:0 protocol ip prio 200 handle b fw classid 1:b
#IP 192.168.12.10 1024K download 100K upload
/sbin/tc class add dev eth0 parent 1: classid 1:c cbq bandwidth 100Mbit rate 1024Kbit weight 102Kbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded isolated
/sbin/tc qdisc add dev eth0 parent 1:c handle b tbf rate 1024Kbit buffer 10Kb/8 limit 15Kb mtu 1500
/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 200 handle c fw classid 1:c
/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.12.10 classid 1:c
/sbin/tc class add dev ppp0 parent 1: classid 1:c cbq bandwidth 2Mbit rate 100Kbit weight 10Kbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000 bounded isolated
/sbin/tc qdisc add dev ppp0 parent 1:c handle b tbf rate 100Kbit buffer 10Kb/8 limit 15Kb mtu 1500
/sbin/tc filter add dev ppp0 parent 1:0 protocol ip prio 200 handle c fw classid 1:c
[1] Comentário enviado por removido em 27/07/2007 - 15:57h
Olá Amigo,
Bom, para deixar seu artigo ainda mais rico eu gostaria de dar uma opinião! No caso de um hijack bem feito (roubo de seção), quando o cliente cai e em seguida entra o hijack seu arping vai consultar ele tranqüilamente! Concorda!? Espero que sim, pois eu já fiz testes com isso e infelizmente da certo! A solução é simples, ao invés de fazer o servidor consultar quem está de pé ou não, o que dependendo do número de estações tem um tempo elevado, eu sugiro mudar para o comando at. Como já uso o servidor Radius, foi fácil, no comando AT eu agendo uma verificação pra saber se o IP tal é do fulano de tal conectado no radius, aí sim, se não for a regra dele é derrubada! Pra substituir o uso do radius, pode-se pensar em cookie, por exemplo!
[2] Comentário enviado por capitainkurn em 27/07/2007 - 17:50h
Boa! nem havia me ocorrido o at.
Quando elaborei aquele while de arping, pensei em coloca-los isoladamente rodando sob um shell filho do mac_accept4.cgi que seria chamado em background, mas esbarrei em um problema... não entendí ainda o por que de não conseguir rodar um loop em um shell filho a partir de um CGI, mas é uma coisa que estou bolando e a sua idéia do at foi grande.
Obrigado pela dica, e espero que tenha gostado do artigo.
[4] Comentário enviado por capitainkurn em 23/04/2008 - 10:03h
É mais fácil ainda, a única razão para eu atrelar o ip ao mac address é o controle de banda, pois provedores em geral possuem planos de velocidade diferentes e se não houver vínculo entre o IP e o login e senha o usuário poderia configurar um IP manualmente e usar uma velocidade maior do que a contratada.
[5] Comentário enviado por cleibson em 03/05/2009 - 22:57h
Como o cliente será diretionado para autenticação, sendo que não há nenhuma regra redirecionando sua navegação para a porta 443 obrigando-o a autenticar antes de navegar
[7] Comentário enviado por douglassironi em 28/06/2011 - 18:38h
Sobre a questão de atrelar MAC, podemos fazer isso com PHP, no momento que o cliente se cadastra e cria seu usuario e senha, podemos tranquilamente pegar o MAC dele com a função, abaixo tem um link explicando como fazer.