About the design of bridge-nf-call-iptables

If you are familiar with ebtables and iptables about the design of bridge-nf-call-iptables, the latter provides more options than the former, however, this does not mean that the IP layer features more abundant than the data link layer, because as long as the data packet enters the NIC, the protocol stack code will be able... if you are familiar with ebtables and iptables about the design of bridge-nf-call-iptables, the latter provides more options than the former, however, this does not mean that the IP layer features richer than the data link layer, because as long as the data packet enters the NIC, the protocol stack code can "see" the entire data packet, the remaining problem is how to resolve and filter. as long as you are willing, the protocol stack can provide the same filtering functions as the IP layer at the data link layer, such as ip_conntrack. Www.2cto.com, however, the protocol stack is not implemented in this way, because it will cause serious code redundancy and high maintenance costs. The bridge filter in Linux provides the bridge-nf-call-iptables mechanism to enable the bridge Netfilter to reuse the Netfilter code at the IP layer. Netfilter provides a powerful filter match and stream recognition mechanism, so that each data packet can be associated with a stream marked by a quintuple, in this way, we can perform more humane operations on the entire stream instead of individual data packets, and the mark mechanism is the most effective for stream recognition and subsequent filtering. Note that this mark is not the data packet itself, it is only valid in the local protocol stack. The Netfilter code can identify the header package of a stream and then inject a mark into the stream, the next packet can directly retrieve the mark from the stream for filtering without having to traverse the entire rule chain. the following rules are commonly used: www.2cto.com iptables-t mangle-I PREROUTING-j CONNMARK -- restore-markiptables-t mangle-A PREROUTING-m mark! -- Mark 0-j ACCEPTiptables-t mangle-a prerouting-m state -- state ESTABLISHED-j ACCEPTiptables-t mangle-N mark_Policy "iptables-t mangle-A mark_Policy $ matches1-j MARK -- set-mark 100 iptables-t mangle-A mark_Policy $ matches2-j MARK -- set-mark 100 iptables-t mangle-A mark_Policy-m mark! -- Mark 0-j CONNMARK -- save-mark is similar to a cache mechanism. only the first packet of a stream needs to traverse the entire rule chain, and the rest can be directly restore the mark, next, the protocol stack can filter or perform Policy Routing based on the mark. If bridge-nf-call-iptables is used, can the bridge layer take advantage of the above advantages? For example, to decide which data packets need to be captured locally and which data packets need to be discarded, the answer is ambiguous and not absolute. For the second problem above, we can decide which data packets need to be discarded, because bridge-nf-call-iptables acts on the PREROUTING of bridge Netfilter, you can select Drop or not on FORWARD, which has no problem. However, for the first problem, which packets need to be captured by the local IP layer, the current implementation is powerless, however, the problem can be solved only by modifying the code of a few two-line bridge modules. However, if you can perform such a small operation to solve such a large problem, you need to accumulate a lot of common sense. I am not boasting about it, this is the truth. Before providing a solution, I will first show where to use the data frame that should be bridge to the local IP layer. if there is no actual need to modify the code, that is not too academic. A typical requirement is transparent bridge VPN. VPN encryption and encapsulation must be performed at the IP layer. Therefore, the streams of interest must be captured to the IP layer, if you are not interested in the stream directly bridge out, this is a practical requirement. However, the code of the existing bridge module cannot be solved. why? Listen to me. In the bridge code of Linux, bridge-nf-call-iptables is reflected in the br_nf_pre_routing function. This function is also a Netfilter HOOK function: [plain] static struct nf_hook_ops br_nf_ops [] _ read_mostly = {{. hook = br_nf_pre_routing ,. owner = THIS_MODULE ,. pf = PF_BRIDGE ,. hooknum = NF_BR_PRE_ROUTING ,. priority = NF_BR_PRI_BRNF ,},...} at the end of the function: [plain] NF_HOOK (PF_INET, NF_INET_PRE_ROUTING, skb, skb-> dev, NULL, br_nf_pre_routing_finish); Netfi at the IP layer is called. Lter PREROUTING code. I want to first call the Netfilter at the IP layer and set the mark of interest stream in its mangle table, in the bridge nat table, mark the data frame redirect to the local IP layer. Unfortunately, this cannot be done because of the priority relationship. the priority of br_nf_pre_routing is NF_BR_PRI_BRNF, it is located after the nat priority: [plain] enum nf_br_hook_priorities {NF_BR_PRI_FIRST = INT_MIN, priority =-300, // NAT priority =-200, NF_BR_PRI_BRNF = 0, // priority of br_nf_pre_routing: NF_BR_PRI_NAT_DST_OTHER = 100, NF_BR_PRI _ FILTER_OTHER = 200, NF_BR_PRI_NAT_SRC = 300, NF_BR_PRI_LAST = INT_MAX,}; therefore, this mark cannot be used for NAT even if Netfilter on the IP layer adds a mark to the data frame, so now you have performed NAT... if you say you can also hot direct data frames to the local IP layer on BROUTING, then your device will be completely an IP layer device, although the bridge semantics can be maintained (for example, the arp data frame is omitted), this design will make your product documentation confusing, and your psychological expectation will also be a thousand miles away from what you finally think. Finally, let's take a look at how to modify the code to solve this problem. The most essential thing is to modify the priority of the br_nf_pre_routing HOOK function so that it runs after the bridge NAT. this is better. modify the br_netfilter.c code: [plain] static struct nf_hook_ops br_nf_ops [] _ read_mostly = {{. hook = br_nf_pre_routing ,. owner = THIS_MODULE ,. pf = PF_BRIDGE ,. hooknum = forward, # ifdef IP_FILTER_BEFORE_NAT/*** 2013/03/06 by Zhao Ya * enable PREROUTING of iptables before DNAT of ebtables. * because the DNAT of the bridge uses the mark set by iptables */. priority = NF_BR_PRI_NAT_DST _ BRIDGED-1, # else. priority = NF_BR_PRI_BRNF, # endif... another modification is br_nf_pre_routing_finish. The problem involves where to continue after IP Netfilter is executed. The last modification of this function is: [plain] # ifdef restart/*** 2013/03/06 by Zhao Ya * restart NF_BR_PRI_BRNF */restart (PF_BRIDGE, train, skb, skb-> dev, NULL, br_handle_frame_finish, complete ); # else NF_HOOK_THRESH (PF_BRIDGE, NF_BR_PRE_ROUTING, skb, skb-> dev, NUL L, br_handle_frame_finish, 1); # endif NF_BR_PRI_BRNF is defined as 0. if the implementation of the standard 2.6.32 kernel is followed, it should start from priority 1. However, in our modified version, because NAT has not been executed yet, we need to start from NAT, and our br_nf_pre_routing priority is set to NAT priority minus 1, then we should start from NAT. This modification does not mean that there are no side effects. it makes the standard implementation, that is, the benefits brought by the assumption that NAT is located before IP Netfilter are completely invalid. just remember this point.