[Bug 1736] nftables - dynamic update for verdict map from the packet path

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1736

--- Comment #6 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to dinhtrason from comment #4)
> > Are you fully using the 32 bits in the mark _only_ for masquerading?
> 
> No, masquerading takes one bit of the packet mark. The location of the bit
> however is not fixed (i.e. it is a configuration option), making the usage
> of meta mark is even more difficult. 

Can you use the conntrack mark (instead of the packet mark)?

Looking at your ruleset, that makes sense to me, because this also allows to
debug via `conntrack -L' what endpoint has being selected for a given flow,
also for netfilter logging as well as `conntrack -E' for event reporting.

> You can refer to masqueradeBit in the link for more details.
> https://kubernetes.io/docs/reference/config-api/kube-proxy-config.v1alpha1/
> #kubeproxy-config-k8s-io-v1alpha1-KubeProxyNFTablesConfiguration
> 
> > 
> > If you use conntrack, then can you use connlabel?
> > 
> 
> No, conntrack is not used in the context of this chain.

You do use conntrack, because I can see 'dnat to' is used in your ruleset after
the endpoint is selected based on the affinity, note that the stateful NAT
engine requires conntrack.

> > I don't have access to your ruleset, I would need a sketch ruleset of you to
> > understand better what you are trying to do and make better suggestions.
> > 
> > Thanks.
> 
> You can refer to the snippet of ruleset highlighted in k8s's pull request
> for more details.
> 
> https://github.com/kubernetes/kubernetes/pull/123168#issuecomment-1931674294
> 
> Note that: I use the trick "ip daddr set ip saddr map
> @affinityMapToEP-DBUHUTQG-default/alpine-service/tcp/iperf" instead of meta
> mark in this example. That works fine for this use-case, but it is not a
> recommended solution from the community.

I have attached a sketch ruleset I build from your link, I mangled it to use ct
mark.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240320/a94330df/attachment.html>