P2P criptografado, um novo desafio!

[FabricioViana]

Ja faz um tempo que o Bittorent e outros p2p estao fazendo conexoes criptografadas para fugir do controle feito através do layer7 (seja do linux "puro" ou seja de distribuições feito Mikrotik).

Alguém já conseguiu segurar esse tráfego?

Pensei em arrumar uma forma de marcar todas as conexoes que fossem criptografadas, mas ainda nao achei como.

Obrigado!
Fabricio

[PatrickBrandao]

Bom dia Fabricio,

eu tenho sofrido esse dilema, meus clientes (provedores) solicitam muito controle de p2p mas a coisa esta evoluindo para um nivel alem do nosso controle. Técnicas como limitar p2p serão ultrapassadas, creio que a solução será:

- Limitar número de conexões por usuário
- Fazer controle de banda com buffer bem pequeno (pfifo = 2 ou bfifo = 3000 bytes)
- Usar algoritmos que dividam o trafego de forma distribuida, garantindo banda para todos (SFQ)
- Fazer QoS por ip no roteador, exemplo: IP do proxy pode consumir a vontade, o resto fica limitado, assim o trafego http sempre navegará ao máximo.

Outro problema: sites de compartilhamentos de arquivos (download com HTTP), como existem muitos mirrors, a solução é usar algritmo SFQ mesmo.

[GrayFox]

Hoje, eu controlo as conexoes por cliente (10 conexoes), e controlo a banda por portas.

Alem disso, seria ideal compilar o squid com o "strict http compliant", pois o p2p nao passaria pelo squid.

[leandro17]

mas como eu faço que o trafego http seja o maximo ? faco nat e estou utilizando proxy transparente , tentei fazer estas regras ...mas nao sei se funciona bem.

iptables -t mangle -I POSTROUTING -p tcp --dport 80 -j TOS --set-tos 8
iptables -t mangle -I FORWARD -p tcp --dport 80 -j TOS --set-tos 8

iptables -t mangle -I POSTROUTING -p tcp --dport 3128 -j TOS --set-tos 8
iptables -t mangle -I FORWARD -p tcp --dport 3128 -j TOS --set-tos 8

iptables -t mangle -I POSTROUTING -p tcp --dport 443 -j TOS --set-tos 8
iptables -t mangle -I FORWARD -p tcp --dport 443 -j TOS --set-tos 8

abraços

[Josue Guedes]

Meu controle é feito pelo HTB, limito a velocidade de cada IP, não tem como burlar isso. Se o usuário colocar o Bittorent dele baixando alguma coisa ele vai consumir tudo que tem direito no contrato dele, se ele quiser usar outra coisa, ele que pause o Bittorent. Quando alguém reclama sobre isso explico, que deve-se limitar as velocidades no própio programa.

[LinuxKids]

Não sei, de vocês mas acho que controlar P2P é falta de respeito com o cliente, já que ele contrata a velocidade por exemplo 500Kbps, e faz download em p2p a 15kbps, 5kbps.
Primeiro acho isso ilegal, e segundo desrespeito para com o usuario.
Se estamos provendo o serviço nada melhor do que prover o serviço com qualidade. entrega a banda do cara ele que se exploda se não conseguir navegar e ligar enchendo o saco, ae fala para ele desligar, o P2P.
Mas veja bem isso em para quem controla P2P em provedor, não para uma empresa que tem sua banda limitada e tem usuarios detonando a rede com p2p, nesse caso só a favor até do bloqueio do P2P.

Bom essa é minha opnião. e acho que isso vai dar uma discussão boa.

[GrayFox]

O caso nao é bloqueio de p2p nem controlar a baixo do contratado, e sim limitar os sockets dos p2p para nao detonar com a rede.

[sergio]

O caso nao é bloqueio de p2p nem controlar a baixo do contratado, e sim limitar os sockets dos p2p para nao detonar com a rede.

Justamente, e esse é o grande problema. O tráfego P2P é um veneno para qualquer rede, tanto que se o contrário fosse não existira ninguém trabalhando em ferramentas para contê-los.

O que o Patrick mencionou sobre o SFQ é uma opção uma vez que requer pouco uso da CPU e RAM, além dos algorítimos estocásticos usados na política SFQ priorizarem os pacotes de acordo com configurações, descartando, assim, os demais no caso de saturação no roteador.

[antoni]

Se não controlar o p2p, é humanamente impossível trabalhar em redes wireless. Não se trata de bloquear, mas de manter o p2p e a rede funcionando com qualidade.

[roneyeduardo]

Seguinte pessoal, eu andei monitorando aqui o tráfego da minha rede, e notei que o access log do meu squid começou a mostrar uma quantidade muito grande de: " error:unsupported-request-method"....

Fui atrás e percebi que isso tava acontecendo porque os softwares de p2p criptografados estava tentando a conexão pela porta 80, porém os headers dos pacotes não eram compatíveis com o protocolo HTTP, que é o que o squid espera e o cliente não consegue conectar na rede p2p, tendo que desconfigurar a opção de criptografia. Assim, então, voltam a sofrer o traffic shapping através do layer7 e do ipp2p.

