From: Ron (ron_at_debian.org)
Date: Sun 06 Jun 2004 - 16:04:26 BST
On Sun, Jun 06, 2004 at 01:32:07PM +0200, Herbert Poetzl wrote:
> masquerading is a special form of (S)NAT which
> 'remapps' the source ports dynamically to use
> one address for many different hosts/ips
Yes, I fairly well understand the various nuances of the netfilter
targets -- this isn't about teething problems with my first vserver
or netfilter config, I've been comfortably using both for quite some
time. The issue I'm noting here primarily has to do with using them
on a gateway box that has a dynamic IP as its route to the outside
> hmm, well, the idea of 'local masquerading'
> is a little strange, because there really is
> no reason to do local masquerading at all ...
> this isn't required for different vservers on
> the same host, as they will not bind to the
> same source port for an outgoing connection.
> > For now SNAT'ing the aliased interface is getting me by, but this seems
> > like a FIXME that would be nice to get rid of if we can.
> so your setup is fine, if you have configured the
> SNAT to substitute your external address for the
> local addresses of your vservers
> as a matter of fact, that's the way it should be
For a network with a (public) static IP on its gateway this
is indeed the case and SNAT is exactly what is wanted. Multiple
vservers are not a problem in either case, it is only NAT'ing
them to a dynamic IP that I noticed is currently suboptimal.
The interesting case that I raise here is the one where the
gateway has a dynamic IP (which is the case that masquerading
is specialised for) and the gatway machine itself is running
a vserver that should be NAT'ed to the outside world.
In this case, packets from the vserver interface (an alias on a
NIC bound to a private IP network) go directly to the OUTPUT chain
of the filter table and bypass the POSTROUTING chain of the nat
Using SNAT you can still rewrite the packets from the vserver that
MASQUERADE ignores, but you essentially have to reimplement the
'special' functionality of MASQ in user space and invoke it every
time the dynamic IP changes.
iptables -t nat -A POSTROUTING -o $PPP_IFACE -j MASQUERADE
does exactly what is required and expected for processes on the
main server, you instead need to do something like:
iptables -t nat -A POSTROUTING -o $PPP_IFACE -s $VSERVER_ADDR \
-j SNAT --to-source $PPP_ADDR
to NAT the vserver on the gatway box, and you need to (re)invoke
this rule with the new dynamic IP every time $PPP_ADDR changes
(without any of the safeguards MASQ provides wrt to clearing out
old connection information)
vservers on other machines in the internal network of course work
just fine when their packets pass through the gateway without the
latter rule because they are not subject to the same short
circuiting that strictly local packets are.
I think the problem essentially is that packets originating from
the main server (with an external destination) will bind to the
external interface and thus be correctly MASQ'd -- whereas packets
originating in the vserver will bind to the NIC alias and go
directly to the filter OUTPUT chain without being rebound to the
external interface or having their source address rewritten by
the nat rules. (someone more current with kernel socket internals
could probably polish this description of empirical observations)
While I agree with you that in general the idea of 'local' masq
seems odd, I think part of the issue is that NIC aliases are not
treated the same as other local adresses, and of course in the
case of a vserver, to some extent they aren't really local at all,
but they still get routed through the main server as if they were.
I'm not really sure what the strictly correct answer to this is
yet, but I do know that what I have done to make this work at the
moment is definitely a kludge.
For me at least it is a temporary kludge, because the machine will
be getting a static IP shortly and then using SNAT will be exactly
correct, but I'm in a reasonable position to test things on this
box before it does go 'stable' which is why I posted to see if that
might be helpful.
anyway, I'm close to needing sleep, so I hope I haven't missed
something glaring in the explanation above -- if I have I'll try
to plug the gap in a few hours time...
Thanks for these... google didn't turn them up for me earlier.
I believe the other alternative to what I did above would be to
use AK's ip2 to bind the additional address for the vserver
directly to the NIC instead of using an alias, but I haven't
confirmed that for sure with this particular installation.
Vserver mailing list