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
