關于Netfilter中連接跟蹤機制的方向問題 Original or Relay

luoyan_xy

內(nèi)核版本2.6.30
由于之前一直在2.4版本的內(nèi)核，現(xiàn)在剛剛改用2.6.30，其內(nèi)核一些數(shù)據(jù)結構和實現(xiàn)機制都發(fā)送了改變，因此變寫了幾個小程序去驗證性的跑一下，結果卻發(fā)現(xiàn)了這個另我費解的問題。。。
本意是在測試最新版本內(nèi)核中連接跟蹤模塊的使用情況，在新版本內(nèi)核中通過struct nf_conn代替之前的ip_conntrack結構，但其中主要的一個數(shù)據(jù)結構
struct nf_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX]并沒有太大改變。
好了，問題來了，按照道理說這個連接數(shù)組中        IP_CT_DIR_ORIGINAL代表的應該是原始方向的數(shù)據(jù)包，其源地址應該與ip頭部中的源地址是相同的，而IP_CT_DIR_REPLY代表回復方向的數(shù)據(jù)包，其目的地址才應該為本機地址。（這是我之前的理解）
但是在我寫的一個小測試用例中，得到的結果恰恰相反，ORIGINAL方向的連接的目的地址才是ip頭部中的源地址，RELAY方向連接的源地址才是ip頭部中的目的地址，很是困惑，想不明白，難道說是我之前對于連接跟蹤方向一直理解錯了嗎？。。。
現(xiàn)在貼一下我的代碼以及測試結果，有些長，各位看官不要嫌麻煩，因此這個問題真的很困擾我，急求給為牛人解惑，小弟不勝感激。。。。

1. #include  <linux/module.h>
   
2. #include  <linux/init.h>
   
3. #include  <linux/kernel.h>
   
4. 
   
5. #include  <linux/types.h>
   
6. #include  <linux/errno.h>
   
7. #include  <linux/sched.h>
   
8. #include  <linux/slab.h>
   
9. #include  <linux/fs.h>
   
10. #include  <linux/poll.h>
    
11. #include  <linux/spinlock.h>
    
12. #include        <linux/ioctl.h>
    
13. #include        <linux/proc_fs.h>
    
14. #include        <linux/list.h>
    
15. #include        <linux/param.h>
    
16. #include        <asm/uaccess.h>
    
17. #include        <asm/atomic.h>
    
18. 
    
19. 
    
20. #include        <linux/skbuff.h>
    
21. #include        <linux/in.h>
    
22. #include        <linux/ip.h>
    
23. #include        <linux/tcp.h>
    
24. #include        <linux/udp.h>
    
25. #include        <linux/icmp.h>
    
26. #include        <linux/netdevice.h>
    
27. #include        <linux/netfilter.h>
    
28. #include        <linux/netfilter_ipv4.h>
    
29. #include <linux/netfilter/nf_conntrack_tuple_common.h>
    
30. #include <net/netfilter/nf_conntrack.h>
    
31. 
    
32. #include        <linux/byteorder/generic.h>
    
33. #include        <linux/if_arp.h>
    
34. #include        <linux/if_ether.h>
    
35. #include        <linux/if_packet.h>
    
36. #include        <linux/delay.h>
    
37. 
    
38. #define HASH_SIZE 1024
    
39. 
    
40. static unsigned int       
    
41. conn_hook(unsigned int hook,
    
42.                            struct sk_buff *skb,
    
43.                            const struct net_device *indev,
    
44.                            const struct net_device *outdev,
    
45.                            int        (*okfn)(struct sk_buff *))
    
