conntrack记录查询的疑问

nu_teller

实例：
tftp client -> tftp server:
ORIGINAL          192.168.1.1:1106   -> 192.168.1.2:69
REPLY                 192.168.1.2:69      -> 192.168.1.1:1106
tftp server -> tftp client:
ORIGINAL          192.168.1.2:69      -> 192.168.1.1:1106
[fly]REPLY                 192.168.1.1:1106   -> 192.168.1.2:69[/fly]
在conntrack条目中只有一条记录
疑问在于：
最主要的是为什么tftp server的回应报文能够在nf_conntrack_hash[hash]表表中查到？
当tftp server回应的tuple的流程如下，
conntrack_in->resolve_normal_ct->nf_conntrack_find_get->__nf_conntrack_find
在nf_conntrack_hash[hash]表中查找是否存在对应的tuple，
不明白的地方是nf_conntrack_hash表有没有ORIGINAL和REPLY的分类，
nf_confirm中的查找orignal和reply tuple中的方法不同的原因？

__nf_conntrack_confirm(struct sk_buff **pskb)
{
        unsigned int hash, repl_hash;
   
        ...

        hash = hash_conntrack(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
        repl_hash = hash_conntrack(&ct->tuplehash[IP_CT_DIR_REPLY].tuple);

        ...

        /* See if there's one in the list already, including reverse:
           NAT could have grabbed it without realizing, since we're
           not in the hash.  If there is, we lost race. */
        list_for_each_entry(h, &nf_conntrack_hash[hash], list)
                if (nf_ct_tuple_equal(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple,
                                      &h->tuple))
                        goto out;
        list_for_each_entry(h, &nf_conntrack_hash[repl_hash], list)
                if (nf_ct_tuple_equal(&ct->tuplehash[IP_CT_DIR_REPLY].tuple,
                                      &h->tuple))
                        goto out;
        ...      
}

nu_teller

自己先顶下，期待大侠解答

Godbach

回复 2# nu_teller
你说的 tftp 估计是 conntrack 中用到 helper 的情形了吧

瀚海书香

回复 1# nu_teller
netfilter中经典的多连接协议匹配。也就是helper的应用。
向ftp,tftp,h.323等协议，因为同一个协议可能是多个通道。比如ftp的命令和数据通道。但是根据命令通道可以计算出对应的数据通道，内核就会将相应的数据通道和命令通道统一划归为ftp链接。

nu_teller

回复 3# Godbach
不好意思，我的叙述太繁琐了，导致兄台误以为是tftp中的控制链接和数据连接的两条conntrack记录
我的本意是：
【问题1】
pc 1 -------->    pc 2   发出请求[Original]，
pc 2 --------->   pc 1   发出回应[Reply]，为什么是一条conntrack记录？
从代码的角度看：
pc2 -----> pc 1 的Reply 报文的tuple，是在nf_conntrack_in->resolve_normal_ct->nf_conntrack_find_get
中遍历 nf_conntrack_hash[hash],
请问nf_conntrack_hash[hash]是否将一条conntrack记录中的original和reply这两个tuple全部记录在内？

【问题2】同时，在__nf_conntrack_confirm这个函数中，在确定一条连接是否存在的时候，
Original会遍历nf_conntrack_hash[hash],
Reply 会遍历 nf_conntrack_hash[repl_hash]，
这两张hash值定义如下：
hash = hash_conntrack(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
repl_hash = hash_conntrack(&ct->tuplehash[IP_CT_DIR_REPLY].tuple);
那么这两张hash表和问题1的hash表有和异同呢？

nu_teller

回复 4# 瀚海书香


    你好，场景如下：      
                                          WAN侧       |   LAN侧
   10.10.10.2                10.10.10.3        |   192.168.1.1                192.168.1.3
tftp server <---------------> router (具备nat功能)   <-------------->  tftp client
                                                          |
                                                          |

此时只有一条Original  dport 69 的conntrack记录，
并没有tcp/ip 卷一种所说的 数据连接 的出现？

Godbach

回复 5# nu_teller

【问题1】
pc 1 -------->    pc 2   发出请求[Original]，
pc 2 --------->   pc 1   发出回应[Reply]，为什么是一条conntrack记录？
从代码的角度看：
pc2 -----> pc 1 的Reply 报文的tuple，是在nf_conntrack_in->resolve_normal_ct->nf_conntrack_find_get
中遍历 nf_conntrack_hash[hash],
请问nf_conntrack_hash[hash]是否将一条conntrack记录中的original和reply这两个tuple全部记录在内？

   
你这么问还是对 conntrack 不了解啊。conntrack 是会将属于同一个连接的双向都记录下来的，也就是将 orginal 和 reply 做一下关联的。

高版本的内核你可以通过  cat /proc/net/nf_conntrack 查看内核是怎么记录的，我随便贴两条给你

ipv4     2 udp      17 8 src=192.168.100.121 dst=202.108.251.50 sport=10752 dport=53 packets=1 bytes=63 src=202.108.251.50 dst=192.168.100.121 sport=53 dport=10752 packets=1 bytes=249 mark=0 secmark=0 use=1
ipv4     2 tcp      6 86 TIME_WAIT src=192.168.2.49 dst=192.168.100.121 sport=65005 dport=21900 packets=10 bytes=863 src=192.168.100.121 dst=192.168.2.49 sport=21900 dport=65005 packets=9 bytes=16439 [ASSURED] mark=0 secmark=0 use=1

nu_teller

回复 7# Godbach

我想知道为什么reply报文能在nf_conntrack_hash[hash]中查到啊？

whaaat

因为在发出请求[Original]建立连接的时候就会记录这个连接reply的tuple，reply报文到来会按照original和reply两个方向去链接表里查询，就会命中该链接。

Godbach

回复 8# nu_teller

内部实现时做了关联的