Nftables families: Difference between revisions
(→ip6: Linked Wikipedia IPv6 page, lightly edited for clarity.) |
(→inet: Edited for clarity.) |
||
Line 17: | Line 17: | ||
== inet == | == inet == | ||
Tables of this family | Tables of this family see both IPv4 and IPv6 traffic/packets, simplifying dual stack support. | ||
Within a table of ''inet'' family, both IPv4 and IPv6 packets traverse the same rules. Rules for IPv4 packets don't affect IPv6 packets. Rules for both L3 protocols affect both. | |||
Rules for both L3 | |||
Examples: | Examples: | ||
<source> | <source> | ||
# | # This rule affects only IPv4 packets: | ||
add rule inet filter input ip saddr 1.1.1.1 counter accept | add rule inet filter input ip saddr 1.1.1.1 counter accept | ||
# | |||
# This rule affects only IPv6 packets: | |||
add rule inet filter input ip6 daddr fe00::2 counter accept | add rule inet filter input ip6 daddr fe00::2 counter accept | ||
# | |||
# These rules affect both IPv4 and IPv6 packets: | |||
add rule inet filter input ct state established,related counter accept | add rule inet filter input ct state established,related counter accept | ||
add rule inet filter input udp dport 53 accept | add rule inet filter input udp dport 53 accept |
Revision as of 16:33, 22 February 2021
Netfilter enables filtering at multiple networking levels. With iptables there is a separate tool for each level: iptables, ip6tables, arptables, ebtables. With nftables the multiple networking levels are abstracted into families, all of which are served by the single tool nft.
Please note that what traffic/packets you see and at which point in the network stack depends on the base chain hook you are using.
Following are descriptions of current nftables families. Additional families may be added in the future.
ip
Tables of this family see IPv4 traffic/packets. The iptables tool is the legacy x_tables equivalent.
ip6
Tables of this family see IPv6 traffic/packets. The ip6tables tool is the legacy x_tables equivalent.
inet
Tables of this family see both IPv4 and IPv6 traffic/packets, simplifying dual stack support.
Within a table of inet family, both IPv4 and IPv6 packets traverse the same rules. Rules for IPv4 packets don't affect IPv6 packets. Rules for both L3 protocols affect both.
Examples:
# This rule affects only IPv4 packets:
add rule inet filter input ip saddr 1.1.1.1 counter accept
# This rule affects only IPv6 packets:
add rule inet filter input ip6 daddr fe00::2 counter accept
# These rules affect both IPv4 and IPv6 packets:
add rule inet filter input ct state established,related counter accept
add rule inet filter input udp dport 53 accept
arp
Tables of this family will see ARP-level (i.e, L2) traffic, before any L3 handling is done by the kernel. The arptables tool was the equivalent in the old x_tables world.
bridge
Tables of this family will see traffic/packets traversing bridges (i.e. switching). No assumptions are made about L3 protocols. The ebtables tool was the equivalent in the old x_tables world. Also, some old x_tables modules such as physdev will eventually be served natively from this family.
Note that there is no nf_conntrack integration for this family. However this may change in the future.
netdev
This family provides the ingress hook, that allows you to classify packets that the driver has just passed up to the networking stack. This means you see all network traffic for your NIC getting in. No assumptions are made about L2 or L3 protocols, therefore you can filter ARP traffic from here.
Note that there is no equivalent in the old iptables world, this is a new feature available since Linux kernel 4.2 for nftables.
This location is ideal to drop packets that result from DDOS attacks given this is very early in the packet path. Dropping packets from here is much more efficient than from the classic prerouting chain, by a factor of 2x.
You can also use this new ingress hook for load balancing, including Direct Server Return (DSR), that has been reported to be 10x faster.