[ovs-dev] [PATCH v2] conntrack: handle SNAT with NULL IP address
blp at ovn.org
Wed Mar 31 19:12:45 UTC 2021
On Wed, Mar 31, 2021 at 07:18:03PM +0200, Paolo Valerio wrote:
> this patch introduces for the userspace datapath the handling
> of rules like the following:
> Kernel datapath already handle this case that is particularly
> handy in scenarios like the following:
> Given A: 10.1.1.1, B: 192.168.2.100, C: 10.1.1.2
> A opens a connection toward B on port 80 selecting as source port 10000.
> B's IP gets dnat'ed to C's IP (10.1.1.1:10000 -> 192.168.2.100:80).
> This will result in:
> A now tries to establish another connection with C using source port
> 10000, this time using C's IP address (10.1.1.1:10000 -> 10.1.1.2:80).
> This second connection, if processed by conntrack with no SNAT/DNAT
> involved, collides with the reverse tuple of the first connection,
> so the entry for this valid connection doesn't get created.
> With this commit, and adding a NULL SNAT rule for
> 10.1.1.1:10000 -> 10.1.1.2:80 will allow to create the conn entry:
> The issue exists even in the opposite case (with A trying to connect
> to C using B's IP after establishing a direct connection from A to C).
> This commit refactors the relevant function in a way that both of the
> previously mentioned cases are handled as well.
> Suggested-by: Eelco Chaudron <echaudro at redhat.com>
> Signed-off-by: Paolo Valerio <pvalerio at redhat.com>
I didn't really review this, but I'm uncomfortable with calling 0.0.0.0
"NULL". To me, in a C context especially, the term NULL in all caps is
a null pointer. I'd use 0.0.0.0 or the all-zero IP address or some
other networking term instead of NULL.
More information about the dev