conntrack+icmp:发现一个奇怪的现象

qtdszws

NAT服务器上想跟踪icmp的连接
ping x.x.x.x//从内网ping本地外网服务器

grep ^icmp /proc/net/ip_conntrack总是没有连接记录
grep conn /proc/slabinfo也不见对象数量有任何改变

开始怀疑是没有生成连接，但是在NAT上是不可能,排除
ping www.sohu.com却能看到记录，不过不是每次都能
经过一番折腾，查看代码后才知原因所在
static int icmp_packet(struct ip_conntrack *ct,
                       struct iphdr *iph, size_t len,
                       enum ip_conntrack_info ctinfo)
{
/* FIXME: Should keep count of orig - reply packets: if == 0,
           destroy --RR */
/* Delete connection immediately on reply: won't actually
           vanish as we still have skb */

if (CTINFO2DIR(ctinfo) == IP_CT_DIR_REPLY) {
//icmp ping包的连接立即会消失,如果echo reply延迟很小的话
//因此利用grep ^icmp /proc/net/ip_conntrack和grep conn /proc/slabinfo通常跟踪不到
if (del_timer(&ct->timeout))
ct->timeout.function((unsigned long)ct);
} else
ip_ct_refresh(ct, ICMP_TIMEOUT);
return NF_ACCEPT;
}

只有ping -f x.x.x.x可增加跟踪到的概率，或ping 不存在的地址也能看到

个人觉得在收到echo reply后应该能够延迟几秒钟再回收连接记录，否则
flooding ping导致的开销不小

qtdszws

NAT服务器在用tcpdump抓icmp包的时候
tcpdump -i eth0 -nnn icmp//eth0为外网

11:20:27.694467 x.x.x.x > y.y.y.y: icmp: echo request
11:20:27.694467 y.y.y.y > 10.1.9.8: icmp: echo reply

reply包尽然是内网地址。

分析后发现:
1.该包显然是经过conntrack和NAT处理后包
2.tcpdump是采用af_packet协议抓包的,命令行已经隐含指出协议类型为ip协议。因此packet_create时直接dev_add_pack到ip包。而不是通常的ETH_P_ALL
3.因此net_rx_action中reply包先由ip_rcv处理，经过PREROUTING后包已被改写(do_bindings)，因此再传给packet_rcv时目的地址已经成为内网地址了