se voce desviar os pacotes com src-port 80 para o proxy vai funcionar.. fiz esse arranjo uma vez e deu certo..
outro sistema q vc pode usar é WCCP se o router for cisco.. o WCCP intercepta os pacotes e repassa ao proxy sem modificar nada (usa o tunel GRE para isto) .. WCCP é bom porque faz balanceamento e fail-over caso tenha mais de 1 proxy registrado ... 2010/6/29 João Paulo Just <j...@rg3.net>: > Patrick Tracanelli wrote: >> Em 27/06/2010, às 13:04, João Paulo Just Peixoto escreveu: >> >> >>> On Sun, 27 Jun 2010 08:02:34 -0300, Luiz Otavio O Souza >>> <lists...@gmail.com> wrote: >>> >>>> Joao Paulo, >>>> >>>> Veja, o tproxy utiliza os IPs dos clientes para buscar as páginas na >>>> >>> web. >>> >>>> Para isso você tem que interceptar o trafego dos clientes (como router >>>> >>> ou >>> >>>> bridge) você não pode ter duas maquinas na mesma rede com o mesmo IP (a >>>> maquina do cliente e o tproxy - dois mac address diferentes concorrendo >>>> pelo mesmo IP). >>>> >>>> A saída dos pacotes a partir do servidor não será problema pois seguirá >>>> >>> do >>> >>>> seu default router, assim você só precisa se preocupar com a volta. >>>> >>>> Pode ser que funcione se você forçar a volta dos pacotes (pacotes com >>>> origem da porta 80 e destino para a rede/IP de clientes) diretamente >>>> >>> para o >>> >>>> tproxy a partir do seu roteador/gateway/firewall. >>>> >>>> Deixe o resto dos pacotes seguindo o caminho default (rota) para os >>>> clientes. >>>> >>>> Boa sorte :) >>>> >>>> Luiz >>>> >>> Olá, Luiz. >>> >>> Imaginei exatamente isso. Queria fazer um teste configurando o roteador >>> para devolver os pacotes oriundos da porta 80 para o servidor com o Lusca, >>> mas a operadora não me dá acesso ao roteador :( >>> >>> De qualquer forma, vou tentar ver com eles pra fazermos esse teste. >>> Acredito que só falta isso pra resolver meu problema. :) >>> >>> >> >> Opa, vi que a thread ja esta encaminhada. >> >> Pra fazer o ThunderCache em modo CLUSTER operar com TPROXY tivemos que fazer >> algumas adaptações. Fizemos o thunder marcar com ToS os pacotes de saída >> (request), e na frente mandamos acompanhar sessão por sessão tudo que saisse >> com essa flag: >> >> $fw add count tag 80 tcp from $cluster_node1 to any 80 iptos lowdelay setup >> keep-state >> $fw add count tag 81 tcp from $cluster_node1 to any 80 iptos thorughput >> setup keep-state >> >> Usamos lowdelay e thorughput pra não precisar mecher no source do ipfw, >> pois alguns valores ele ja da match. >> >> Ai no gateway devolvemos o retorno pro cluster_node de acordo com o marcado: >> >> $fw add fwd $cluster_node1 tcp from any 80 to $rede_cliente in via $ife >> tagged 80 >> $fw add fwd $cluster_node2 tcp from any 80 to $rede_cliente in via $ife >> tagged 81 >> >> Foi o jeito. Funcionou. >> >> Talvez algo similar seja possível se o gateway do Lusca no seu cenário >> tambem for FreeBSD. >> >> Lenbre-se que tem que marcar a sessão pois o que importa é o retorno, não a >> saída. >> > Se não conseguir fazer a mudança no roteador, vou tentar isso aí. Aqui > uso FreeBSD em tudo, só o roteador que é MikroTik. > > -- > João Paulo Just > Diretor Técnico RG3.Net - http://www.rg3.net/ > FCP - Furukawa Certified Professional > -- > Feira de Santana, BA, Brasil. > +55 75 8104 8473 > Blog: http://just.rg3.net/ > > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Sds. Alexandre J. Correa Onda Internet http://www.onda.net.br IPV6 Ready !!! http://ipv6.onda.net.br ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
