一次UDP奇葩问题排查

一 背景

昨天，接同事电话，说帮忙协查一个UDP抓不到包的问题，他描述的问题是A主机通过UDP协议向B主机的10001端口发送syslog报文，结果我们的采集程序flume收不到数据；但是C主机向B主机的10002端口也同样发送syslog报文，同一个flume采集程序却可以正常收到报文。

B主机双网卡分别为：42这个ip，网口是eth0；72这个ip，网口是eth1。

B对外网用的IP是一个134网段的IP。

A主机和C主机均使用134这个网段的IP向B主机发送报文。

示意图如下：

二 分析

2.1 排查防火墙问题

我第一个反应是不是防火墙的问题。登录到主机后，因为是centos7的版本，所以通过防火墙状态查看命令，查看防火墙已经关闭。

2.2 抓包检测中间网络

继续分析，接着考虑是不是防火墙的问题，所以在接收主机B主机上用tcpdump进行抓包，命令如下：

发现报文没问题，接着加上-vv选项，可以看到解析出来的信息，也正是我们要发送的报文，说明中间网络是没问题的。

2.3 用nc测试

nc可以说是网络测试的神器，可以方面的建立监听端口，做服务器；可以做客户端测试服务器。

具体测试步骤如下：

1 把B上的flume监听程序停止，然后在B主机上 运行一下命令：

结果：收不到任何消息！！！有点吃惊，都可以抓到包了，防火墙也是关闭的为什么收不到那。

不服气，继续用nc，在B主机随便启动一个10009端口：

在A服务器上 通过nc命令连接测试：

输入报文进行测试，仍然收不到报文。

2 看下系统日志，发现没有报错。

进入深深的思考中…

三 再战

说什么，咱们也不能认怂啊，打电话问了下大师，大师说重启下防火墙吧。

所以第二天一大早联系上同事，继续重启防火墙，发现故障依旧。

接着看下flume启动的监听端口情况：

监听的ip配置为0.0.0.0 ，端口绑定的是10001 ，没问题。

虽然B主机有两块网卡，两个IP，但是我们监听了所有IP啊，谨慎一点，还是把IP配置成抓包抓到的42这个IP，结果故障依旧。

继续在B主机上抓包，发现A主机过来的IP是10网段，C主机过来的IP是134网段，那说明源IP网段不一样，会不会因为网段问题造成的这个问题。

鬼使神差地，用 看了下路由信息，发现：

10网段的目标IP，用的是eth1 这个网口，但是这个eth1的网口配置的ip是72 ip和A向B发送的目标IP不同，A向B发送的目标Ip为34这个ip。

下面把UDP包的流转过程梳理下：

从B主机（IP:10.x.x.x）向A主机的134.x.x.x 发送UDP报文，UDP报文经过中间的NAT转换后目标IP变成了x.x.x.42 通过网口eth0进入到B主机。

B主机访问10.x.x.x 时候，按照现有的route配置，是通过eth1 网口出去的，如果要是有回包的话，那么接收包的网口eth0和回包的网口eth1 不是同一个网卡！

总觉得不太对，我手工删除老的10.x.x.x 路由，并且添加了下新的路由，新路由走eth0，命令如下：

接着再次测试nc收包情况，却可以收到了，flume也同样可以收到了，至此问题解决。

但是有点想不通，按道理udp报文是不会受到路由影响的，有大神知道的，请告知。