Closed atenart closed 1 year ago
nftables already has its own ruleset tracing mechanism and this can be considered as one of the possible ways to collect info.
Normally those infos are collected via netlink like it's done using nft monitor trace
.
The upside is that the data collection is stable over time as it happens through netlink.
One of the potential downsides of this approach is that the matching packets to trace should be determined by the nft rules. This requires the need to add such rules, that is, only the collecting phase of the tool will play a role in this way.
As a potential alternative approach, it should be possible to probe:
static noinline void __nft_trace_packet(struct nft_traceinfo *info,
const struct nft_chain *chain,
enum nft_trace_types type)
This way it is still possible to collect the needed info, but it should still be possible to match packets without the need of adding specific nft rules. Also, the hook chain will run creating the requested events.
The creation of a regular chain without hooks is still required to enable the tracing static branch so that __nft_trace_packet() gets called.
table inet packet_tracer { # handle 3
chain trace_chain { # handle 4
meta nftrace set 1 # handle 5
}
}
Given that "by itself a regular chain does not see any traffic", this would not trigger any netlink event in the case listeners are present. The potential downside of this approach is mostly stability (although the logic seems fairly settled, there are no guarantees over time unlike with the netlink approach). The upside, as described above, is that the solution would be integrated and both filtering, hooks and potential additions can still potentially remain in place.
Done in #137.
Investigate and see if we can support a collector retrieving firewalling data. The use case would be for example to link a packet being dropped to an installed rule.