[BUG] Quickly adding and deleting FIP can lead to leaked iptables rule

[cruickshankpg]

Kube-OVN Version

v1.13.4

Kubernetes Version

v1.28.6

Operation-system/Kernel Version

"Ubuntu 22.04.5 LTS" 6.8.0-47-generic

Description

Creating a FIP and then deleting it before kube-ovn has completely processed the add can lead to an iptables rule being leaked on the gw.

This then prevents other FIPs from using the EIP.

handleAddIptablesFip only adds the finalizer after programming the iptables rule. The method has to wait for the gateway lock and iptables-legacy can be relatively slow to run so there is a time window where the FIP can be deleted with no finalizer but some programming has taken place.

handleAddIptablesFip should add the finalizer first and adding the finalizer should error if the FIP cannot be found to prevent further processing.

We hit this in a integration test that created a FIP, checked connectivity and then deleted it.

Steps To Reproduce

This is a race condition so it might take some attempts

1. create a vpc nat gw
2. create EIP
3. create and delete FIP using EIP
4. exec onto gateway and check if iptables-legacy still has the fip rules for the deleted fip

Current Behavior

Adding and quickly deleting a FIP may leave iptables rules on VPC NAT GW

Expected Behavior

Adding and quickly deleting a FIP leaves no configuration on VPC NAT GW

[dosubot]

To address the issue of leaked iptables rules when a Floating IP (FIP) is quickly added and deleted in Kube-OVN v1.13.4, you can modify the handleAddIptablesFip function to add the finalizer before programming the iptables rule. This change ensures that if the FIP is deleted before the iptables rule is fully processed, the finalizer will prevent the deletion from proceeding until the rule is properly cleaned up.

Here's a suggested approach:

1. Add Finalizer First: Modify the handleAddIptablesFip function to add the finalizer to the FIP resource before any iptables rules are programmed. This ensures that the FIP cannot be deleted until the finalizer is removed, which should only happen after all necessary cleanup is complete.

2. Error Handling: Ensure that adding the finalizer returns an error if the FIP cannot be found. This prevents further processing of a non-existent FIP, reducing the risk of leaving orphaned iptables rules.

3. Invoke Cleanup: Make sure that the del_floating_ip function is invoked to clean up any iptables rules if a FIP is deleted. This function checks for existing rules and deletes them, along with clearing the connection tracking for the destination IP ^[1].

Implementing these changes should help prevent iptables rules from being leaked on the gateway when a FIP is quickly added and deleted.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}