云LAN环境下Linux主机抓取到大量非本机转发流量的原因咨询

嘿，我之前在云LAN场景里碰到过类似的问题，咱们来梳理下你遇到的情况哈～

你在本地IP为172.16.0.11的Linux机器上执行了tcpdump -i eth0 -nne -p抓包，结果意外抓到了大量不属于本机的流量（源172.16.0.227、目的172.16.0.72），这种情况在云环境里通常有几个常见原因：

可能的原因分析 #

• 云虚拟网卡的特性限制：虽然你加了-p参数（禁用混杂模式），但很多云厂商的虚拟网卡底层架构并不会严格遵守这个参数，尤其是当你的实例和其他同子网实例部署在同一宿主机上时，虚拟交换机会把部分同子网的单播流量“镜像”到你的实例网卡上，这是云平台为了优化网络转发效率导致的。
• 流量镜像配置：你可以检查下云控制台有没有配置流量镜像规则——有没有把172.16.0.227或者整个子网的流量转发到172.16.0.11这台机器上？有时候团队里的运维同学可能会配置这类监控规则但没通知到你。
• 误开启IP转发：虽然从抓包看流量的源/目的都不是本机，但还是可以排查下本机是否开启了IP转发：执行cat /proc/sys/net/ipv4/ip_forward，如果返回值是1，说明本机开启了转发功能，可能会被当作子网内的转发节点（不过这种情况一般会有本机IP参与转发，可能性相对小）。
• 云平台的运维监控：部分云厂商会在后台临时镜像子网内的流量用于运维监控，这种情况通常是临时的，且不会持续太久，但也不排除例外。

你抓取到的流量记录 #

执行的抓包命令：
tcpdump -i eth0 -nne -p

抓取到的部分流量片段：

16:07:14.639206 fa:31:3f:2a:30:b7 > fa:31:3f:ba:7b:be, ethertype IPv4 (0x0800), length 1366: 172.16.0.227.9029 > 172.16.0.72.36726: Flags [P.], seq 2796:4096, ack 1, win 9677, options [nop,nop,TS val 483833918 ecr 1703882345], length 1300
16:07:14.639241 fa:31:3f:2a:30:b7 > fa:31:3f:ba:7b:be, ethertype IPv4 (0x0800), length 2862: 172.16.0.227.9029 > 172.16.0.72.36726: Flags [.], seq 4096:6892, ack 1, win 9677, options [nop,nop,TS val 483833918 ecr 1703882345], length 2796
16:07:14.639267 fa:31:3f:2a:30:b7 > fa:31:3f:ba:7b:be, ethertype IPv4 (0x0800), length 1366: 172.16.0.227.9029 > 172.16.0.72.36726: Flags [P.], seq 6892:8192, ack 1, win 9677, options [nop,nop,TS val 483833918 ecr 1703...

排查建议 #

• 先登录云控制台，检查是否存在针对该实例或子网的流量镜像配置；
• 执行cat /proc/sys/net/ipv4/ip_forward确认IP转发状态，如果是1且不需要转发，可以执行echo 0 > /proc/sys/net/ipv4/ip_forward临时关闭，再抓包测试；
• 尝试修改tcpdump命令，只抓取本机相关流量：tcpdump -i eth0 -nne -p host 172.16.0.11，确认是否还会收到非本机流量；
• 如果以上都排查不出问题，直接联系云厂商的技术支持，询问该子网的网络转发机制，他们能给出更精准的解释。

我当时碰到的类似情况是云厂商宿主机层面的虚拟交换机默认共享了同子网实例的部分流量，后来通过调整网卡的侦听策略解决的，你可以先按上面的步骤排查看看～

备注：内容来源于stack exchange，提问作者Yves