On 2/4/21 9:07 AM, Thomas Lamprecht wrote:
On 03.02.21 15:25, Mira Limbeck wrote:
Dumping conntrack information and importing conntrack information works
for IPv4 and IPv6. No filtering is supported for now. pve-conntrack-tool
will always return both IPv4 and IPv6 conntracks together.

Conntracks are serialized as JSON and printed on STDOUT line by line
with one line containing one conntrack. When inserting data is read
from STDIN line by line and expected to be one JSON object per line
representing the conntrack.

Currently some conntrack attributes are not supported. These are
HELPER_INFO, CONNLABELS and CONNLABELS_MASK. The reason for this is that
handling of variable length attributes does not seem to be correctly
implemented in libnetfilter_conntrack. To fix this we would probably have
to use libmnl directly.

Conntracks containing protonum 2 (IGMP) are ignored in the dump as
they can't be inserted using libnetfilter_conntrack (conntrack-tools'
conntrack also exhibits the same behavior).

Expectation support, which is necessary for FTP and other protocols, is
not yet implemented.

Signed-off-by: Mira Limbeck <m.limb...@proxmox.com>
---
v2:
  - changed Conntracks to Socket
  - reworked a lot of the code for less code duplication
  - reduced usage of 'unsafe'
  - added/changed things based on @Wobu's suggestions (off-list)

  Cargo.toml                 |  14 ++
  src/main.rs                | 488 +++++++++++++++++++++++++++++++++++++
  src/mnl.rs                 | 132 ++++++++++
  src/netfilter_conntrack.rs | 168 +++++++++++++
  4 files changed, 802 insertions(+)
  create mode 100644 Cargo.toml
  create mode 100644 src/main.rs
  create mode 100644 src/mnl.rs
  create mode 100644 src/netfilter_conntrack.rs

I take a (very) quick look at it and the code itself seems quite sensible.

One higher level question though, would it makes sense do have the whole
plumbing and general socket interfacing in it's own library crate (or sub
workspace or something like that) and the binary here separate and as
plain user of that create.

That way we could additionally publish it on crates.io, could be helpful
form some people (even if conntrack/nl is certainly a bit of a niche).

What do you think about that?

The bindings are not complete, I only added what I needed during development and sometimes a bit more.

We would have to remove the query_(conntracks|expects) and insert_(conntrack|expect) functions from the Socket then.


For libmnl there are already 2 crates available which provide a wrapper around the low level bindings: https://github.com/mullvad/mnl-rs and https://crates.io/crates/crslmnl which are more complete.

For netlink itself there are also some crates: https://crates.io/keywords/netlink

But I could not find any bindings for libnetfilter_conntrack.




_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Reply via email to