-
Notifications
You must be signed in to change notification settings - Fork 790
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
portmap: fix nftables backend #1116
portmap: fix nftables backend #1116
Conversation
2e32a3f
to
92965ed
Compare
We can't use dnat from the input hook, depending on nftables (and kernel ?) version we get "Error: Could not process rule: Operation not supported" iptables backend also uses prerouting. Also 'ip6 protocol tcp' is invalid, so rework / simplify the rules Fixes 01a94e1 Signed-off-by: Etienne Champetier <e.champetier@ateme.com>
92965ed
to
32d1489
Compare
Tested with
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Type: knftables.PtrTo(knftables.NATType), | ||
Hook: knftables.PtrTo(knftables.InputHook), | ||
Hook: knftables.PtrTo(knftables.PreroutingHook), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I think I know what I was confused about: in prerouting
it hasn't yet decided where it's going to route the packet to, so you can't use oifname
. I was thinking that meant you couldn't use fib daddr type
either, but that's wrong; fib daddr type
answers "what does the routing table say we should do with this packet?", not "what are we actually going to do with this packet?", so it doesn't depend on the routing decision.
"th dport", e.HostPort, | ||
"dnat", ipX, "addr . port", "to", containerNet.IP, ".", e.ContainerPort, | ||
e.Protocol, "dport", e.HostPort, | ||
"dnat to", net.JoinHostPort(containerNet.IP.String(), strconv.Itoa(e.ContainerPort)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(yeah, this rule was complicated because it's derived from a kube-proxy rule where we look up the "addr . protocol . port" in a map rather than just having a static rule)
We can't use dnat from the input hook,
depending on nftables (and kernel ?) version we get
"Error: Could not process rule: Operation not supported"
iptables backend also uses prerouting.
Also 'ip6 protocol tcp' is invalid, so rework / simplify the rules
Fixes 01a94e1
Fixes #1115