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.
Costumo fazer redes condominiais onde é necessário que os clientes não se enxerguem por meio da difusão de nomes netbios, por isso costumo atribuir cada IP de cada uma das estações em uma sub-rede separada, mas podemos fazer tudo em uma única separadas pelo domínio de broadcast de uma máscara de sub-rede alta 255.255.255.254 ou /31 por exemplo enquanto o gateway fica em uma máscara mais baixa 255.255.0.0 ou /16. em nosso exemplo usei a primeira técnica.
Então ficamos com o gateway configurado da seguinte forma:
interface interna: eth0 192.168.10.1/16 ou 255.255.0.0;
interfaces externas: eth1 sem IP atribuído e ppp0 obtida por um modem ADSL em modo bridge e um cliente PPPoE. Não mencionarei a configuração do pppoe pois não é o objetivo deste artigo e aqui mesmo no Viva o Linux há inúmeros artigos e dicas sobre isso.
Para simplificar nossa administração empregaremos um servidor DHCP onde o arquivo /etc/dhcpd.conf ficará da seguinte forma.
Atentem para o parâmetro "option domain-name-servers 192.168.10.1; #Bind", é que implemento um DNS cache no próprio gateway, porém não mencionarei neste artigo pelos mesmos motivos que citei acima.
Leiam minha dica sobre uma maneira diferente de escrever o /etc/dhcpd.conf em:
Quando trabalhamos com um número elevado de subredes pode ocorrer o neighbor table overflow, não se assustem com isso, a solução está em uma dica minha aqui mesmo no VOL em:
[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.