Quanto ao SFQ, seu objetivo é trabalhar na alocação/distribuição da banda de forma justa...mas a maneira como ele é implementado a distribuição da banda ainda se torna "unfair", visto que clientes com um número maior de requisições / conexões conseguem ter mais banda alocada do que clientes com poucas conexões.

Para solucionar esse problema, foi criado um patch para o kernel e para o iproute, chamado ESFQ (Enhanced SFQ), onde se faz a alocação de banda por IP, e não por conexão.

ESFQ for Linux 2.6

Eu compilei e tô usando ele aqui...a diferença é muito grande...melhore e muito na equalização do compartilhamento da banda...

[gustkiller]

Não sei, de vocês mas acho que controlar P2P é falta de respeito com o cliente, já que ele contrata a velocidade por exemplo 500Kbps, e faz download em p2p a 15kbps, 5kbps.
Primeiro acho isso ilegal, e segundo desrespeito para com o usuario.
Se estamos provendo o serviço nada melhor do que prover o serviço com qualidade. entrega a banda do cara ele que se exploda se não conseguir navegar e ligar enchendo o saco, ae fala para ele desligar, o P2P.
Mas veja bem isso em para quem controla P2P em provedor, não para uma empresa que tem sua banda limitada e tem usuarios detonando a rede com p2p, nesse caso só a favor até do bloqueio do P2P.

Bom essa é minha opnião. e acho que isso vai dar uma discussão boa.

Vai

O problema do p2p são das grandes operadoras oferecendo velocidades altas com preços baixos sendo que não existe magica que faça um negocio ser lucrativo , o que é o objetivo de todo negócio ( estamos falando de brasil, favor não vir com exemplo de que no japão o cara paga 10 reais por 100mbits sem Traffic Shaping).

8megas por 200 reais, sendo que nós provedores pagamos mais de mil reais por 1 mega, como vamos vender para um cliente 300kbps por 50 reais? O pessoal se engana muito com propaganda, os contratos destas operadoras grandes de banda larga, garantem de 10% ( DENTRO DA REDE INTERNA DELES) e tem ate contrato que não existe garantia de velocidade de trafego. Mas o consumidor, só quer ver o lado dele e tambem não sabe o custo de um link. Ate telefonia ilimitada tem limites contra abuso. o cara pagar 50 reais para usar uma conexao 24/7 no topo como um link dedicado e um provedor pagar pelos mesmos 300kbps dependendo da região entre 300 a 400 reais, não tem como haver o negocio.

Claro que vivemos da Oversubscription , e da pra atender os clientes com qualidade que utilizam a internet normalmente , e que no final das contas acabam pagando pelo excesso dos clientes de P2P 24/7.

Na verdade não estamos fazendo nada de ilegal, já que nosso contrato tem garantias minimas de velocidade e tambem a forma que a internet funciona, é impossível até para nós provedores termos garantia de nosso fornecedor de banda.

Ex hipotético: temos um link de 100mbits com operadora x, e acessamos um site que não tem capacidade de banda para fornecer nem 1mbit, temos garantia de banda de 100mbits da operadora. Quando começarmos a baixar deste site e o downlad vir a 1mbit vamos ligar para operadora reclamando que esta lento?

Infelizmente a internet é um meio que não tem como garantir, e no modelo de negocio de provedor, matematicamente falando para sobrar alguma coisa no final do mês , temos que agradecer quando um usuario que tem suporte local, personalizado mas só quer saber de preço e propaganda enganosa das grandes, se muda para eles e depois se arrepende!

Uma idéia que tenho sobre isto é criar um plano especial para usuarios p2p , "Plano P2P PLUS com priorização de tráfego p2p para você. Se você não está baixando no maximo pode ter certeza que é problema nas suas fontes!" Custando 3 ou 4 vezes a mais que o plano comum. Para diminuir o prejuizo!

[Giovani.couto]

Seguinte pessoal, eu andei monitorando aqui o tráfego da minha rede, e notei que o access log do meu squid começou a mostrar uma quantidade muito grande de: " error:unsupported-request-method"....

Fui atrás e percebi que isso tava acontecendo porque os softwares de p2p criptografados estava tentando a conexão pela porta 80, porém os headers dos pacotes não eram compatíveis com o protocolo HTTP, que é o que o squid espera e o cliente não consegue conectar na rede p2p, tendo que desconfigurar a opção de criptografia. Assim, então, voltam a sofrer o traffic shapping através do layer7 e do ipp2p.

Quanto ao SFQ, seu objetivo é trabalhar na alocação/distribuição da banda de forma justa...mas a maneira como ele é implementado a distribuição da banda ainda se torna "unfair", visto que clientes com um número maior de requisições / conexões conseguem ter mais banda alocada do que clientes com poucas conexões.

Para solucionar esse problema, foi criado um patch para o kernel e para o iproute, chamado ESFQ (Enhanced SFQ), onde se faz a alocação de banda por IP, e não por conexão.

ESFQ for Linux 2.6

Eu compilei e tô usando ele aqui...a diferença é muito grande...melhore e muito na equalização do compartilhamento da banda...

Olá Amigo !

Entao os p2p criptografados nao funcionão ai ?

teria como tu dar uma ajuda pra nos tipo colocar as configs do teu squid a versão dele !

por que no meu aqui nao aparece este erro que tu mencionou !

desde já agradeço por sua Atenção !