On Mon, May 04, 2015 at 03:47:33PM +0200, Thomas Graf wrote:
[...]
> Given that the multiple source zones which talk to a common
> destination zone may have conflicting IPs, the SNAT must either
> occur in the source zone where the source address is still unique
> or the CT tuple must be made unique with a source zone identifier
> so that the SNAT can occur in the destination zone.
>
> Doing the SNAT in the source zone requires to use a unique IP pool
> to map to for each source zone as otherwise IP sources may clash again
> in the destination zone. We obviously can't do --SNAT -to 10.1.1.1 in
> two namespaces and then just route into a third namespace. This
> approach is not scalable in a container environment with 100s or even
> 1000s of containers each in its own network namespace.
>
> What we want to do instead is to do the SNAT in the destination zone
> where we can have a single SNAT rule which overs all source zones.
> This allows inter namespace communication in a /31 with minimal waste
> of addresses.
Thanks for explaining. So you need to allocate an unique tuple using
the mark to avoid the clashes for the first packet that goes original
using the same pool. Then, the NAT engine will allocate an unique
tuple in the reply direction.
But what is the use case for -j CT --flextuple reply ? By when you see
the reply packet the tuple was already created.
Another question is if it makes sense to have part of the flows using
your flextuple idea while some others not, ie.
-s x.y.z.w/24 -j CT --flextuple original
so shouldn't this be a global switch that includes the skb->mark
only for packets coming in the original direction?
I also wonder how you're going to deal with port redirections. This
only seem to be working SNAT/masquerade to me if the NAT happens from
VRF side.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
