一个奇葩的网络问题，把技术砖家“搞蒙了”

大家好，最近遇到一个奇葩的网络问题，分享给大家，看完一定会觉得很奇葩。

问题现象

客户反馈有一个服务器端S，两个客户端端C1，C2，S的iptables规则对C1，C2都是放通的，但是C2无法连接上S，客户很着急，催我们尽快解决。

这里解释一下，iptables规则是防火墙规则，是Linux系统实现防火墙一个应用层配置工具，依赖于Linux内核网络的netfiler框架。这里简单介绍一下问题的背景知识（后面网络硬核系列文章会详细介绍）。

背景知识

netfilter是Linux内核内部的一个框架，该框架允许内核模块在Linux网络中的不同位置注册的堆栈函数。然后对于遍历Linux网络内部相互链接的每个数据包，将调用已注册的一部分函数。

netfilter / iptables能做什么？

建立基于无状态和有状态数据包过滤的互联网防火墙
部署高可用性的无状态和有状态防火墙部署
如果您没有足够的公共IP地址，请使用NAT和伪装来共享Internet访问
使用NAT来实现透明代理
协助tc和iproute2系统用于内置复杂的QoS和策略路由器
进行进一步的数据包处理（处理），例如更改IP标头的TOS / DSCP / ECN位

在内核协议栈位置大概是这样：

netfilter XML的位置：

5个HOOK点：

PREROUTING ：数据包进入路由表之前

INPUT ：通过路由表后目的地为本机

FORWARD ：通过路由表后，目的地不为本机

输出：由本机产生，超出发送

POSTROUTIONG ：发送到网卡接口之前。

每个HOOK点都会执行一些函数，大致分为以下几个表：

NAT表：用于实现nat功能，端口映射，地址映射等

mangle表：用于修改报文，例如更改IP标头的TOS / DSCP / ECN位

filter表：用来过滤报文

raw表：用来预先标记报文不走一些流程（而不需要建会话）

如果不熟悉不要紧，只是知道在协议栈收发关键入口（进入，转发，发出）注册一些hook函数，然后报文会通过hook内部函数处理，而这些hook的动作（函数）是需要一个iptables的工具下发配置生成的。

iptables是您下发规则的用户状态工具。IP表中的每个规则都由多个分类器（iptables匹配项）和一个连接的动作（iptables目标）组成。命令格式可参考下图，详细可以参考手册：

这里记住两个动作就行了，ACCEPT表示通过，DROP表示丢掉；

内核里面看到的规则大概是这个样子：

主要特点

无状态数据包过滤（IPv4和IPv6）
有状态的数据包过滤（IPv4和IPv6）
各种网络地址和端口转换，例如NAT / NAPT（IPv4和IPv6）
灵活可扩展的基础架构
第三方扩展的API

所以大多数公司会基于netfilter框架实现软件防火墙（安全组）和软件虚拟交换机（vswitch，类似ovs）。

好，背景简单介绍完了，如果不是很理解，后面会详细介绍的，来看一下这个客户实际问题。

分析过程

1.先了解网络拓扑

客户网络拓扑是相当的简单，就是同网段下client机器访问服务器，一台可以访问，一台不可以。

2.查看配置是否丢失

对于服务端10.0.0.3而言，两台客户端机器到本机的iptable规则都是一样的。但10.0.2.8到10.0.0.3的20202端口的syn包被丢了，而10.0.2.7到10.0.0.3的20202范围的访问是正常的。

配置都在，需要进一步分析。

3.抓包分析

client端发起telnet命令连接服务器，服务器按client ip抓包，发现只有TCP SYN请求过来，根本回包，确实是本机OS内丢包导致无法正常连接：

通过netstat可以查看服务器TCP统计信息：连接数不高，没有TCP丢包统计信息，结合10.0.0.2.7客户端可以访问，进一步确认，放通安全组后，10.0.2.8到10.0.0.3的icmp包也没有回，这个时候和TCP协议处理没有本质关系了。

4.追踪内核丢包调用栈

报文如果被内核破坏后，正常情况下调用kfree_skb函数，内核通过kfree_skb释放skb，kfree_skb函数中已经埋下了跟踪点，并通过__builtin_return_address（0）记录下了调用kfree_skb的函数地址并传给给位置参数，可以通过systemtap脚本，追踪kfree_skb这个跟踪点，找到匹配的丢包并输出对应的变量：

