bpf: avoid SNAT tracking for overlay traffic

[julianwiedmann]

In certain configs (basically when the node-to-node IPv4 address is also chosen as IPV4_MASQUERADE) the masquerade code in to-netdev decides that tunnel traffic is potentially conflicting with masqueraded traffic. We thus need to reserve the packet's source port ("track it"), and potentially even SNAT it.

Creating SNAT entries for tunnel traffic makes little sense - in particular as the replies will not be addressed to the packet's source port, but to TUNNEL_PORT. Doing it anyway results in pressure on the CT and NAT maps.

Improve this by marking such traffic in to-overlay, and then bypassing the masquerading logic in to-netdev accordingly. Also use the mark to detect overlay traffic for the recently introduced encrypted-overlay feature. For wireguard we're a bit more careful, to avoid missing unmarked traffic during an upgrade.

Fixes: #26908

Skip overlay traffic in the BPF SNAT processing, and thus reduce pressure on the BPF Connection tracking and NAT maps.

[julianwiedmann]

/test

[julianwiedmann]

/test

[julianwiedmann]

/test

[julianwiedmann]

/test

[julianwiedmann]

/test

[julianwiedmann]

/test

[ldelossa]

Changes to the encrypted overlay bits check out to me.

I'm having a bit of trouble tracing out where TC runs in the egress vxlan driver path.
I'm going to assume we are setting the mark on the packet post-encap.

If we are not, the mark will get cleaned, and I assume this isn't occuring if the PR is tested.

[ldelossa]

Above comment is addressed here:
#31082 (comment)

[julianwiedmann]

If we are not, the mark will get cleaned, and I assume this isn't occuring if the PR is tested.

To summarize some offline discussion - Louis' concern was that https://elixir.bootlin.com/linux/latest/source/net/ipv4/ip_tunnel_core.c#L60 would clear the mark. But that doesn't apply, as we don't switch net namespace (xnet is false).