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_at_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
Received on Sat Sep 24 2011 - 06:19:07 MDT
This archive was generated by hypermail 2.2.0 : Sat Sep 24 2011 - 12:00:03 MDT