linux – 如何找出发送数据包(生成网络流量)的进程的PID？

发布时间：2020-12-14 02:34:01 所属栏目：Linux 来源：网络整理

导读：几个星期前,我遇到了一个问题,我在大约300个节点的大型网络中更改了DNS地址.之后,一些节点仍然继续询问旧的DNS服务器,虽然resolv.conf没问题,而host / nslookup正在查询新的DNS服务器. 看着tcpdump并试图用iptables日志记录来记录请求,我确认确实有些主机仍

几个星期前,我遇到了一个问题,我在大约300个节点的大型网络中更改了DNS地址.之后,一些节点仍然继续询问旧的DNS服务器,虽然resolv.conf没问题,而host / nslookup正在查询新的DNS服务器.

看着tcpdump并试图用iptables日志记录来记录请求,我确认确实有些主机仍在向旧的名称服务器发送查询.

我把其中一台主机停止生产,并开始关闭服务/支撑过程,试图找出罪魁祸首.

最后 – 它是lldpd守护进程,它显然在启动时缓存了名称服务器,甚至没有注意到resolv.conf中的更改.

所以,我的问题是 – 是否有更智能的方法来找出哪个PId产生特定类型的流量？我尝试过auditctl,但没有取得多大成功. CentOS 6有问题,但如果有任何Linux发行版的解决方案,我将不胜感激.

解决方法

几天前我和同样的问题搏斗,并提出了一个非常简单的方法.它基于以下事实：发送进程将等待DNS响应来自它发送请求的同一端口：

>使用iptables -j LOG找出传出DNS请求的源端口
>使用lsof -i UDP：< source_port>找出哪个进程正在等待该端口的响应.

当然,当响应在几毫秒内到达时,你不能手动完成;此外,即使在自动化时,也无法保证在DNS响应到来之前您能够查询系统,并且发送过程终止.这就是为什么在执行上述步骤之前,我还配置内核流量控制器来延迟指向特定ip /端口的传出数据包(使用tc模块netem).这允许我在步骤1中获得的源UDP端口上控制我必须查询系统关于哪个PID等待DNS响应的时间窗口.

我已经在一个名为ptrap的小脚本中自动执行了上述步骤,包括tc延迟(这是一种更通用的解决方案,不限于DNS请求,因此有资格使用任何基于TCP / UDP的协议检测进程).在我的帮助下,我发现,在我的情况下,联系旧DNS服务器的服务是sendmail.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!