Migrate network-setup to nftables and improve it into a better state

[kanpov]

Changes

network-for-clones is not changed in this PR since it's a whole another can of worms I'd like to deal with later.
These changes are to network-setup:

• Migrate to nftables

• Improve the documentation itself to convert it from a rather basic getting started guide to something more usable in the real world:

• Multiple guests section

• Guest kernel configuration at kernel level section (ip kernel boot arg)

Reason

Fulfills #4874

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

• If a specific issue led to this PR, this PR closes the issue.
• The description of changes is clear and encompassing.
• Any required documentation changes (code and docs) are included in this
  PR.
• API changes follow the Runbook for Firecracker API changes.
• User-facing changes are mentioned in CHANGELOG.md.
• All added/changed functionality is tested.
• New TODOs link to an issue.
• Commits meet
  contribution quality standards.

---

• This functionality cannot be added in rust-vmm.

[kanpov]

I'm welcome to critique of the new sections in the doc, since I think this is the real minimal amount of information needed for a Firecracker user to get a proper networking setup with support for multiple guests and other improvements. Back when I started working with Firecracker, I found this specific area of the docs to be especially frustrating to use (and led to me spending far, far too much of my time developing fcnet to make networking bearable):

• Why shouldn't I use it if I just have another iface instead of eth0, why not just say you can replace the name?
• Why no indications on how to support multiple guests?
• Why no explanations of what the iptables or ip commands actually do for people unfamiliar with NAT, TUN/TAP and gateways?

With this, I've tried to address these.

[pb8o]

Thanks for your contribution! I need to try the commands myself, but looks good so far.

I have a couple of asks: could we squash the commits together? I think it becomes easier to review. And we would like to keep the iptables commands for some time until nft becomes more spread.

[kanpov]

Thanks for your contribution! I need to try the commands myself, but looks good so far.

I have a couple of asks: could we squash the commits together? I think it becomes easier to review. And we would like to keep the iptables commands for some time until nft becomes more spread.

I'll apply the squash and, as for iptables, I like your idea for collapsible blocks as opt-in for using it.

Iptables, however, is most certainly no longer the default and, even when it's used, it's used only through the iptables-nft compat layer which is already itself deprecated on some distros (including RHEL).

So I'll do a collapsible choice between iptables-nft and just nft.

[kanpov]

@pb8o Sorry for the delay! I've fixed the problems, and made an effort to support both nft and iptables-nft seamlessly. For the methods of routing, I explicitly highlighted 3 of them: NAT, referring to the main portion of the article, bridge-based, referring to the dedicated section, and namespaced, referring to "Network for Clones" (which will need another PR to perform some extremely needed fixing as well). Would appreciate another look!

I explicitly don't want to encourage using the legacy iptables command instead of iptables-nft, since it leads to both nf_tables and x_tables kernel routing modules being used at the same time and them conflicting with each other while trying to both do packet filtering each according to their own rules. So, I suggest iptables-nft in the current revision, which has the same syntax so should be compatible with your requirements, but doesn't cause such conflicts by internally translating commands to nft syntax.

[kanpov]

For the squashing, I'm pretty sure the PR can just be merged with the "squash and merge" option to clean everything up.

[pb8o]

I explicitly don't want to encourage using the legacy iptables command instead of iptables-nft

In my Ubuntu machine the default is iptables-nft, but I guess it doesn't hurt to make it explicit.

% ll /usr/sbin/iptables
lrwxrwxrwx 1 root root 26 2024-02-22T09:25 /usr/sbin/iptables -> /etc/alternatives/iptables
% ll /etc/alternatives/iptables
lrwxrwxrwx 1 root root 22 2024-02-22T09:23 /etc/alternatives/iptables -> /usr/sbin/iptables-nft
% iptables --version
iptables v1.8.7 (nf_tables)

[kanpov]

In my Ubuntu machine the default is iptables-nft, but I guess it doesn't hurt to make it explicit.

Fedora 40 and 41 have it as default as well, but openSUSE Leap and Tumbleweed still use x_tables and enable it by default, and those are pretty significant.

[pb8o]

Thanks, this looks good to me!

[pb8o]

Ok so I saw some style checks failing, here is how to make it happy:

1. Run ./tools/devtool fmt and mdformat will reformat the markdown to its liking.
2. Could you squash the commits into one? We use gitlint and make sure each commit follows the contribution guidelines

You can check if the styles check pass by running ./tools/devtool checkstyle

[kanpov]

Messed up the commit tree, will have to remake the PR(