On Thu, Mar 24, 2011 at 05:14:29PM -0600, Jason J. W. Williams wrote:
> >
> > Anyway the purist in me will say that this is not NAT, as there is no
> > relation between the packets of each side, this is still proxying but
> > with spoofed addresses.
> 
> 
> Hey, I don't care what HAProxy wants to call it...y'all have it is all that
> matters for me. :)
> 
> I just come from a traditional HW SLB background where it's called half-NAT.

Excuse-me for insisting, but this is still different and the difference
matters. When a component does NAT (half, full, etc...) it is in the
middle of the connection, it just mangles *packets* but does not interact
with TCP management (congestion window, segmentation, etc...). The end
point still is in charge of the session management. That means that if
the server uses small windows or emits lots of small packets, the client
will be affected by that. In turn, if the server's TCP stack has some
vulnerabilities, they will be exposed.

With a proxy, the connection from the client is terminated on the proxy
and another connection is established with the server. Data are copied
between those two connections. This means that the issues above do not
happen, but that in turn the proxy's TCP stack must be properly tuned.
A proxy also enables protocol conversion and MTU adaptation. You can
run jumbo frames on your internal network, and you can offer IPv6 service
from an IPv4-only server farm.

Last, doing L7 transformations on packets is a nightmare and generally
doesn't work very well, because retransmits, fragments and out-of-order
packets are hard to handle. Doing them on a buffered stream is a lot
easier. Nowadays, almost all L7 load balancers involve proxies, even
if they're not explicitly shown. A few L4 LBs with some L7 features
still work on packets and cause a lot of issues when L7 is enabled.

None is better than the other for all tasks. However, L7 should always be
performed by proxies, while L4 is often better done by "packet switches".

I hope this clarifies the difference.

Regards,
Willy


Reply via email to