Re: [squid-users] Squid 3.1 and TPROXY 4 Problems

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
Received on Sat May 05 2012 - 23:25:19 MDT