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: > > ct(commit,nat(src=0.0.0.0),...) > > 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: > > tcp,orig=(src=10.1.1.1,dst=192.168.2.100,sport=10000,dport=80),reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10000),protoinfo=(state=ESTABLISHED) > > 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: > > tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=10000,dport=80),reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10001),protoinfo=(state=ESTABLISHED) > tcp,orig=(src=10.1.1.1,dst=192.168.2.100,sport=10000,dport=80),reply=(src=10.1.1.2,dst=10.1.1.1,sport=80,dport=10000),protoinfo=(state=ESTABLISHED) > > 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 <[email protected]> > Signed-off-by: Paolo Valerio <[email protected]>
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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