/ **
* kfree_skb-释放一个sk_buff
* @skb：释放缓冲区
*
*删除对缓冲区的引用，并在使用计数
达到零时释放它。
* /
void  kfree_skb （ struct sk_buff * skb ）
{如果 （不太可能（！ skb ））返回; 如果 （可能（atomic_read （＆ SKB - >用户） ==  1 ））smp_rmb （）; 否则 ，如果 （可能（！atomic_dec_and_test （与SKB - >用户）））回报; trace_kfree_skb （ SKB ， __builtin_return_address （0 ））; __kfree_skb （ skb ）;
}
EXPORT_SYMBOL （ kfree_skb ）; / *
* Tracepoint免费提供一个sk_buff：
* /
TRACE_EVENT （ kfree_skb ，TP_PROTO （ struct sk_buff * skb ， void  * location ），TP_ARGS （skb ， location ），TP_STRUCT__entry （__field （        void  * ，          skbaddr          ）__field （        void  * ，          location         ）__field （         unsigned short ， protocol         ）），TP_fast_assign （__entry- > skbaddr = skb ;__entry- > location = location ;__entry- >协议=  ntohs （ skb- > protocol ）; ），TP_printk （“ skbaddr =％p协议=％u location =％p” ，__entry- > skbaddr ， __entry- >协议， __entry- > location ）
））;

systemtap脚本：

＃猫mydropwatch 。STP
＃/！ USR /斌/科技咨询-所有-模块
％{
＃包括< Linux的/内核。h >#include < linux / net 。h >#include < linux / textsearch 。h >#include < net /校验和。h >#include < linux /DMA -映射。h >#include < linux / netdev_features 。h >#include < linux / skbuff 。h >#include < uapi / linux / ip 。h >#include < uapi / linux / udp 。h >#include < uapi / linux / tcp 。h >
％}
################################################ ##########＃
dropwatch2 。STP
＃示例脚本来模仿行为的的dropwatch效用
＃报告每隔5秒与时间戳
＃使用： STAP -摹-所有-模块mydropwatch 。stp //-g表示大师模式
########################################## ##################
function get_packet_info ：字符串（ skb ： long ）
％{int ret =-1 ; unsigned int src_port =  0 ; unsigned int dest_port =  0 ; struct udphdr * udp_header ; struct tcphdr * tcp_header ; struct sk_buff * skb =  （ struct sk_buff * ） STAP_ARG_skb ; struct iphdr * ip_header ; 无符号整数src_ip = 0 ， dest_ip = 0 ; 如果（！ skb ）{转到EXIT_F ; }ip_header =  （ struct iphdr * ）skb_network_header （ skb ）; 如果（！ ip_header ）{转到EXIT_F ; }src_ip =  （ unsigned int ） ip_header- > saddr ; dest_ip =  （ unsigned int ） ip_header- > daddr ;
＃如果 0如果 （ IP_HEADER - >协议== 17 ） {udp_header =  （ struct udphdr * ）skb_transport_header （ skb ）; src_port =  （ unsigned int ）ntohs （ udp_header- > source ）; }  else  if  （ ip_header- > protocol ==  6 ） {tcp_header =  （ struct tcphdr * ）skb_transport_header （ skb ）;src_port =  （ unsigned int ）ntohs （ tcp_header- > source ）; dest_port =  （ unsigned int ）ntohs （ tcp_header- > dest ）; } printk （ KERN_INFO “输出数据包信息：src ip：％u，src端口：％u； dest ip：％u，dest端口：％u； proto：％u \ n” ， src_ip ， src_port ， dest_ip ， dest_port ， ip_header ->协议）;
＃万一// printk（KERN_DEBUG“ IP地址=％pI4 DEST =％pI4 \ n”，＆src_ip，＆dest_ip）;
EXIT_F ：snprintf （ STAP_RETVALUE ， MAXSTRINGLEN ， “％d。％d。％d。％d” ，（ unsigned int ）（（ unsigned char * ）＆ src_ip ）[ 0 ]，（ unsigned int ）（（ unsigned char * ）＆ src_ip ）[ 1 ]，（ unsigned int ）（（ unsigned char * ）＆ src_ip ）[ 2 ]，（ unsigned int ）（（unsigned char * ）＆ src_ip ）[ 3 ]）;
％}
＃保留放置点列表的数组，我们可以找到
全局位置
＃注意，当我们打开和关闭监视器时，
探针开始{  printf （“监视丢弃的数据包\ n” ） }
探针结束{  printf （“停止丢弃的数据包监视器\ n“ ） }
＃为在
探针内核处放置的每个位置增加一个放置计数器。跟踪（“ kfree_skb” ） {SrcIp = get_packet_info （ $ skb ）//if(SrcIp== "10.0.2.8") //数据包的src ip为“ 10.0.2.8” // printf（“ srcip：％s \ r \ n”，SrcIp）如果（ SrcIp == @ 1 ）{位置[ $ location ]  <<<  1  // systemtap统计聚合if（symname（$ location）==“ nf_hook_slow”）//如果nf_hook_slow函数print_backtrace（）调用了kfree_skb，则转储回溯。}
}
＃每隔5秒报告我们的墨滴位置
探测定时器。秒（5）
{
// printf（“ \ n ===％s === \ n”，ctime（gettimeofday_s（）））foreach  （ l在位置- ） { printf （“ \ n ===％s === \ n“ ， ctime （gettimeofday_s （）））printf （”％d个数据包在％x（％s）处丢弃\ n“ ，@ count （ location [ l ]）， l ， symname （ l ））}删除位置
}## ＃mydropwatch 。stp结束###