46. {
    
47.         struct nf_conn *conn;
    
48.         struct nf_conntrack_tuple_hash tuple_list;
    
49.         struct nf_conntrack_tuple orig_tuple;
    
50.         struct nf_conntrack_tuple relay_tuple;
    
51.         struct iphdr *iph;
    
52.         struct tcphdr *tcph;
    
53.         u32 ip_saddr;
    
54.         u32 ip_daddr;
    
55.        
    
56.         if(!skb)
    
57.                 {
    
58.                         return NF_ACCEPT;       
    
59.                 }
    
60.         printk("Hook functions\n");
    
61.         //獲取連接跟蹤數(shù)據(jù)結構
    
62.         conn = (struct nf_conn *)(skb->nfct);
    
63.         if(!conn)
    
64.                 {
    
65.                         printk("no nf_conntrack \n");
    
66.                         return NF_ACCEPT;       
    
67.                 }
    
68.                
    
69. #if 1
    
70.         iph = ip_hdr(skb);
    
71.         tcph = tcp_hdr(skb);
    
72.         printk("ipv4 src addr: %d.%d.%d.%d,dst addr:%d.%d.%d.%d\n", NIPQUAD(iph->saddr),NIPQUAD(iph->daddr));
    
73.         printk("ipv4 tcp src port %d, dst port %d\n",tcph->source,tcph->dest);
    
74.         tuple_list = conn->tuplehash[IP_CT_DIR_REPLY];
    
75.         orig_tuple = conn->tuplehash[IP_CT_DIR_ORIGINAL].tuple;
    
76.         relay_tuple = conn->tuplehash[IP_CT_DIR_REPLY].tuple;
    
77.         ip_saddr = orig_tuple.src.u3.ip;
    
78.         ip_daddr = orig_tuple.dst.u3.ip;
    
79.         printk("ipv4 original src addr: %d.%d.%d.%d,dst src addr: %d.%d.%d.%d\n", NIPQUAD(ip_saddr),NIPQUAD(ip_daddr));
    
80.         printk("src original port: %d,dst prot: %d\n",orig_tuple.src.u.tcp.port,orig_tuple.dst.u.tcp.port);       
    
81.         ip_saddr = relay_tuple.src.u3.ip;
    
82.         ip_daddr = relay_tuple.dst.u3.ip;
    
83.         printk("ipv4 relay src addr: %d.%d.%d.%d,dst src addr: %d.%d.%d.%d\n", NIPQUAD(ip_saddr),NIPQUAD(ip_daddr));
    
84.         printk("src relay port: %d,dst prot: %d\n",relay_tuple.src.u.tcp.port,relay_tuple.dst.u.tcp.port);
    
85. #endif
    
86. 
    
87.         return NF_ACCEPT;
    
88. }
    
89. 
    
90. static struct nf_hook_ops conn_hook_ops = {
    
91. .hook =       conn_hook,
    
92. .pf =         PF_INET,
    
93. .hooknum =    NF_INET_POST_ROUTING,
    
94. .priority =    NF_IP_PRI_LAST-1,
    
95. };
    
96. 
    
97. static int conn_init(void)
    
98. {
    
99.         int ret = 0;
    
100. //注冊鉤子
     
101.         ret = nf_register_hook(&conn_hook_ops);
     
102.         if (ret < 0)
     
103.         {
     
104.                 printk("register isatap hook ops error!\n");
     
105.         return -ENOMEM;
     
106.         }
     
107.     return 0;
     
108. }
     
109. 
     
110. static void conn_exit(void)
     
111. {
     
112.         nf_unregister_hook(&conn_hook_ops);       
     
113.         printk("Unregister conntrack hook ok\n");
     
114.         return;
     
115. }
     
116. 
     
117. module_init(conn_init);
     
118. module_exit(conn_exit);
     
119. 
     
120. MODULE_LICENSE("GPL");

復制代碼

然后使運行結果;

1. Hook functions
   
2. ipv4 src addr: 192.168.1.4,dst addr:192.168.1.221
   
3. ipv4 tcp src port 5632, dst port 2824
   
4. ipv4 original src addr: 192.168.1.221,dst src addr: 192.168.1.4
   
5. src original port: 2824,dst prot: 5632
   
6. ipv4 relay src addr: 192.168.1.4,dst src addr: 192.168.1.221
   
7. src relay port: 5632,dst prot: 2824
   
8. Hook functions
   
9. ipv4 src addr: 192.168.1.4,dst addr:192.168.1.221
   
10. ipv4 tcp src port 5632, dst port 2824
    
11. ipv4 original src addr: 192.168.1.221,dst src addr: 192.168.1.4
    
12. src original port: 2824,dst prot: 5632
    
