On 06.03.2012 12:54, E.S. Rosenberg wrote:
2012/3/6 Amos Jeffries <squ...@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
