Luiz,
Meu proxy estava rodando a mais de 2 anos com as mesmas regras de
firewall.
Eu sempre usei o SKIPTO jogando pra 65000 que tem um allow ip from any
to any --- a linha 65535 tem a mesma instrução porque o firewal é OPEN.
O fato é que todos os sites que tinham o SKIPTO (caixa, sefaz, rapdshare
e o escambau) simplesmente pararam de funcionar.
Quando eu apagava a linha do SKIP ele funcionava (sendo cacheado).
O que vi como problema foi o fato do squid ter o ip da rede interna como
parâmetro do squid.conf. A solução que vi foi aquela de várias instâncias
squid rodando.
No exemplo que vc mandou abaixo está o redirecionamendo do localhost e
não do ip real. Isso é realmente funcional?
Ats,
Ademir Peixoto
----- Original Message -----
From: "Luiz Otavio O Souza" <l...@visualconnect.com.br>
To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
<freebsd@fug.com.br>
Sent: Thursday, January 29, 2009 11:17 AM
Subject: Re: [FUG-BR] Cacheboy esta sendo renomeado
> Olá Luiz,
>
> Aproveito seu e-mail pra falar sobre os pathes do tproxy no freebsd.
> Instalei e ele funcionou.
> Mas surgiram algumas limitações bastante complicadas.
> 1 - Ele não faz cache de ip que não esteja com a rede conectada na
> placa
> local.
> 2 - Ele não suporta mais de uma interface de rede fazendo saida pra
> cliente (temos 4).
> 3 - Ele não suportou os skipto de sites como a caixa (famigerado
> conectividade social)
>
>
> Não tive tempo de testá-lo melhor. Vi que ele estava repassando o ip,
> mas não vazia cache de ips reais de clientes que estão atrás de outros
> dispositivos de roteamento (como mikrotik)
> Sei que está e versão beta mas essas coisas que citei acima são
> extremamente necessárias pra serem usadas em provedores.
> Parabéns pelo trabalho
>
Ademir,
Existe sim uma parte do patch que não foi publicada e que é a responsável
pelo funcionamento de sistemas mais complexos (sistemas com uma só placa de
rede e também no modo bridge). Esse patch não foi publicado porque
atualmente ele não funciona :) Será preciso reescrever essa parte para o
código atual.
Tirando essa parte bem especifica, eu acredito que os problemas que você viu
por ai são possíveis de serem contornados mesmo na situação atual. Você
provavelmente esta usando os meus exemplos de regras que contém alguma
limitações, mas na verdade o ipfw permite algumas variações que acredito que
possam resolver os problemas que você citou.
Para seus testes talvez essas regras deixem as coisas mais claras:
ipfw add fwd 127.0.0.1,3128 tcp from 200.200.200.0/24 to any 80 in via
${iif} # default rule to transparent proxy
ipfw add fwd 127.0.0.1 tcp from any 80 to 200.200.200.0/24 in via ${oif} #
catch the packets that come back using the clients IPs
Não é necessário utilizar o IP da rede de clientes como no meu exemplo do
site. Isso ajuda ? Eu imagino que isso resolva os problema 1 e 2.
O problema 3 também é possível de ser resolvido adicionando essas regras
ANTES das regras de fwd:
ipfw add skipto XXX tcp from 200.200.200.0/24 to ${caixa} 80 in via {$iif}
ipfw add skipto XXX tcp from ${caixa} 80 to 200.200.200.0/24 in via ${oif}
Embora a solução atual seja digna do RF (meu parceiro de gambiarras), ela é
bem funcional, basta você exercitar seu conhecimento de ipfw que é parte
essencial dessa solução.
Qualquer duvida entre em contato.
Abraço,
Luiz
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