13. ipv4 relay src addr: 192.168.1.4,dst src addr: 192.168.1.221
    
14. src relay port: 5632,dst prot: 2824
    
15. Hook functions
    
16. ipv4 src addr: 192.168.1.4,dst addr:192.168.1.221
    
17. ipv4 tcp src port 5632, dst port 2824
    
18. ipv4 original src addr: 192.168.1.221,dst src addr: 192.168.1.4
    
19. src original port: 2824,dst prot: 5632
    
20. ipv4 relay src addr: 192.168.1.4,dst src addr: 192.168.1.221
    
21. src relay port: 5632,dst prot: 2824
    
22. Hook functions
    
23. ipv4 src addr: 192.168.1.4,dst addr:192.168.1.221
    
24. ipv4 tcp src port 5632, dst port 10760
    
25. ipv4 original src addr: 192.168.1.221,dst src addr: 192.168.1.4
    
26. src original port: 10760,dst prot: 5632
    
27. ipv4 relay src addr: 192.168.1.4,dst src addr: 192.168.1.221
    
28. src relay port: 5632,dst prot: 10760

復制代碼

從這個結果來看，ip首部的源地址和目的地址對應的是relay方向的連接包，通過tcp頭部的端口號也證明了這一點。。。
而且我剛剛看了下ipv4_pkt_to_tuple，它所做的工作的確是從ip首部自動的源地址開始，讀取兩個32字節(jié)的變量，分別賦給tuple中的源地址和目的地址，按照道理說應該不會出錯啊，可是我怎么得出了這么個結果。。。

這個真的很困惑，本人也是剛開始學Netfilter不久，還請各位高手幫忙解答。。。

luoyan_xy

貌似我忘記考慮端口的網(wǎng)絡字節(jié)序的問題了。。。。
各位請直接跳過這個問題

luoyan_xy

操作系統(tǒng)Centos，實驗平臺虛擬機，應該沒有需要補充的了。。。

luoyan_xy

沒人能幫忙看一下嗎。。。
哎。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

Godbach

# static struct nf_hook_ops conn_hook_ops = {
# .hook =       conn_hook,
# .pf =         PF_INET,
# .hooknum =    NF_INET_POST_ROUTING,
# .priority =    NF_IP_PRI_LAST-1,
# };

本身數(shù)據(jù)包又流入和流出兩個方向，都會通過連接跟蹤的。
你看一下你的 hook 函數(shù)注冊的位置，如果是終端主機的話，只有哪個方向的包才會進入你的 hook 函數(shù)

luoyan_xy

回復 5# Godbach


    注冊點在 POST_ROUTING,測試機是終端主機，按照道理在LOCAL_OUT的時候會對本機發(fā)出的數(shù)據(jù)包建立連接跟蹤，在POST_ROUTING中掛入連接跟蹤隊列中

    目的是為了測試本機發(fā)出的數(shù)據(jù)包，在POST_ROUTING也不能捕獲到達本機的數(shù)據(jù)包吧，測試中那個192.168.1.4是運行程序的主機ip地址，192.168.1.221為發(fā)出數(shù)據(jù)包的目的地址

Godbach

首先要明確你這個連接主動發(fā)起方是哪個 IP。
可以做個測試，用另一臺主機向你當前主機發(fā)起 SYN 請求，或者等連接完全建立之后也行，你在 LOCALIN 出截獲它的數(shù)據(jù)包，并查看連接的 ORG 方向的源 IP.

奇門遁甲-lu

很明顯你的數(shù)據(jù)是由
192.168.1.221開始發(fā)出的。
數(shù)據(jù)通過連接跟蹤，如果還沒建立連接跟蹤的，就建立一個連接跟蹤
你的掛鉤放在NF_INET_POST_ROUTING。

實際上是192.168.1.4應答的時候捕捉到的數(shù)據(jù)。

所以
ipv4 original src addr: 192.168.1.221,dst src addr: 192.168.1.4
一點沒錯，
IP_CT_DIR_ORIGINAL記錄的是數(shù)據(jù)最開始時的方向,

另外應該判斷一下傳輸協(xié)層議協(xié)議是不是tcp.