执行方法：

stap -g -v --all-modules mydropwatch.stp 10.0.2.8

执行命令后，对应输出：

从调用栈可知是在ip_local_deliver函数时因为iptables规则导致的丢包，结合内核代码：

nf_hook_slow + 0xf3对于代码188行（先找到对应内核版本的源代码，用崩溃工具打开对应内核版本的vmlinux，反汇编函数查看指令布局，定位到源代码行号）：

可知是在INPUT链丢的包，但是检查了mangle，nat，filter等表的INPUT链，可以其他拖放规则，更改策略可以接受，所以这里有点奇怪。

为了确定是否真的匹配上了ACCEPT规则，我在规则前面添加了打印日志规则，报文匹配后会打印日志出来：

显示确认一下：

通过触发请求，匹配上了第一个打印日志的规则，10.0.2.8白名单规则命中计数有添加，而第二日志规则没有匹配上，说明报文命中了白名单规则，报文可以通过防火墙：

但为什么服务端没有回syn + ack呢，是不是某种场景触发了netfiler框架的错误，假装接受，实际上把报文悄悄地给丢了？结合报文和系统环境，看了几遍netfiler代码后，没有抛光啥问题，清空iptables规则，停了firewalld，依然丢了，还是丢在nf_hook_ slow，也越来越证明不是普通iptables规则导致的。

如果要继续排查，是不是得遍历下内核数据结构，看看是不是列表坏掉了，由于时间比较紧迫，遍历内核数据结构有点麻烦，需要找到netfiler hook表起始地址，再结合数据结构算出偏偏移，一步一步遍历内存，由于可以通过器可以重启（业务已经不正常了），客户相信，重启可以比我们重新解决问题，还是重启大法好，但不幸的是，机器重启完后没有恢复，问题依然存在，这个就有意思了。

5.排查其他netfilter hook（钩子）函数

那么，有没有可能是有其他内核模块在INPUT链中注册了hook函数，drop了对应的包呢？

背景知识

crash是redhat的工程师开发的，主要用于离线分析Linux内核转存文件，它集成了gdb工具，功能非常强大。生成的转存文件格式，如kdump，LKCD，netdump和diskdump，而且还可以分析虚拟机Xen和Kvm上生成的内核转存文件。内核映象存放在/ proc / kcore。

5.1。从nf_hooks找到ipv4 INPUT链的挂钩

内核hook的组织：

那么对于NFPROTO_IPV4协议的NF_INET_LOCAL_IN链，我们可以找到其链表地址：

可以看到有一个非标模块resguard_linux日期了非标钩子函数net_hook_in_v4，反汇编net_hook_in_v4函数，可知其有一些白名单/黑名单之类的检查：

由此基本可以确定是这个模块的安全功能利用netfilter hook拦截了访问。

他大爷的，还真的注册了nf hook 。

但要客户认账，还得证明这个包就是这个hook函数丢的，其实已经差不多了。

5.2。如何证明是net_hook_in_v4返回NF_DROP（0x0）导致的丢包？

可以结合systemtap得到skb地址，然后通过perf probe抓取net_hook_in_v4和nf_iterate的返回值：

脚本：

运行结果：

由此可以抛光bb2100最后的这个skb是因为nf_hook_in_v4导致的丢包。

网上搜索可知该第三方安全模块疑似云锁类别软件提供，他可以通过ip黑白列表控制对网站的访问。

问题算术终于结束了，想着之前催得那么急，真想在线战斗一下，而客户是大爷，不敢想，不敢想。

可以学到什么

1.大致了解Linux防火墙实现框架：netfilter + iptables；

2.通过systemtap脚本追踪内核协议栈丢包特定信息；

3.如何通过尺寸函数和指令替换找到源代码信息；

4.一些丢包排查思路；

5.了解一些工具使用，有时会系统点击，崩溃，iptables，tcpdump等；