The Iptables, Mark.

This paper focuses on the implementation of Connmark in the kernel, and also includes Mark's match and target module implementation. Because the Connmark module is usually used in combination with the Mark module. about how to use these three modules in iptables, see my other article "NetFilter Connmark usage and Analysis (i)--iptables The use of the command line." This article welcomes the free reprint, but please indicate the source and this article link, and maintain the integrity of this article. Cu:godbach Blog:http://blog.chinaunix.net/u/33048/index.html Oct 31, 2009 1. Options for Connmark and related modules Here we first list the iptables command line options for the Connmark, Mark, and Mark modules, and then we analyze the kernel implementations of each module individually. The iptables version is v1.3.5. (1) Connmark target option Options feature --set-mark Value[/mask] marks the link tracking record. --save-mark [--mask mask] records the tagged values on the packet to the link tracking record. --restore-mark [--mask mask] Reset the Nfmark value of the packet. (2) MARK Target's options Options feature --set-mark value sets the Nfmark value of the packet. --and-mark values and value of value packets are bitwise AND Nfmark. The Nfmark value of the--or-mark value packet and value are pressed or calculated. (3) MARK Match's options Options feature [!] The Nfmark value of the--mark Value[/mask] packet matches value, where the mask value is optional. The Connmark and Mark match have the mask option, which is primarily used to specify which of the value is to be set. Typically, if we do not specify mask, the value is initially 0xFFFFFFFFUL by default. 2. MARK Target's kernel implementation I am here to analyze the kernel source version is 2.6.18, the module's code see file Xt_mark.c, the core of the target implementation code is as follows: the static unsigned int TARGET_V1 (struct Sk_buff **pskb, struct Net_device *in, The const struct Net_device *out, unsigned int hooknum, The const struct Xt_target *target, The const void *targinfo, *userinfo void) 49 { const struct XT_MARK_TARGET_INFO_V1 *markinfo = targinfo; Wuyi int mark = 0; 52 Switch (markinfo->mode) { Case Xt_mark_set: Mark = markinfo->mark; a break; 57 Case Xt_mark_and: Mark = (*PSKB)->nfmark & markinfo->mark; break; 61 Case XT_MARK_OR: Mark = (*PSKB)->nfmark | markinfo->mark; The break; 65} 66/* Assign the mark value set by the user to the nfmark*/of the packet if ((*PSKB)->nfmark!= Mark) (*PSKB)->nfmark = Mark; 69 Xt_continue return; Copy code mark target three the most commonly used should be--set-mark, which sets the tag for the packet's Nfmark. such as the following rule Iptables-a postrouting-p TCP--dport 21-t mangle-j MARK--set-mark 1 is to set the Nfmark value of the packet that matches the previous matching option to 1. The corresponding source code in the kernel is: case Xt_mark_set: Mark = markinfo->mark; a break; Option--and-mark corresponds to the source code: Case Xt_mark_and: Mark = (*PSKB)->nfmark & markinfo->mark; break; The copy code function is to place the Nfmark value of the record in the packet and the value of the user setting to bitwise. The same option--or-mark is the value of the Nfmark and user settings recorded in the packet, and the source code is as follows: Xt_mark_or: Mark = (*PSKB)->nfmark | markinfo->mark; The break; Copy code The module finally determines whether the mark value that is set is equal to the Nfmark value saved in the packet, and if it does not, then the Nfmark value of the update packet is the mark just set. The code is as follows:->nfmark if ((*PSKB)!= Mark) (*PSKB)->nfmark = Mark; Copy code personally feel that if the packet Nfmark and mark are equal, it is OK to give Mark to Nfmark directly. Here add an if to judge, is to when two values are equal, less execution once write memory instruction? 3. MARK Match's kernel implementation The implementation of the module in the kernel source of the xt_mark.c. The implementation code of its core matching module is as follows: Static int Match (const struct Sk_buff *skb, const struct Net_device *in, The const struct Net_device *out, The const struct Xt_match *match, const void *matchinfo, int offset, unsigned int protoff, int *hotdrop) 31 { The const struct Xt_mark_info *info = matchinfo; 33 Return ((Skb->nfmark & info->mask) = = Info->mark) ^ info->invert; 35} Copy Code This module implements a relatively simple function, which is to determine whether the Nfmark value of the packet is the same as the user specified. The time to judge is to consider the mask and to take the counter marker bit. The following iptables rule implements the accept action for all packets that are not labeled 0: Iptables-a postrouting-t mangle-m Mark! --mark 0-j ACCEPT Assuming that the Skb->nfmark is 1, the default value is 0xfffffffful,info->mark 0, because no mask is specified, and the counter marker bit is set, Info->invert is 1. Therefore, ((Skb->nfmark & info->mask) = = Info->mark) ^ Info->invert The result should be (1&0xfffffffful) = = 0) ^1 = 0^1 = 1. The return value of the match function for this module is 1, performing the Accept action. 4. Connmark Target's kernel implementation The implementation of the module in the kernel source of the xt_connmark.c. The implementation code of its core action module is as follows: static unsigned int Target (struct Sk_buff **pskb, Notoginseng const struct Net_device *in, The const struct Net_device *out, unsigned int hooknum, const struct Xt_target *target, The const void *targinfo, void *userinfo) 43 { The const struct Xt_connmark_target_info *markinfo = targinfo; u_int32_t diff; u_int32_t Nfmark; u_int32_t Newmark; u_int32_t Ctinfo; u_int32_t *ctmark = Nf_ct_get_mark (*PSKB, &ctinfo); 50 if (Ctmark) { Switch (markinfo->mode) { Case Xt_connmark_set: Newmark = (*ctmark & ~markinfo->mask) | markinfo->mark; if (Newmark!= *ctmark) *ctmark = Newmark; break; Case Xt_connmark_save: Newmark = (*ctmark & ~markinfo->mask) | ((*PSKB)->nfmark & Markinfo->mask); if (*ctmark!= Newmark) *ctmark = Newmark; a break; Case Xt_connmark_restore: Nfmark = (*PSKB)->nfmark; The diff = (*ctmark ^ nfmark) & markinfo->mask; if (diff!= 0) (*PSKB)->nfmark = Nfmark ^ diff; a break; 69} 70} 71 Xt_continue return; 73} Copying code The code first takes out the address of the mark value in the link trace of the packet: u_int32_t *ctmark = Nf_ct_get_mark (*PSKB, &ctinfo); Copy the code and then determine if Ctmark is null:51 if (ctmark) {Copying code if Ctmark = = NULL, there is no ct->mark this field in link tracking, the only possible reason is that the kernel configuration file does not have a config_nf The _conntrack_mark is configured without the ability to enable Conntrack mark. Otherwise, the corresponding implementation is based on the user's configured action. The following will be divided into three sections. (1) Mark the link Tracking set (--set-mark) The implementation code is as follows: Xt_connmark_set case: Newmark = (*ctmark & ~markinfo->mask) | markinfo->mark; if (Newmark!= *ctmark) *ctmark = Newmark; break; Copy code here first in accordance with all the bit in Markinfo->mask, the corresponding bit in the *ctmark to zero, and then markinfo->mark with the bitwise OR. This ensures that the bit bit in the mask is reset according to the value in Mark. The implementation of the 55~57 line code is the same as the implementation of the 67~68 code we analyzed in the 2nd part. (2) Save Tag value to link Tracking (--save-mark) The implementation code is as follows: Xt_connmark_save case: Newmark = (*ctmark & ~markinfo->mask) | ((*PSKB)->nfmark & Markinfo->mask); if (*ctmark!= Newmark) *ctmark = Newmark; a break; The code in this part of the copy code mask the same functionality as the above analysis. For simplicity analysis, we assume that the user did not specify mask, and the default value is 0xFFFFFFFFUL. In this way, the 59-line calculation is simplified to: Newmark = (*PSKB)->nfmark Plus the latter two lines of code: *ctmark!= Newmark *ctmark = Newmark; The specific functionality of the copy code is clear, and the Nfmark value of the current packet record is recorded in the Ct->mark in the link tracking. So, logically, if the process of the packet goes to this part of the code, it should be that the packet has been tagged, that is, the processing of--set-mark in Mark Target, which was analyzed earlier. Therefore, in the iptables of the rules, usually the--set-mark rules are in the front, and the--save-mark rules are followed. This ensures that the packet is labeled First, and then the tag on the packet is recorded on its corresponding link tracking. Here are a few example rules that follow this process: Iptables-a postrouting-m Mark--ma