Hi Pablo,
On 05/06/2015 04:27 PM, Pablo Neira Ayuso wrote:
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.
Yes, that's correct. In original direction, due to the overlapping
tuple the ct-mark is considered as well for the match, and in reply
direction SNAT chooses already a unique tuple. That's essentially
the rationale for our use case with SNAT.
But what is the use case for -j CT --flextuple reply ? By when you see
the reply packet the tuple was already created.
Given this change is completely NAT agnostic, we can keep it as a
generic addition to the conntracker. Given that the mark is very
flexible, I think it could also be used for load balancing as a
different usage.
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 first thought about a global sysctl switch, but eventually found
this config possibility from iptables side much cleaner resp. better
integrated. I think if the environment is correctly configured for
that, such a partial flextuple scenario works, too.
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.
In our case, we'd like to use the flextuple when we're explicitly
configuring iptables with SNAT. For DNAT, one could reuse it in a
different, somewhat reversed example we previously had and together
with mark based routing and match on the reply side.
Thanks a lot,
Daniel
--
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
