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.
Amos
Received on Mon Mar 05 2012 - 23:45:59 MST
This archive was generated by hypermail 2.2.0 : Tue Mar 06 2012 - 12:00:02 MST