[squid-users] Re: Squid3.1 TProxy weirdness

  Hi all,

  One thing: When I plug in the router with the clients, squid doesn't
get anything and I get A LOT of:

tcp 0 0 64.233.163.94:3128 200.250.249.127:2030
SYN_RECV 0 0 - on (10.29/2/0)
tcp 0 0 208.51.98.57:3128 189.22.101.109:1260
SYN_RECV 0 0 - on (11.89/2/0)
tcp 0 0 69.64.56.40:3128 189.58.246.203:3497
SYN_RECV 0 0 - on (10.29/2/0)

  What does this mean?

  Could this mean that squid isn't getting the requests because the
system is blocking them?

  What can I do to test it?

  I'm using debug_options ALL,0 ALL,1 3,3 50,ALL 33,4 5,5 and
cache.log doesn't show any error...and access.log is still blank.

  Thanks!

Felipe Damasio

2010/1/6 Felipe W Damasio <felipewd_at_gmail.com>:
>   Hi all,
>   I'm new to this list, but checked the archives a lot before asking this.
>   I'm trying to get squid-3.1 up and running with TProxy 4.1 on an ISP
> network.
>   My setup is working correctly when only a few users are connected to the
> users VLAN. The users can browse and TProxy works.
>   But when I plug in the router with all the users (around 60000), squid
> doesn't respond anymore.
>   I first suspected the problem was iptables/ebtables rules not routing the
> packets to squid, but iptables -v -t mangle -L shows:
> Chain PREROUTING (policy ACCEPT 144K packets, 50M bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>    85  6232 DIVERT     tcp  --  any    any     anywhere             anywhere
>            socket
>  5568 1581K TPROXY     tcp  --  eth0   any     anywhere             anywhere
>            tcp dpt:http TPROXY redirect 0.0.0.0:3128 mark 0x1/0x1
>   And about 2 seconds later:
> Chain PREROUTING (policy ACCEPT 208K packets, 62M bytes)
>  pkts bytes target     prot opt in     out     source
> destination
>    92  6692 DIVERT     tcp  --  any    any     anywhere             anywhere
>            socket
>  7690 2210K TPROXY     tcp  --  eth0   any     anywhere             anywhere
>            tcp dpt:http TPROXY redirect 0.0.0.0:3128 mark 0x1/0x1
>   So the requests are going through iptables, right?
>   I added debug_options ALL,1 ALL,0 and 33,4, so I could see if comm_accept
> returned OK or not. But cache.log doesn't show anything.
>   Just so you guys know, eth0 is the client-facing interface and eth1 is the
> internet-facing interface.
>   I'm using a 2.6.29.6 vanilla kernel, with these proc options:
>
> echo 1 >  /proc/sys/net/ipv4/ip_forward
>
> echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter
>
> echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
>
> echo 1 >  /proc/sys/net/ipv4/tcp_low_latency
>
> echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
>
> echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
>
> echo 0 > /proc/sys/net/ipv4/conf/br0/rp_filter
>
> echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
>
> echo 1 > /proc/sys/net/ipv4/conf/all/send_redirects
>
> echo 1 > /proc/sys/net/ipv4/conf/eth0/send_redirects
>
>   Also, I'm using these rules that I got on the squid wiki TProxy tutorial:
>
> 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 -i eth0 -p tcp --dport 80  -j TPROXY
> --tproxy-mark 0x1/0x1 --on-port 3128
>
> ebtables -t broute -A BROUTING -i eth0 -p ipv4 --ip-proto tcp --ip-dport 80
> -j redirect --redirect-target DROP
>
> ebtables -t broute -A BROUTING -i eth1 -p ipv4 --ip-proto tcp --ip-sport 80
> -j redirect --redirect-target DROP
>
>  cd /proc/sys/net/bridge/
>
>  for i in *
>
>  do
>
>    echo 0 > $i
>
>  done
>
>  unset i
>
>   Is there any tests I can do or any other info I can provide?
>
>   Ebtables version is "ebtables v2.0.9-1 (June 2009)". And iptables is
> "iptables v1.4.3.2".
>
>   What kills me is that if I plug in a single user on the client interface
> everything works...also if I put a single user on the VLAN of the client
> interface everything works too...no idea why it doesn't work when all users
> are plugged in.
>
>   Thanks in advance!
>
> Felipe Damasio
Received on Thu Jan 07 2010 - 22:41:11 MST