+ Responder ao Tópico



  1. Citação Postado originalmente por Michael
    ....
    Sérgio, está controlando sim!!! tenta colocar essas mesmas regras de mangle na chain " POSTROUTING " com crtza vai dar certo!!! :good: :good:
    Blz Michael, vou rever as regras aqui para o POSTROUTING (pois jah tem um POSTROUNTIG no codigo ae em cima..) e depois posto o resultado aqui. :good:

  2. Pelo que pude verificar, no postrouting nao adiantaria marcar os pacotes pela roda a ser usada já estar definida... vale à pena verificar a veracidade da informação...



  3. #43
    Avenger
    Jim,

    Vai ver tem alguma outra regra antes da regra que você tá colocando prá marcar, que esteja absorvendo o pacote, então não esteja por isso marcando os pacotes. Tenta o seguinte, ao invés do iptables -A, usa iptables -I prá inserir a regra no início da corrente PREROUTING da tabela mangle. iptables -nvL PREROUTING -t mangle e vê se finalmente incrementa. Se não, vai simplificando com um -j LOG, de repente o layer7 não detecta pacotes ao-serem-criados como http, daí a regra talvez tenha que estar na corrente FORWARD (se é que a forward da mangle aceita MARK).

    De qualquer forma, pode ser que a 'pattern' http seja diferente, quando passa na prerouting, e quando passaria em outra corrente. O que você faz, como disse, prá ver se o pacote tá mesmo 'chegando' até a regra que você fez, é, ao invés de colocar ela, colocar um -j LOG -s 192.168.7.100 ... e talvez até colocar a regra do l7 após a log. (LOG não absorve o pacote, ela loga e deixa o pacote continuar passando pelo restante das regras da corrente.

    Daí se você ver que o -j LOG incrementa (ou fica aparecendo no 'dmesg') mas a do layer7 não pega, o problema pode tar no pattern que vc tá usando. Eu não sei direito como é, mas parece que determinada conexão TCP passa na PREROUTING só enquanto está começando a conexão, e a maioria dos pacotes http iriam passar pelo forward (a vantagem de barrar no prerouting é porque ia cortar o mal pela raiz).

    Espero que ajude! :P

    Agora expressando minha idéia sobre o que o pessoal aí falou sobre barrar, bloquear, e mandar clientes prá aquele lugar, minha iniciativa foi, sendo nós provedores de acesso, fazer como a Telemar no Velox. Oferecemos a banda: o cliente faz o que quiser com ela. Pode entrar ne IRC, msn, abrir 65536 conexões nos mais diversos kazaa's da vida... (só espero que nossos switches aguentem a quantidade de pacotes por segundo!..). Mas eles não passam da banda. Como eu não confio em qdiscs, eu uso regras baseadas no iproute2 e o módulo shaper, que só faz limitações de 1bps a 1Mbps, em geral fornecendo 128k de download e 96 ou 64k de upload. E o link é dedicado: 128k a cada usuário, e não 128k para um prédio inteiro. E não tem nada de empréstimo de banda. é os 128k e pronto hehe.

    Meu único problema com essa limitação pelo shaper, é que o único jeito que achei de limitar o upload dos clientes é bastante limitado, eu só posso fazer no máximo 255 canais limitados -- geralmente suficiente em cada local em que temos firewall linux segurando -- implementei esse sistema de limitação até em LRP (fiz um pacotinho pro bering).

    Aproveitando a mão: alguém aqui já ouviu dizer que, fazendo limitação de banda com o HTB/CBQ, há uma margem de falha na limitação na qual, um usuário com muitas conexões abertas, pode prejudicar o dos outros ou exceder o próprio link delegado a ele?

  4. Aí... eu concordo com o Brenno...

    aqui na empresa, uso squid com regras de iptables...

    perfeito... não conecta MSN, kazaa, e outros do gênero...

    bloqueio também, todos sites de proxy que consigo ter acesso, assim o usuário não tem como conectar...

    [ ]´s
    Mauzão



  5. Citação Postado originalmente por Jim
    Pelo que pude verificar, no postrouting nao adiantaria marcar os pacotes pela roda a ser usada já estar definida... vale à pena verificar a veracidade da informação...
    :clap: :clap:
    É isso ai!!! vc tem toda razão " vale à pena verificar a veracidade da informação... "
    :toim: :toim: :toim: :toim: :toim: ufffff!!!!!!

    " Prove-nos o contrário da informação que eu dei JIM"
    da pra perceber que desde o inicio o seu l7 não ta funfando corretamente,
    não ta aplicando as regras em todas as chains, como lhe falei antes pode ser a versão Default do Kernel do seu Debian que não tem patch do l7 desenvolvido pra ela, e isso pode ta causando o funcionamento inadequado do seu l7...

    Da uma checada nesse end. http://sourceforge.net/project/showf...kage_id=109674

    Não existe nenhuma versão do l7 com patch na versão do kernel default que acopanha o Debian 3.1 que vc ta usando, baixe essa versão http://prdownloads.sourceforge.net/l...ar.gz?download
    depois o Kernel - 2.6.11.8, complile com os devidos módulos ativados, remova o iptables default que acompanha o debian #aptitude remove iptables; Depois instale o iptables 1.3.1 que vai funfar perfeitamente em todas as chains que vc precisar! falow!!!

    Se ter alguma dúvida a respeito, quiser ver alguma saida do meu iptables com l7 fique a vontade estou a disposição!!!!!

    :twisted: :twisted: :twisted:






Tópicos Similares

  1. Bloquear Kazaa
    Por valeonline no fórum Servidores de Rede
    Respostas: 2
    Último Post: 12-02-2006, 22:26
  2. Bloquear kazaa
    Por jlbavaresco no fórum Servidores de Rede
    Respostas: 2
    Último Post: 06-03-2005, 09:10
  3. HELP!!! NÃO consigo Bloquear KAZAA.
    Por fdotta no fórum Servidores de Rede
    Respostas: 15
    Último Post: 22-09-2004, 19:45
  4. Bloquear Kazaa e outros serviços P2P
    Por no fórum Servidores de Rede
    Respostas: 6
    Último Post: 12-12-2003, 09:13
  5. Bloquear Kazaa e ICQ?
    Por no fórum Servidores de Rede
    Respostas: 1
    Último Post: 27-11-2002, 15:04

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L