On 5/05/2012 7:58 p.m., Dave Blakey wrote:
Hi all,
I'm busy working on a tproxy setup with the latest squid on Ubuntu
12.04; tproxy is enabled, squid is compiled with tproxy support etc.
The difference with this setup is that traffic is being sent to the
host using route-map on a cisco as opposed to WCCP but it seems that
should work. Unfortunately it seems there is very little documentation
about the latest tproxy+squid3.1 setup method - but this is what I
have --
# IP
ip -f inet rule add fwmark 1 lookup 100
ip -f inet route add local default dev eth0 table 100
# Sysctl
echo 1> /proc/sys/net/ipv4/ip_forward
echo 2> /proc/sys/net/ipv4/conf/default/rp_filter
echo 2> /proc/sys/net/ipv4/conf/all/rp_filter
echo 0> /proc/sys/net/ipv4/conf/eth0/rp_filter
# IP Tables
iptables -t mangle -N DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY
--tproxy-mark 0x1/0x1 --on-port 3129
In squid.conf the relevant line for http_port 3129 tproxy is set etc.
With this setup I get hits on the iptables rules, and see a request in
the access log but it fails to fill it, it also looks very strange --
1336146295.076 56266 x.x.x.x TCP_MISS/000 0 GET
http://www.google.com/url? - DIRECT/www.google.com -
1336146337.969 42875 x.x.x.x TCP_MISS/000 0 GET
http://www.google.com/url? - DIRECT/www.google.com -
As you can see it's a TCP_MISS/000 and the DIRECT/www.google.com in my
experience should have an IP not a hostname? Additionally the sizes
seem very weird. The client just hangs.
Depends on your squid version, the 3.2+ are IP-only there the older ones
display FQDN when its available and log_fqdn is on.
Size is zero because upstream was contacted, but things went bad before
any bytes were transferred to the client.
This is the usual log signature for a forwarding loop. With TPROXY those
are a greater risk than with NAT, and harder to track down. You may need
to take a very close look at the TCP packets in the different network
link places and see what is going on. NP: port number is the only way to
identify cleint and server connections apart at the TCP/IP level.
Should this setup be working or is there some obvious error?
I'm not entirely sure about the rp_filter sysctl. I've had trouble on
recent Debian myself with TPROXY hanging. It may be worth experimenting
with those a bit.
Amos
