RE: [squid-users] Linux + TPROXY + Remote Squid

On 31.05.2012 05:19, Thomas York wrote:
> I've made a LOT of progress with that. The only problem that I'm
> having now is making sure that the traffic that is coming from squid
> BACK through the same router doesn't get tagged and sent back to the
> proxy (causing a loop). I've tried doing different taggings based on
> interface, but this doesn’t seem to help at all... I also would have
> thought that added a " iptables -t mangle -A PREROUTING -s 10.0.1.1
> -j
> ACCEPT" to the router would stop this from happening, but it doesn't
> look like the traffic from Squid -> Internet web server is using
> 10.0.1.1, for some reason.

"Some reason" being ... this is "T(ransparent)PROXY", not the hacked up
half-way version of packet interception based on NAT.

Traffic Squid<->Internet has src(client IP):dst(Internet IP) and the
traffic Squid<->client has src(Internet IP):dst(client IP). Squid is
transparent at the IP address level.

That rule will match only the traffic from Squid box generated as a
result of Squid or other software on the box needing to do something
itself (DNS lookups, peer checks, cachemgr operations, etc).

> Proxy
> ------------
> ip -f inet rule add fwmark 1 lookup 100
> ip -f inet route add local default dev lo table 100
> 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
>
> root_at_proxy01:~# ip route list
> default via 10.0.1.254 dev eth0
> 10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.1
>
> root_at_proxy01:~# ip route list table 100
> local default dev lo scope host
>
>
> Router
> ------------
> ip -f inet rule add fwmark 1 lookup 100
> ip -f inet route add default via 10.0.1.1 table 100
> ip -f inet rule add fwmark 2 lookup 101
> ip -f inet route add default via 10.1.17.254 table 101
> 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 -N FROMPROXY
> iptables -t mangle -A FROMPROXY -j MARK --set-mark 2
> iptables -t mangle -A FROMPROXY -j ACCEPT

> iptables -t mangle -A PREROUTING -i eth5 -d 10.0.0.0/8 -j ACCEPT
> iptables -t mangle -A PREROUTING -i eth5 -d 192.168.0.0/16 -j ACCEPT
> iptables -t mangle -A PREROUTING -i eth5 -j FROMPROXY
> iptables -t mangle -A PREROUTING -s 10.0.1.1 -j ACCEPT
> iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j DIVERT
>
> root_at_fw:~# ip route list table 100
> default via 10.0.1.1 dev eth5
> 10.0.1.0/24 dev eth5 scope link
>
> root_at_fw:~# ip route list table 101
> default via 10.1.17.254 dev eth0
> 10.1.17.0/24 dev eth0 scope link
>
> root_at_fw:~# ip route list
> default via 10.1.17.254 dev eth0
> 10.0.1.0/24 dev eth5 proto kernel scope link src 10.0.1.254
> 10.1.1.0/24 via 10.100.1.22 dev eth2 metric 110
> 10.1.17.0/24 dev eth0 proto kernel scope link src 10.1.17.158
>
>

AFAIK that should be working.

> -- Thomas York
> -----Original Message-----
> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Sent: Tuesday, May 29, 2012 8:00 PM
> To: squid-users_at_squid-cache.org
> Subject: RE: [squid-users] Linux + TPROXY + Remote Squid
>
> On 30.05.2012 01:49, Thomas York wrote:
>> Is any more information needed?
>>
>> -- Thomas York
>>
>> -----Original Message-----
>> From: Thomas York
>> Sent: Friday, May 25, 2012 1:37 PM
>>
>> I forgot one detail. I have an iptables rule BEFORE the PREROUTING
>> divert/tproxy iptables rules on the router. I added an accept so
>> that
>> HTTP traffic from the proxy doesn't get tagged and rerouted to the
>> proxy.
>>
>> Here's the rule set I have for the firewall
>>
>> 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 -s 10.0.1.1 -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
>
> With Squid listening on localhost port 3129 to receive the packets
> sent to 0.0.0.0:3129 and [::]:3129 ?
>
> When the router is a different box to the Squid you should do all
> this with plain old routing and marking/tagging (no TPROXY) on the
> router.
>
>
>> -----Original Message-----
>> From: Thomas York
>> Sent: Friday, May 25, 2012 1:32 PM
>>
>> No. The router has three interfaces. One goes to the internet and
>> has
>> a
>> default route. I am running NAT on this interface so that the
>> firewall,
>> proxy
>> and clients can reach the internet. The second is a single /24
>> network
>> (10.0.1.0/24) that has only the proxy and the firewall on it. The
>> third is a
>>
>> single /24 (10.1.1.0/24) that has a single Windows 7 client on it
>> for
>> generating HTTP requests and testing. I'm tagging the packets on
>> the
>> firewall
>> and running them through a separate routing table, which sends the
>> packets
>> to
>> the proxy (without NAT-ing). The proxy and the firewall see the
>> routed
>> packets
>> perfectly fine. I'm not doing any kind of iptables rules on the
>> proxy,
>> however.
>
> This is the problem. TPROXY rules are iptables rules supposed to be
> on
> the proxy machine *only*. Outside that proxy box all packets have
> client
> and Internet destination IP addresses and get routed.
>
> NIC flow in/out or MAC address is best to identify which stage of the
> flow the packets are at and how to tag/handle them in the routers. It
> may require several tags at the router; for packets direct from
> client
> or Internet, and packets already been via Squid/proxy box.
> OR just routing based on NIC received...
>
>
> ie, Router config logic:
> if in NIC (from client) tag for routing and send to Squid box as
> gateway
> if in NIC (from Internet) tag for routing and send to Squid box as
> gateway
> if in NIC (from Squid) handle as if Squid did not exist: send to
> normal IP destination on packet
>
>
> Amos
Received on Thu May 31 2012 - 00:57:42 MDT