The iptables Manual cannot be used.

I am proud to find a secret to intercept data packets, that is, using the ctdir of conntrack. The first step is to read the man manual of iptables and find that:
-- Ctdir {Original | Reply}
Match packets that are flowing in the specified direction. If this flag is not specified at all, matches packets
In both directions ctions.
So I wrote down the following rules:

iptables -t mangle -A PREROUTING -d x.x.x.x/a -i eth2 -m conntrack --ctdir ORIGINAL -j MARK --set-xmark 100iptables -t mangle -A PREROUTING -s y.y.y.y/b -i eth2 -m conntrack --ctdir REPLY -j MARK --set-xmark 100

Is there any problem with writing this? Absolutely no! People who know iptables know what I want to do. What I want to do is intercept two types of streams, one is to actively access X. x. x. x/A streams, and Y. y. y. the stream accessed by Y/B. OK, everything looks good. However, when I deploy the above rules, a problem occurs. The interception is actually the opposite. That is to say, two types of streams are intercepted, one is X. x. x. x/A is the accessed stream, and the other is the active access to y. y. y. y/B stream... what should I do? For a long time, I always thought that I was wrong, Google, Baidu, and no result. As a mature iptables that has been used for so long, it will not make mistakes. It must be my mistake. So my next plan is to find out: What is wrong with me?
This is just a comfort. In fact, I know that I am not wrong. Simply put, reply represents the meaning of return. My actual plan should be to find evidence that I was not wrong. I have been searching for this evidence on the Internet for a long time, so I decided to check the code. First, I will see the general match function of conntrack. The kernel version is 2.6.32. Use the match function in/NET/Netfilter/xt_conntrack.c:

Static boolconntrack_mt (const struct sk_buff * SKB, const struct regular * par, 2010state_mask, 2010status_mask) {const struct regular * info = par-> matchinfo; Enum ip_conntrack_info ctinfo; const struct nf_conn * CT; unsigned int statebit; Ct = nf_ct_get (SKB, & ctinfo);/* These are not currently concerned, currently only focus on ctdir */... if (Info-> match_flags & xt_conntrack_direction) & (ctinfo2dir (ctinfo) = ip_ct _ Dir_original) ^ !! (Info-> invert_flags & xt_conntrack_direction) return false;/* none of these are currently followed. Currently, only ctdir */... return true ;}

For clearer thinking, the help functions/macros are also listed as follows:

enum ip_conntrack_dir{    IP_CT_DIR_ORIGINAL,    IP_CT_DIR_REPLY,    IP_CT_DIR_MAX};enum ip_conntrack_info{    /* Part of an established connection (either direction). */    IP_CT_ESTABLISHED,    /* Like NEW, but related to an existing connection, or ICMP error       (in either direction). */    IP_CT_RELATED,    /* Started a new connection to track (only           IP_CT_DIR_ORIGINAL); may be a retransmission. */    IP_CT_NEW,    /* >= this indicates reply direction */    IP_CT_IS_REPLY,    /* Number of distinct IP_CT types (no NEW in reply dirn). */    IP_CT_NUMBER = IP_CT_IS_REPLY * 2 - 1};#define CTINFO2DIR(ctinfo) ((ctinfo) >= IP_CT_IS_REPLY ? IP_CT_DIR_REPLY : IP_CT_DIR_ORIGINAL)static inline struct nf_conn *nf_ct_get(const struct sk_buff *skb, enum ip_conntrack_info *ctinfo){    *ctinfo = skb->nfctinfo;    return (struct nf_conn *)skb->nfct;}

Next, let's take a look at SKB-> where the nfctinfo is initialized. In fact, you don't need to find it and know it's in resolve_normal_ct in nf_conntrack_in:

If (nf_ct_direction (H) = ip_ct_dir_reply) {* ctinfo = ip_ct_established + ip_ct_is_reply;/* Please set reply bit if this packet OK */* set_reply = 1 ;} else {// as long as it is not the return direction, it is a forward packet. /* Once we 've had two way comms, always established. */If (test_bit (ips_seen_reply_bit, & CT-> Status) {* ctinfo = ip_ct_established;} else if (test_bit (ips_expected_bit, & CT-> Status )) {* ctinfo = ip_ct_related;} else {* ctinfo = ip_ct_new;} * set_reply = 0;} SKB-> nfct = & CT-> ct_general; SKB-> nfctinfo = * ctinfo;

It can be seen that the nfctinfo of the forward direction data packet is initialized to forward, ip_ct_related or ip_ct_new, and these are smaller than ip_ct_is_reply. Therefore, the ctinfo2dir of the forward direction data packet must be forward (see the ctinfo2 ). Another evidence is in the init_conntrack function, which is a function that initializes CT. In this case, CT is definitely considered to be in the positive direction, the function returns & CT-> tuplehash [ip_ct_dir_original], a CT-part in the direction of ip_ct_dir_original.
Now let's look at the conntrack_mt function. For a positive packet, (ctinfo2dir (ctinfo) = ip_ct_dir_original) is 1. If the ctdir of iptables is set to original, (Info-> invert_flags & xt_conntrack_direction) is 0 (see ip_conntrack_dir enumeration for details). Therefore, if the two values are different or 1, false is returned. Isn't this just a lie? For the returned packet, that is, the packet in the opposite direction, the return value is true... at least from the code point of view, ip_conntrack completely reversed the ctdir. Therefore, if you want your configuration to take effect based on your ideas, you need to configure it in turn:
Iptables-T mangle-A prerouting-D x. x/a-I eth2-M conntrack -- ctdir reply-J mark -- Set-xmark 100
Iptables-T mangle-A prerouting-s y. Y/B-I eth2-M conntrack -- ctdir original-J mark -- Set-xmark 100
Strange, but correct! To correct this problem, you only need to remove a "!" rule except for the odd configuration. No:

(CTINFO2DIR(ctinfo) == IP_CT_DIR_ORIGINAL) ^!!(info->invert_flags & XT_CONNTRACK_DIRECTION))

Changed:

(CTINFO2DIR(ctinfo) == IP_CT_DIR_ORIGINAL) ^!(info->invert_flags & XT_CONNTRACK_DIRECTION))

From "! (Info-> invert_flags & xt_conntrack_direction) "this line of code shows that there is a high possibility of incorrect writing. Otherwise, I cannot figure out why I should use double negative statements.

Angrily, how can such a problem be raised by few people? Is it true that it can be used? Or am I really wrong? Alas, in any case, I can use it if my configuration is reversed. If my configuration is correct, it will be wrong! After an afternoon, the real TM fuxx the conntrack, how can it be ignored? Who else can I trust in this mature iptables?