>
> I have a unique situation where I have a multi-homed
> machine running squid where I will need to do some
> kind of load balancing for outbound squid traffic.
>
> Well, if both the outgoing interface are nat-ed, things will
> be relatively easier, I will just do transparent proxy
> (without tproxy ). Since the identity of the original http
> requests are lost anyway, tproxy will be redundant.
>
> However, in a situation where one of the outgoing legs is
> NOT NAT-ed, while another leg is NAT-ed, this is where
> I am in trouble.
>
> When the outgoing interface is not NAT-ed, I would like
> to be able to do tproxy, retaining the identity of the
> original http requests. However, when I use the squid
> redirective,
>
> http_port 3128 tproxy transparent
Thats the config.
tproxy option also implies transparent, but having both is clear.
If its a config problem its not there.
> The un-NAT-ed leg will work just fine but I noticed that for the
> NAT-ed leg, the outgoing traffic gets out to the internet
> using the source IP of the original http request DESPITE that
> there is a SNAT on the nat POSTROUTING chain. As you can
> imagine, this will cause return traffic unable to come back to the
> machine.
>
> Wonder if it is the limitation of the tproxy kernel patch,
> or it's just the way I did (wrong) which causes the behaviour.
Most common failure like this requires 'you need to patch the kernel', but
it sounds like that's been done.
Next step is seeing what tcpdump shows about the two types of traffic.
And possibly what type of router/balancer is doing the splitting?
PS. Do you HAVE to use tproxy? If the NATing isn't a problem you could use
a plain intercepting/transparent proxy and have remote sources down both
streams see the squid IP as the source of requests.
Amos
Received on Mon Oct 22 2007 - 19:50:47 MDT
This archive was generated by hypermail pre-2.1.9 : Thu Nov 01 2007 - 13:00:01 MDT