The next-generation packet filtering framework following iptables is nftables.

The next-generation packet filtering framework following iptables is nftables.
At night, I was prepared to go on to tell the story about Netfilter. The text was a little loose. Because I didn't draft a draft, I was a little confused about whether to boast or laugh at myself in one breath, right when I was a child, I like to write my diary every day. I used to copy a few boxes in the name of a retired employee in school. I changed my mind to Zhou Kee in the past few years because I drank alcohol. Now I realized that my life was short, time is not enough. If you can't get through it in a confused way, you are ready to record 1.1 drops of what you know about the Linux network. I would like to continue writing this article on paper, however, I found that in the personal computer smartphone era, many words will not be written long ago... I haven't finished the story about iptables last time. This article continues...
1. the iptables framework knows too much about the kernel state, resulting in a large amount of code redundancy.
2. The rule Structure Design of iptables is unreasonable.
Table {

A. Continue matching the next rule

Loop 1: static breakrule = 0; traverse each rule of a chain {nomatch = 0; loop 2: traverse each match of a rule {result = rule-> match [curr] (skb, info); if (result! = MATCH) {nomatch = 1; break;} if (nomatch = 1) {continue the next rule of the chain;} result = rule-> target (skb, info ); if (result = DROP) {break discard packet} else if (result = ACCEPT) {break ACCEPT packet} else if (result = GOTO) {breakrule = rule; jump to the corresponding chain, execute loop 1} else if (result = RETURN) {break to RETURN the call chain, and execute the next rule of its breakrule }...}After reading the above code, I basically know the command implementation of iptables. What programmers can do is to expand the iptables function. There are two specific practices: Write a match and write a target. In addition, programmers have nothing to do with it. The rest depends on the user's imagination...
A. if you want to implement multiple targets, you have to write multiple rules.
B. You can write a match to secretly do something in it, but you don't know it outside.
@ Hotdrop: drop packet if we had inspection problemsThis hotdrop is used as an outgoing parameter to pass in every match callback function, which indicates to discard a data packet within the match. This exposes the design deficiency. Is it not the target to discard a packet? The role of a match is to determine whether the packet matches. Why should we instruct the packet to discard it? Isn't that an excessive level? This is just a detail. You can give one thousand reasons to indicate that it is reasonable, but it is ugly!
A. How to use a unified method to parse data packets
B. How to execute multiple actions
Loop 1: static breakrule = 0; traverse every rule in a chain {nomatch = 0; reg [MAX] loop 2: traverse each expression {void rule-> expression [curr]-> operations-> expr (skb, info, reg) if (reg [VERDICT]! = CONTINUE) {break;} if (reg [VERDICT] = CONTINUE) {continue the next rule of the chain;} else if (reg [VERDICT] = DROP) {break discard packet} else if (reg [VERDICT] = ACCEPT) {break ACCEPT packet} else if (reg [VERDICT] = GOTO) {breakrule = rule; jump to the corresponding chain, execute loop 1} else if (reg [VERDICT] = RETURN) {break calls the chain, and execute the next rule of its breakrule }...}From the perspective of this process, we can compete with iptables. We can see that nftables does not have match or target, but abstracts a rule into several expressions, that is, expression. The so-called expression is the form of a subject plus a predicate, it is "executable" and can "do anything", not just calculate a matching result. In addition, nftables has a set of built-in registers, one of which is the verdict register, which indicates "what to do next ". After each expression is executed, the register is taken out and the value of the Register takes the next action. This verdict register replaces the target Return Value in iptables, which can take multiple actions in a rule. Each action can be parsed into an expression, after each expression is executed, set the verdict register to CONTINUE!
Payload expression:
Compare expression:
Counter expression:
Log expression:
Nat expression:
Compat expression:
...
Expr1: reg [verdict] = CONTINUE; reg [0] = skb [m... n]; expr2: info [0] = something from userspace; ret = compare (reg [0], info [0]); if (ret = true ); then reg [verdict] = CONTINUE; else reg [verdict] = BREAK; break; fiexpr3: log_packet (skb); expr4: ret = do_nat_packet (skb, reg [I]/* address to trans */...); if (ret = true); then reg [verdict] = CONTINUE; else reg [verdict] = BREAK; break; fi...Let's see how many things a rule has done! The interpreter executes the expression in the order of expr1 to expr4. Check the verdict register before executing the next expression. Who is the interpreter? Of course, the above nftables execution process!
Nft add rule ip filter input ip saddr 1.1.1.1 drop
Tcpdump-I eth0 dst 1.1.1.1
Root @ debian:/usr/local/etc/nftables # tcpdump-I eth0 dst 1.1.1.1-dd
{0x28, 0, 0, 0x0000000c },

Table {

Iptables-a input-m hipac -- match-hipac hipac_test-j NOTHING

Nft-f/usr/local/etc/nftables/ipv4-filter
Nft add rule ip filter output ip daddr 1.2.3.4 drop
Nft add rule ip filter input ip protocol vmap {tcp: jump tcp-chain, udp: jump udp-chain, icmp: jump icmp-chain}
Proto = skb-> net_hdr-> proto; if (proto = tcp) {tcp_chain (skb);} else if (proto = udp) {udp_chain (skb );} else if (proto = icmp) {icmp_chain (skb );}Nftables has become a real programming language! Since it has become a programming language, how flexible will it be to support variables? Fortunately, oh, no, it cannot be lucky, but nftables is a native nature, nftables supports "variables "! Note the following command:
Nft add set filter blackhole {type Limit 4_addr \;}

Nft add map filter mydict {type Limit 4_addr: verdict \;}