kubeovn / kube-ovn / 24973889774

25%

push

github

fix(vpcnatgw): order SHARED_SNAT rules by longest-prefix-first (#6680)

iptables evaluates rules in a chain top-down (first-match wins).
When multiple IptablesSnatRule resources share overlapping source
CIDRs (e.g., 10.0.0.0/16 and 10.0.1.0/24), a broader rule placed
before a more specific one shadows the latter, producing the wrong
SNAT source IP for packets that should match the specific rule.

Previously add_snat() appended new rules with 'iptables -A', so the
final ordering was determined by whatever sequence the controller
happened to push rules — itself subject to informer event order and
List() non-determinism across NAT gateway restarts (handleUpdateVpcSnat
walks the cache in undefined order). The same set of SNATs could end
up with different chain orders across restarts, producing intermittent
shadowing that was hard to reproduce.

Fix by computing the insert position from the source-prefix lengths
of the existing SHARED_SNAT rules and inserting each new rule with
'iptables -I <pos>' so the chain is kept sorted by descending prefix
length. iptables first-match then yields longest-prefix-match
behavior regardless of the order in which rules arrive. No controller
coordination or chain flush is required.

Also normalize bare-IPv4 InternalCIDR at the controller boundary.
validateSnatRule in pkg/controller/vpc_nat_gw_nat.go accepts
InternalCIDR as either "x.x.x.x/len" or a bare IPv4 (per the comment
"iptables NAT only supports single IPv4 CIDR or IP"). A bare IP would
slip through the shell's prefix extraction as the full address
string, causing awk to parse '10.0.0.5' as 10 and place the /32 rule
behind any /16 or /24 — the exact regression the new ordering logic
is meant to prevent. Introduce normalizeSnatInternalCIDR and call it
at every site that hands InternalCIDR across a boundary:

  - createSnatInPod / deleteSnatInPod before rendering the shell rule
  - handleUpdateIptablesSnatRule's old/new diff before comparing, so
    flipping Spec betw... (continued)

0 of 15 new or added lines in 1 file covered. (0.0%)

14071 of 56631 relevant lines covered (24.85%)

0.29 hits per line