[v1.14] bpf: lxc: defer CT_INGRESS entry creation for loopback connections #27920
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
maintainer-s-little-helper
bot
added
backport/1.14
|
/test-backport-1.14 |
youngnick
approved these changes
Sep 5, 2023
julianwiedmann
force-pushed
the
v1.14-lxc-ct-ingress
branch
from
d4eb125
to
ee4e0bc
Compare
|
(resolve a context conflict with #27381) |
|
/test-backport-1.14 |
4 tasks
qmonnet
approved these changes
Sep 7, 2023
[ upstream commit dbf4351 ] [ backporter's notes: bring back ipv4_ct_tuple_swap_addrs() to avoid churn in the tests. ] Currently the CT_INGRESS entry for a loopback connection is already created when the first request leaves the client, as from-container creates the CT_EGRESS entry (see the loopback handling in ct_create4() for details). This is unusual - we would normally just create the CT_INGRESS entry as the first packet passes through to-container into the backend. But for loopback connections it is needed, so that 1.) to-container finds a CT entry with .loopback set, and thus skips network policy enforcement even for the first packet, and 2.) the CT entry has its rev_nat_index field populated, and thus can RevNAT replies in from-container. This approach conflicts with the fact that loopback replies skip the client's to-container path (to avoid network policy enforcement). Once the loopback connection is closed, the backend's from-container path observes the FIN / RST, and __ct_lookup4() updates the CT_INGRESS entry's lifetime to CT_CLOSE_TIMEOUT. But the client's to-container path will not observe the FIN / RST, and thus the CT_EGRESS entry's lifetime remains as CT_CONNECTION_LIFETIME_TCP. Therefore the CT_INGRESS entry will expire earlier, and potentially gets garbage-collected while the CT_EGRESS entry stays in place. If the same loopback connection is subsequently re-opened, the client's from-container path finds the CT_EGRESS entry and thus will *not* call ct_create4(). Consequently the CT_INGRESS entry is not created, and the backend will not apply the loopback-specific handling described above. Inbound requests are potentially dropped (due to network policy), and/or replies are not RevNATed. Fix this up by letting the backend path create its CT_INGRESS entry as usual. It just needs a bit of detection code in its CT_NEW handling to understand that the first packet belongs to a .loopback connection, and populate its own CT_INGRESS entry accordingly. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
[ upstream commit f0b44c0 ] The test currently assumes SVC_PORT == BACKEND_PORT. This limits the test coverage (we're not testing that L4 NAT works properly), and isn't strictly required in real world scenarios. Change the test so that the backend uses a different port. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
julianwiedmann
force-pushed
the
v1.14-lxc-ct-ingress
branch
from
ee4e0bc
to
2ad7ac0
Compare
|
/test-backport-1.14 |
|
(one more round of CI to make the branch protection happy) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Manual backport (due to contextual conflicts and missing test infra) of:
Once this PR is merged, you can update the PR labels via:
or with