On Tue, 20 Sep 2011 15:15:32 +0300, Tux Mason wrote:
Hello,
Thank you for the prompt reply.
When I set my browser to use the troxy port, netstat output shows
SYN_SENT for a while and the connection times out.
Of course. Squid is required to invert the connecting IP addresses
on
arrival at a tproxy port. You CAN NOT send forward-proxy traffic
from the
browser to a Squid tproxy flagged port and have anything useful come
out the
WAN side of Squid.
Set your browser to use no proxy at all and the Squid box as its box
gateway
router.
My goal is to use WCCP with squid 3.1.x and TPROXY4.
I would like to test with my browser first and ensure all is well
before i can make any permanent settings on my router.
I use the squid box for caching only and not routing.
Routing is not optional. TPROXY operates by catching packets as they
pass through the box. It must be setup either as a 'normal' router or as
a bridging router.
Note that there is no need for it to be the only router, or even to
handle all outgoing traffic. One of the network designs is to have a
main gateway router use WCCP to pass port 80 packets from LAN to the
squid box for teh TPROXY steps and routing to take place. The routing
Squid box does is usually just to send the packets back to the main
gateway after TROXY.
To test the TPROXY functionality, you can plug your test workstation
into the squid box as the only client and use it as that workstations
gateway router. It is a good idea not to get WCCP involved until you are
sure that at least will work.
Once that is done and being tested correctly. Check your rpfilter
settings
against the wiki page. I have reason to believe the wiki docs are
now out of
date as of kernel 2.6.35 and incorrect regarding rpfilter. But none
has yet
confirmed which altered settings we need.
---- /etc/sysctl.conf
-------------------------------------------------------------------------------------------------------------
# Enable source routing
net.ipv4.conf.all.accept_source_route = 1
net.ipv4.conf.lo.accept_source_route = 1
net.ipv4.conf.eth0.accept_source_route = 1
net.ipv4.conf.default.accept_source_route = 1
Source route is not relevant to TPROXY. Where the routing stages happen
on packet output from squid or on bypassed traffic.
Probably best to leave that at its default.
# Enable IP spoofing
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
One of the kernel guys informs that rp_filter "2" now means loose
routing checks. "0" should still mean none (I think), so that should be
fine.
# Enable packet forwarding
net.ipv4.ip_forward=1
----------------------------------------------------------------------------------------------------------------------------------------
---------- squid.conf excerpt
I see no NAT rules for port 3128 interception.
I used squid interception on port 3128 with WCCP and it worked ok.
That means the client->WCCP_router->Squid stage works. NAT and TPROXY
have very different outgoing packets, so means nothing about outgoing
Squid->WCCP_router->Internet traffic.
Below is the rule I was using for NAT (on the squid box) after
creating the required gre tunnel between the cisco router and the
squid box.
iptables -t nat -A PREROUTING -i wccp0 -p tcp -m tcp --dport 80 -j
DNAT --to-destination <SQUID_PUBLIC_IP>:3128
My objective now is to get squid TPROXY4 working with one or two pcs
before I can attempt to make it work with WCCP.
This way I can be sure that my squid server is well configured in
case
i run into trouble when configuring WCCP.
In my firefox settings, I set the proxy server to <SQUID_PUBLIC_IP>
and the port to 80. (squid tproxy is running on port 3129)
This will make the browser send packets from its IP to the domain which
is being hosted on the Squid IP on port 80.
TPROXY will tell Squid to send packets to SQUID_PUBLIC_IP on port 80,
using the browser IP as outgoing.
Squid will connect to itself using port 80 and sending the client IP as
source....
Like I said, configuring the browser to be aware of the proxy _is not
possible_ with TPROXY. It only ever worked with NAT because of a bug,
which is now fixed.
The browser MUST be connecting directly to the IP and port where some
website is hosted. The network routing functionality makes sure the
packets flow through the squid box, where TPROXY there can pick packets
up.
The iptables status shows that the packets are forwarded from port 80
to port 3129 ok.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
root@cache1:~# iptables -t mangle -L -v -n
Chain PREROUTING (policy ACCEPT 1856 packets, 185K bytes)
pkts bytes target prot opt in out source
destination
160K 6616K DIVERT tcp -- eth0 * 0.0.0.0/0
0.0.0.0/0 socket
24 1112 TPROXY tcp -- eth0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:80 TPROXY redirect
<SQUID_PUBLIC_IP>:3129
mark 0x1/0x1
Chain INPUT (policy ACCEPT 160K packets, 6632K bytes)
pkts bytes target prot opt in out source
destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy ACCEPT 317K packets, 34M bytes)
pkts bytes target prot opt in out source
destination
Chain POSTROUTING (policy ACCEPT 317K packets, 34M bytes)
pkts bytes target prot opt in out source
destination
Chain DIVERT (1 references)
pkts bytes target prot opt in out source
destination
160K 6616K MARK all -- * * 0.0.0.0/0
0.0.0.0/0 MARK set 0x1
160K 6616K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
That looks right for the rules. I think this whole issue is simply the
browser configuration (ie the testing method).
Amos
