The essential knowledge of implementing transparent firewalls-bridge filter half view

NetFilter is an excellent framework for a highly customizable protocol stack that has long been included in the Linux kernel, and its design can be found on its official website with more than N to look at. The most talked about is the design of the location of the hook point (the core of the design that foreigners are concerned about, rather than how to implement it, and after the implementation of the source code analysis), it is best to look at these discussions.
If you want to implement a transparent firewall, then the understanding of several netfilter framework is unavoidable, there will be some problems, such as the following several questions:
1. Why output design is after routing.
2. Why forward is designed after routing.
3. Why are there so many stolen in the NetFilter hook function of bridging layer?
For question 1, I find it not difficult to answer, because the Linux routing module directly distinguishes between local and non-local concepts, and the routing result contains a lot of information about the target device, including network card information, send callback functions, and so on, and has selected the source IP address (for TCP,UDP, in the case of TSO, Because the checksum code is computed before entering the IP layer, need a pseudo head, and the pseudo header has a source IP address, so before entering the IP layer needs to be routed first, output this hook point required information is basically after the route is determined, Dnat is the hook point on the more special, Because it changes the destination address, it needs to be rerouted, and of course the responsibility for rerouting after the Dnat is for the Dnat module itself. Answer the question 1, question 2 basically do not have to answer, as to question 3, it is more complicated, because this involves bridge NetFilter and IP netfilter linkage problem.
Bridge and IP in the transparent firewall is required linkage, because the IP layer can be more control, such as more strategies (string match) for filter, such as can be based on the five elements of the connection tracking, although these can be done in the bridge layer, But the modularity and kiss principle separates bridge from these complex strategies so that it only handles what it should, and if it needs the help of the IP layer, call directly, and the NetFilter mechanism uses nf_ The hook macro allows a packet of any layer to be processed by any hook on any layer, and the hook function traversal of each hook point can be interrupted at any point (nf_stop), Then, at any other place at any time, we continue to iterate over the interrupted hook function at the interrupted Hook point, which is done by Nf_hook_thresh macros, and any hook-point hooks can steal packets (Nf_stolen), as shown in the following illustration:

It is this flexibility that brings complexity. The NetFilter of Linux uses the IP netfilter hook in the bridge layer's execution, In the case of net.bridge.bridge-nf-call-iptables, the situation is more complicated, the data packets entering the bridge need to pass through the IP layer of the prerouting and postrouting these two hooks, while the ip-prerouting may be dnat, and be After the Dnat packet needs to be routed by the IP layer, so it cannot continue to move forward in the bridge layer, it must enter the local IP layer, the result may be routed from the same bridge device, or it may be issued from the other network card, if the same bridge issued, Then will enter the bridge of the Local-out, otherwise the packet will be imported into the local IP layer processing, due to bridge processing has passed ip-prerouting, then this will be directly bypassed ip-prerouting ... How it all happened. Text description is not easy, look at the code before I first show a picture, may have seen this diagram, there is no need to look at the code:

The diagram shows how a packet passes through each of the hook points in bridge and how to interact with the hook point in the IP layer, very complex, this figure should be horizontal, but limited to the width of the display, or portrait, the minimum scroll bar is almost unlimited, and the longitudinal scroll bar is more usable than the horizontal scroll bar (with Apple's 360-degree wheel mouse, of course, that's the exception). The deal is complicated, but from this picture, it's very organized. If you want to implement a transparent firewall, it is necessary to understand this picture. Of course, if you look at the code is also very good, but first look at the code always feel a bit messy, you can not find out which is the main path, which is the secondary path, it is difficult to have the patience to first netfilter the basic framework before you go to see the code, basically, NetFilter's core framework 1. Several hook points
2. A hook function sorted by priority on each hook
3.nf_hook_thresh macro
4.nf_hook_ops structure
5. Several nf_xx_hook_ Priorities Precedence enumeration