On Mon, May 04, 2015 at 12:23:41PM +0200, Daniel Borkmann wrote:
> This patch adds support for the possibility of doing NAT with
> conflicting IP address/ports tuples from multiple, isolated
> tenants, represented as network namespaces and netfilter zones.
> For such internal VRFs, traffic is directed to a single or shared
> pool of public IP address/port range for the external/public VRF.
>
> Or in other words, this allows for doing NAT *between* VRFs
> instead of *inside* VRFs without requiring each tenant to NAT
> twice or to use its own dedicated IP address to SNAT to, also
> with the side effect to not requiring to expose a unique marker
> per tenant in the data center to the public.
>
> Simplified example scheme:
>
> +--- VRF A ---+ +--- CT Zone 1 --------+
> | 10.1.1.1/8 +--+ 10.1.1.1 ESTABLISHED |
> +-------------+ +--+-------------------+
> |
> +--+--+
> | L3 +-SNAT-[20.1.1.1:20000-40000]--eth0
> +--+--+
> |
> +-- VRF B ----+ +--- CT Zone 2 --------+
> | 10.1.1.1/8 +--+ 10.1.1.1 ESTABLISHED |
> +-------------+ +----------------------+
So, it's the skb->mark that survives between the containers. I'm not
sure it makes sense to keep a zone 0 from the container that performs
SNAT. Instead, we can probably restore the zone based on the
skb->mark. The problem is that the existing zone is u16. In nftables,
Patrick already mentioned about supporting casting so we can do
something like:
ct zone set (u16)meta mark
So you can reserve a part of the skb->mark to map it to the zone. I'm
not very convinced about this.
--
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
