datapath/iptable: fuzzy match for devices than exact match

[liyihuang]

Use device filter to fuzzy match the devices than the exact match to match the users input for devices and MasqueradeInterfaces. We described this in the doc but not really doing it in the code.

we need to backport it all the way to 1.15 since that's when we introduce the MasqueradeRouteSource
Fixes: #37448

Fix traffic not getting masqueraded with wildcard devices or egress-masquerade-interfaces when enable-masquerade-to-route-source flag is set.

[liyihuang]

/test

[liyihuang]

/ci-integration

[liyihuang]

/ci-ginkgo

[liyihuang]

/ci-ipsec-upgrade

[liyihuang]

/ci-ipsec-upgrade

[liyihuang]

/ci-e2e-upgrade

[liyihuang]

/ci-e2e-upgrade

[liyihuang]

/ci-e2e-upgrade

[liyihuang]

/ci-e2e-upgrade

[liyihuang]

/ci-e2e-upgrade

[liyihuang]

/ci-e2e-upgrade

[liyihuang]

I really think the CI failure for e2e upgrade is not related to this PR, but also don't know what caused it

[liyihuang]

/ci-e2e-upgrade

[liyihuang]

it looks like CI passed when only retriggering the failed ones.

Confirmed in the slack channel. its the CI issue

[joestringer]

Even if this is the correct behavior per the documented steps, I worry a little that this may change the way Cilium behaves in production environments and whether that in itself could cause more problems than the bug being fixed. Do you have a sense for the risk of making this change? Could we start dropping traffic that was previously passed for instance?

(To be clear, this question relates to the backports; for future versions and even v1.17.x it sounds like the fix makes sense 👍 )

[joestringer]

Ah, I see the reproducer would require the user to specify the masquerade route source (unusual config) with eth+ or similar. Maybe the risk is not so high.

[liyihuang]

Even if this is the correct behavior per the documented steps, I worry a little that this may change the way Cilium behaves in production environments and whether that in itself could cause more problems than the bug being fixed. Do you have a sense for the risk of making this change? Could we start dropping traffic that was previously passed for instance?

(To be clear, this question relates to the backports; for future versions and even v1.17.x it sounds like the fix makes sense 👍 )

I personally dont think this will cause any issue unless the users don't use this feature correctly (for example the packet following the default/other route ip table rules via eth0, and this bug fix will make the packet going to eth1 or eth1.1 based on the route table.) that's the only changes that I can think of.

[aditighag]

Thanks for the fix.

Based on the documentation, I wonder if the correct way to get the expected masquerading behavior is by setting the flag egress-masquerade-interfaces to something like eth+.

With the enable-masquerade-to-route-source: "true" option, Cilium will, by default, use interfaces listed in the devices field as the egress masquerade interfaces when egress-masquerade-interfaces is empty. When egress-masquerade-interfaces is set, it takes precedence over devices to choose which network interface should perform masquerading. You can set egress-masquerade-interfaces to match multiple interfaces like this: eth+ ens+.

[liyihuang]

yes. and the more common config is people using the eth+ in devices field and egress-masquerade-interfaces is empty, and we need to handle that. People could also configure the egress-masquerade-interfaces with eth+. Before this PR, we say it could take eth+ in doc but it can't.

Btw the doc that you copied is also written by me where I have incorrect understanding about how it works

Hope I made it clear.

[aditighag]

Please add a release note before the PR is merged.

[aditighag]

@liyihuang FYI - I rephrased the release note as its purpose is to convey "what user-facing bug was fixed" rather than "how the bug was fixed".