Ben Pfaff <[email protected]> writes: > 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.
ACK. That would be more accurate. Thanks. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
