Re: [squid-users] Implement Tproxy on Debian squeeze

On 06.03.2012 12:54, E.S. Rosenberg wrote:
> 2012/3/6 Amos Jeffries <squid3_at_treenet.co.nz>:
>> On 06.03.2012 11:42, E.S. Rosenberg wrote:
>>>
>>> 2012/3/2 Yucong Sun (叶雨飞):
>>>
>>>> I think what happens is the document seems to be wrong, the kernel
>>>> already has TPROXY compiled in , look for /boot/config-xxxx   and
>>>> search for TPROXY, it should says "m".
>>>>
>>>> for the iptables rules, you will need to use mangle table, there's
>>>> no
>>>> tproxy table anymore.
>>
>>
>> There was never a TPROXY table. It has always been the mangle table,
>> with
>> TPROXY *target*.
>>
>>
>>>>
>>>>
>>>> However, I do want to add an additional question , suppose my
>>>> proxy
>>>> machine will be acting as network gateway to my LAN,  can I simply
>>>> archive the same effect by simply
>>>> -iptables -t mangle -A PREROUTING -p tcp --dport 80 -j DNAT
>>>> 127.0.0.1:xxxx  ??? why was tproxy needed in the first place?
>>
>>
>>> As far as I understood it you would use tproxy if you want to
>>> expose
>>> your "internal" IPs to the other side, so if for instance my
>>> internal
>>> network is actually a publicly routable block and I don't want to
>>> NAT
>>> that then you use tproxy, whereas the effect of the rule you write
>>> above is basically NAT in that the original source will be
>>> invisible
>>> to the destination.
>>>
>>> But I may not have understood things right...
>>
>>
>>
>> Sort-of. "Exposure" is only limited to the in and out ports of
>> Squid.
>>  TPROXY can work alongside proper address-only NAT to gain the
>> address
>> obfuscation if you want it. Or with any kind of firewalls for actual
>> security.
>>
>> You would also use TPROXY if you needed to do traffic interception
>> for
>> protocols other than IPv4.
>>
>>
>> For OS where transparent proxy works there is no more technical
>> reasons to
>> use NAT. OpenBSD 5.x for example seem to have jumped the whole
>> upgrade
>> process and no longer support NAT interception at all, using
>> "divert"
>> sockets which is their version of TPROXY, across the main set of
>> system
>> tools.
> That is assuming the TPROXY machine sits on the line of the machines
> going out, if it's just a firewall that is redirecting all port 80
> traffic to the proxy on a different subnet you would still use it I
> would think?

If by "line" you mean the packet flow at a virtual level, yes. TPROXY
is similar to a virtual bridge. Interception in any form assumes the
packets are reaching the machine somehow.

Actually bridging the packets across a box with TPROXY on it is the
easy way to configure it. Policy routing is the slightly harder way.
Only difference in these installations between the TPROXY of the NAT is
what properties routing logics need to make decisions on.

Amos
Received on Tue Mar 06 2012 - 01:03:13 MST