The difference between brouting and prerouting redirect in ebtables

Both ebtables and iptables use the netfilter framework, which is the same. However, the two actually need to be linked. Many people do not understand the difference between the Redirect of the ebtales broute table and the Redirect of the NAT table prerouting. In fact, you only need to remember two points, that is, the same point, they all direct data packets to the local IP layer. For different points, the Redirect in the broute table sets the receiving device of the data packet to the physical network card that actually receives the data, the NAT table sets the receiving device of data packets as a bridge device, which can be viewed in the source code of the Linux protocol stack. For the Redirect of the broute table, you can see the following statement in the callback function called by br_handle_frame handle_bridge:

switch (p->state) {case BR_STATE_FORWARDING:    rhook = rcu_dereference(br_should_route_hook);    if (rhook != NULL) {        if (rhook(skb))            return skb;        dest = eth_hdr(skb)->h_dest;    }    /* fall through */case BR_STATE_LEARNING:    if (!compare_ether_addr(p->br->dev->dev_addr, dest))        skb->pkt_type = PACKET_HOST;    NF_HOOK(PF_BRIDGE, NF_BR_PRE_ROUTING, skb, skb->dev, NULL,        br_handle_frame_finish);    break;...

Let's take a look at the callback function ebt_broute br_should_route_hook:

static int ebt_broute(struct sk_buff *skb){    int ret;    ret = ebt_do_table(NF_BR_BROUTING, skb, skb->dev, NULL,               dev_net(skb->dev)->xt.broute_table);    if (ret == NF_DROP)        return 1; /* route it */    return 0; /* bridge it */}

It enters the target that we are all familiar with the xxx_do_table function, that is, the general netfilter rule search operation, and finally enters the Redirect target when the matching rule is found. If there is no broute table rule, it will enter the nf_hook hook, during which all the nf_br_brouting rules will be passed. if a target is hit by the Redirect rule, it will also enter the Redirect target, what is this target? It is the function of ebt_redirect_tg:

Static unsigned intebt_redirect_tg (struct sk_buff * SKB, const struct xt_target_param * par) {const struct ebt_redirect_info * info = par-> targinfo; If (! Skb_make_writable (SKB, 0) return ebt_drop; If (par-> hooknum! = Nf_br_brouting) // if it is a NAT prerouting, copy the MAC address of the bridge to the destination MAC address of the packet. Memcpy (eth_hdr (SKB)-> h_dest, par-> In-> br_port-> Br-> Dev-> dev_addr, eth_alen); else // For brouting tables, then, copy the MAC address of the physical NIC that actually receives the data packet to the destination MAC address of the data packet. Memcpy (eth_hdr (SKB)-> h_dest, par-> In-> dev_addr, eth_alen); // the local machine can receive this data packet SKB-> pkt_type = packet_host; // usually return drop return Info-> target ;}

From br_handle_frame, we can see that once the broute table's matching rule returns drop, handle_bridge directly returns this SKB and does not execute it downward. This means that SKB will continue along netif_receive_skb after handle_bridge returns, if no broute table rule is matched, it may be hit in the prerouting chain of the NAT table. After ebt_redirect_tg is executed, br_handle_frame_finish is called to continue. In br_handle_frame_finish, because the destination MAC address has been changed to the MAC address of the local Nic, br_pass_frame_up will be called to send the packet to the upper layer of the Protocol Stack:

Static void br_pass_frame_up (struct net_bridge * Br, struct sk_buff * SKB) {struct net_device * indev, * brdev = Br-> dev; brdev-> stats. rx_packets ++; brdev-> stats. rx_bytes + = SKB-> Len; indev = SKB-> dev; // modify the dev of SKB to brx. Then, after local_in, call netif_receive_skb again, in netif_receive_skb, The handle_bridge handler will not be accessed again] (my little press ...). SKB-> Dev = brdev; nf_hook (pf_bridge, nf_br_local_in, SKB, indev, null, netif_receive_skb );}

Note: After redrect in the broute table, the data packet receiving device is the actual physical network adapter ethx, And the destination MAC address is the MAC address of the physical network adapter ethx, and after the Redirect of the NAT prerouting, the receiving device of the data packet is a bridge device, and the destination MAC address is the MAC address of the bridge device. After knowing this, let's look at the Redirect problem of the NAT table of the next and iptables.
Assume that the eth0 IP address of the local machine is 1.1.1.254/24, port 88 of TCP is enabled, and the IP address of host h directly connected to the local machine is 1.1.1.2/24, configure on S:

Brctl addbr br0brctl addif eth0ifconfig br0 1.1.1.254/24 ifcongig eth0 0.0.0.0 # To prevent route chaos, therefore, delete the IP address iptables-T Nat-A prerouting-D 2.2.2.2-p tcp -- dport 1234-J redirect -- to-ports 88 of eth0.

Execute on H

route add -host 2.2.2.2 gw 1.1.1.254telnet 2.2.2.2 1234

What are the results? No! No syn-Ack is received. However, you can delete the Redirect rule on S and execute the following rule:

iptables -t nat -A PREROUTING -d 2.2.2.2 -p tcp --dport 1234 -j DNAT --to-destination 1.1.1.254:88

Is there any difference between DNAT and redirect? If you do not understand the differences between the two, you can understand the differences between SNAT and masquerade. DNAT and SNAT can specify any
Similar to masquerade, redirect can specify any destination address. It is only a destination address selected by the kernel based on its own policy, just as masquerade is
The core is the same as the source address selected based on the RFC recommendations and its own policy. So how to select the destination address of redirect? Take a look at the man manual of iptables:
Redirect

This target is only valid in the NAT table, in the prerouting and output chains, and user-defined chains which are only called from those
Chains. It redirects the packet to the machine itself by changing the destination IP to the primary address of the incoming interface (locally
-Generated packets are mapped to the 127.0.0.1 address ).
Note the phrase "to the primary address of the incoming interface. How does the Redirect rule in the kernel achieve this? You need to take a look at the code to know:

Static unsigned intredirect_tg (struct sk_buff * SKB, const struct xt_target_param * par ){... if (par-> hooknum = nf_inet_local_out) newdst = htonl (0x7f000001); else {struct in_device * indev; struct in_ifaddr * IFA; newdst = 0; rcu_read_lock (); indev = _ in_dev_get_rcu (SKB-> Dev); // retrieve the IP address of the receiving device if (indev & (IFA = indev-> ifa_list) newdst = IFA-> ifa_local; rcu_read_unlock (); // if the recipient does not have an IP address, the discarded packet if ( ! Newdst) return nf_drop;}... return nf_nat_setup_info (CT, & newrange, ip_nat_manip_dst );}

Now we understand everything. Since redirect in the broute table sets the receiving device as the actual physical Nic, And the IP address of this Nic has been deleted, the newdst of the above function does not exist, so the data packet is dropped. So far, the problem is very clear. It can be seen that the Redirect method of ebtables directly affects the Redirect method of iptables. To make the Redirect method of iptables still feasible at any time when using bridge, you must set an IP address for the NIC that enables broute redirect, to avoid route conflicts, consider 127.0.0.2...
Note: The meaning of the broute table
Why is there such a problem? Broute is the reason. The so-called broute is the bridge or router, similar to the Cat sent by the carrier when broadband was installed earlier. It can be used as a bridge device or as a router. If a router does not have a bridge device, it is a matter of course to set the receiving device as the actual physical Nic.