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
