nftables未来要替换iptables, 目前还处于开发状态.
nftables is the new packet classification framework that intends to replace the existing {ip,ip6,arp,eb}_tables infrastructure. In a nutshell:
- It is available in Linux kernels >= 3.13.
- It comes with a new command line utility nft whose syntax is different to iptables.
- It also comes with a compatibility layer that allows you to run iptables commands over the new nftables kernel framework.
- It also comes with the generic set infrastructure that allows you to construct mappings between matchings and actions for performance lookups.
- This software is under development, so get ready to report bugs in case you experience problems. Netfilter's bugzilla is your friend.
CentOS 7.0 的内核还是3.10的, 所以nftables暂时不会出现在7.0的版本中.
需要试用的话, 可以下载nftables源码, 重新编译内核.
相比iptables的好处
Main Features
- Pseudo-state machine in kernel-space: the userspace utility nftables interprets the rule-set provided by the user (using a new syntax), it compiles it into the pseudo-state machine bytecode and then it transfers it to the kernel via the nftables Netlink's API. Roughly, the idea behind nftables is similar to the Berkeley Packet Filters (BPF).
- Fast lookups through performance data structures: The new syntax allows you to arrange you rule-set in a very performance way contrary to purely linear-list based filtering policies. Nftables allows you to use set-based action mappings, ie. for a matching element in the set, issue the action specified by the user.
- Reduce the amount of code in kernel-space. You can express the packet selectors for all existing protocols using the instruction-set provided by the nftables pseudo-state machine. That means that we do not need a specific extension in kernel-space for each protocol that you want to support. As a side effect, you are likely not need to upgrade your kernel to obtain new features as it has been designed to keep most of the logic in user-space.
- Unified interface to replace iptables/ip6tables/arptables/ebtables utilities. Thus, we will be able to fully get rid of all the existing code replication in kernel and user-space.
Main differences with iptables
The main differences between nftables and iptables from the user point of view are:
- The syntax. The iptables command line tool uses a getopt_long()-based parser where keys are always preceded by double minus, eg. --key or one single minus, eg. -p tcp. In that regard, nftables uses cleaner syntax which is inspired by tcpdump.
- Tables and chains are fully configurable. Contrary to iptables that comes with a set of already defined tables and chains, nftables allows you to create your own tables and chain configurations. We have gotten reports in the past that unused predefined chains were harming performance, even if unused. With this new approach, you can just register the chains that you need depending on your setup.
- No distinction between matches and targets anymore. In nftables, we have expressions that are basically instructions that can be used to build the rule. This approach is radically different from iptables, that requires specific extensions to match protocol header fields and packet meta information.
- You can specify several actions in one single rule. In iptables you can only specify one single target. This has been a longstanding limitation that has been resolved by jumping to custom chains at the cost of making the rule-set structure slightly a bit more complex.
- No built-in counter per chain and rules. In nftables, these are optional so you can enable counters on demand.
- Generic set infrastructure. This infrastructure integrates tightly into the nftables core and it allows advanced configurations such as dictionaries, maps andintervals to achieve performance-oriented packet classification. The most important thing is that you can use any supported selector to classify traffic.
- New supported protocols without kernel upgrades. Kernel upgrade is a timeconsuming task, specifically if you have to maintain more than one single firewall in your network. Distributors usually include a bit older Linux kernel versions for stability reasons. With the new pseudo-state machine approach, you will most likely not need such upgrade to support a new protocol, a relatively simple nft userspace utility update should be enough to obtain it.
[参考]
