]> git.ipfire.org Git - thirdparty/squid.git/commit - src/cf.data.pre
Author: Adrian Chadd <adrian@squid-cache.org>
authorAmos Jeffries <squid3@treenet.co.nz>
Fri, 25 Sep 2009 11:09:37 +0000 (23:09 +1200)
committerAmos Jeffries <squid3@treenet.co.nz>
Fri, 25 Sep 2009 11:09:37 +0000 (23:09 +1200)
commitb0758e04c93745979a8f679cec8e08b724d6ec58
treebcd0a84de003ce2a0cbe7db49b897e5abb344144
parenta53ea9b85e4df10a882204a11fed283a5234d627
Author: Adrian Chadd <adrian@squid-cache.org>
A tproxy cache cluster (eg behind WCCPv2) can't peer.

The issue stems from the forwarding logic creating source address spoofed
sockets to destinations that are inside the cluster. Since the WCCPv2
router won't redirect packets with an origin of the proxy MAC (at least for
L2 peering), source spoofed packets go out and are routed normally. The
packets back from the destination peer have a remote end of the spoofed IP,
and are instead sent to teh original client rather than the proxy.

The forwarding logic needs to be taught to optionally enable tproxy source
spoofing on connections based on a peer flag.

Just for completeness - tproxy'ed connections to a upstream or peer proxy
which is -outside- of the WCCPv2 tproxy cluster work fine.
src/cache_cf.cc
src/cf.data.pre
src/forward.cc
src/neighbors.cc
src/structs.h