Re: HTB x CACHE SQUID A FULL
Citação:
Postado originalmente por KALAMAT
isso é facil amigo.
basta nas regras do seu htb (marcação por pacote) não marcar a porta 80 e ativar o delay pools no squid pra ninguem consumir o link todo.
no meu htb eu faço assim na linha de marcação de pacotes:
[size=10pt]$IPTABLES -t mangle -A FORWARD -p tcp -s $ADDR --dport ! 80 -j MARK --set-mark $ID[/size]
assim eu libero essa porta do controle de banda.
no squid eu tenho na parte de delay pools:
acl paginas urlpath_regex -i "/etc/squid/acelerador/paginas.txt"
delay_pools 2
delay_class 1 3
delay_class 2 3
delay_access 1 allow paginas
delay_access 1 deny all
delay_access 2 allow wifi
delay_access 2 deny all
delay_parameters 1 -1/-1 -1/-1 109250/128000
delay_parameters 2 -1/-1 -1/-1 18750/128000
sendo que nesse arquivo citrado, coloquei apenas as extensões htm, asp, php, cgi, pl, etc...
assim a navegação vai ficar turbinada, ja outras coisas (downloads, etc) vem no download de forma normal.
espero ter ajudado.
Tem como fazer isso usando o cbq, se tem como ficaria as regras?
Obrigado
Re: HTB x CACHE SQUID A FULL
/vamo la, alguem pode ajudar?
Re: HTB x CACHE SQUID A FULL
Pessoal...atenção ai...
Não limitar a porta 80 e usar o delay_pools é uma "faca de dois legumes"...Por exemplo...o cliente tem 256 Kbits de banda...Ai você define no HTB que ele tem 256 pra qualquer coisa, menos pra porta 80 (HTTP)...Ai você vai no SQUID e faz um delay_pools dizendo que ele tem 256...Blz...mas e se o cara fizer um download via FTP (passando por fora do proxy) e, ao mesmo tempo, fazer um download em HTTP....ele vai consumir 512 Kbits...
A solução exata para este problema é usar o PATCH ZPH no SQUID (http://www.it-academy.bg/zph/)...
Como ele trabalha: Aplicando esse patch no SQUID, ele meio que integra o SQUID com o QOS do Kernel...assim: ele cria uma "marcação" especial nos pacotes de requisição aos arquivos do cache do squid...é um número tipo assim: "0x8804ABCD"...Ai, quando você criar suas regras do HTB, você vai definir que os pacotes com essa "marca" terão velocidade total (ou seja, o cache vai vir com toda velocidade disponível no link):
tc filter add dev $LANDEV parent 1:0 protocol ip prio 1 u32 match ip protocol 0x6 0xff match u32 0x8804ABCD 0xffffffff at 20 flowid 1:60
Ai supondo que 1:60 é seu HTB default, vai vir com toda a velocidade...
Re: HTB x CACHE SQUID A FULL
A solução é a seguinte (ainda nao consegui!):
Não ha como diferenciar um arquivo de cache do outro no htb, salvo por um detalhe:
Quando um pacote nao esta no cache, o primeiro cabecalho enviado do proxy para o navegador contem o cabecalho:
X-Cache: MISS ....
Ja quando o arquivo esta no cache, ele retonar:
X-Cache: HIT from ....
A solucao que eu imaginei e que toda conexao onde o o "X-Cache: HIT" estiver presente, ele escapa do htb/cbq/etc..., assim:
iptables -t mangle -I OUTPUT -p tcp --sport 8080 -m string --string 'X-Cache: HIT' --algo bm -j ACCEPT
Porem somente um pacote (que contem a string) é aceito antes das marcacoes de QoS, eu preciso descobrir uma forma de identificar uma conexao cujo um dos pacotes, sendo aceitos pelo string "X-Cache: HIT" continuem a bater na regra.
O bug que temo é que o navegador use a mesma conexao tcp para baixar demais arquivos, o que iria contraria a ideia.
att,
Patrick
Re: HTB x CACHE SQUID A FULL
Citação:
Postado originalmente por roneyeduardo
Pessoal...atenção ai...
Não limitar a porta 80 e usar o delay_pools é uma "faca de dois legumes"...Por exemplo...o cliente tem 256 Kbits de banda...Ai você define no HTB que ele tem 256 pra qualquer coisa, menos pra porta 80 (HTTP)...Ai você vai no SQUID e faz um delay_pools dizendo que ele tem 256...Blz...mas e se o cara fizer um download via FTP (passando por fora do proxy) e, ao mesmo tempo, fazer um download em HTTP....ele vai consumir 512 Kbits...
A solução exata para este problema é usar o PATCH ZPH no SQUID (
http://www.it-academy.bg/zph/)...
Como ele trabalha: Aplicando esse patch no SQUID, ele meio que integra o SQUID com o QOS do Kernel...assim: ele cria uma "marcação" especial nos pacotes de requisição aos arquivos do cache do squid...é um número tipo assim: "0x8804ABCD"...Ai, quando você criar suas regras do HTB, você vai definir que os pacotes com essa "marca" terão velocidade total (ou seja, o cache vai vir com toda velocidade disponível no link):
tc filter add dev $LANDEV parent 1:0 protocol ip prio 1 u32 match ip protocol 0x6 0xff match u32 0x8804ABCD 0xffffffff at 20 flowid 1:60
Ai supondo que 1:60 é seu HTB default, vai vir com toda a velocidade...
bom essa é a ideia, pois paginas html, asp, php, são pequenas e rápidas e com o delay pools eu identifico o tipo de pagina que o usuário esta acessando, pois se for um download de um exe, zip, rar, etc.. grande, eu faço ele voltar a velocidade normal dele que foi contratada.