With the tproxy server as given in my scenario, I have a lot of flexibilities:<br>1. The high-end caching (tproxy) server can offer thro'put advantages.<br>2. Original IP of the clients can be retained thro' tproxy support<br>
3. Another IP based traffic identification/metering mechanism can sit between comp/tunneling-agent2 and the web server and monitor the traffic.<br><br>whereas in the conventional scenario suggested by you, point # 2 and # 3 would fail.<br>
<br>Tproxy4 socket is not a secure tunnel like that of IPSec to prevent DNATs from happening.<br><br>IMHO, I feel that the tproxy-local DNAT issue is a kind of restriction in the name of a new feature.<br><br><br><br><div class="gmail_quote">
2008/12/16 Balazs Scheidler <span dir="ltr"><<a href="mailto:bazsi@balabit.hu">bazsi@balabit.hu</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Tue, 2008-12-16 at 10:46 +0530, Arun Srinivasan wrote:<br>
> Hi,<br>
><br>
> Balazs comment 1:<br>
> "You cannot use DNAT and tproxy on the same connection. What do you<br>
> want<br>
> to achieve?"<br>
><br>
> This is a common scenario. Say you have an intermediate compression<br>
> agent/tunneling agent between the tproxy server and the web server as<br>
> shown below:<br>
><br>
> Client <--------> tproxy server <---------> compression/tunneling<br>
> agent1 <=============> compression/tunneling agent2<br>
> <------------------> web server<br>
><br>
> In this case, the output from the tproxy server has to be DNATted or<br>
> policy routed to the compression/tunneling agent. Policy routing is<br>
> possible if the compression/tunneling agent lies outside the box. In<br>
> case, if it runs as another process along with the tproxy server, DNAT<br>
> is the only option, AFAIK.<br>
><br>
> Balazs comment 2:<br>
> "If you want to change the target address of the server side<br>
> connection,<br>
> why don't you DNAT the server connection? That should work."<br>
><br>
> Not able to understand what you exactly mean by "DNAT the server<br>
> connection".<br>
><br>
> If my understanding is correct, Tproxy association is only for the<br>
> socket created between client and the tproxy server. If that is the<br>
> case, why does socket match failure happen for the socket created<br>
> between tproxy server and DNAT server?<br>
<br>
</div></div>No, tproxy _may_ operate for both the client->tproxy and the<br>
tproxy->server connections, not just between client & tproxy.<br>
<br>
However, you're right that tproxy does not support redirecting the<br>
traffic if the upstream for tproxy is running on the same box, the<br>
reason is simple, tproxy also uses routing to direct traffic to a local<br>
process, and it is not currently possible to divert outgoing traffic<br>
back to the input interface. but never mind.<br>
<br>
So in the scenario above, what is the added value of using "tproxy"<br>
instead of plain, simple NAT.<br>
<br>
client -> REDIRECT in nat/PREROUTING -> proxy1 -> DNAT in nat/OUTPUT -><br>
<div class="Ih2E3d">compression/tunneling agent1 <-> compression/tunneling agent2 -><br>
</div>webserver<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
the added value of tproxy over using NAT is increased performance (no<br>
NAT is required) and solving the problems related to the conntrack table<br>
and local IP stack state to get out of sync.<br>
<font color="#888888"><br>
<br>
<br>
--<br>
Bazsi<br>
<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Regards,<br>Arun S.<br>