iperf3互通但接入点侧PC无法ping通接收机侧PC的故障原因问询

先帮你梳理下当前的网络场景和核心现象，方便定位问题：

• 拓扑：PC1（10.23.200.10）连AP（10.23.200.20），PC2（10.23.200.40）连接收机（10.23.200.30），同时AP和接收机直连
• 环境：两台PC都关闭了防火墙、安全软件和杀毒软件
• 关键现象：
  1. 两台PC能通过iperf3正常互发互收流量
  2. PC2可以ping通PC1
  3. PC1能ping通接收机，但死活ping不通PC2

可能的原因分析 #

结合现象来看，TCP流量能双向走通但ICMP（ping用的协议）走不通，大概率是中间设备（也就是接收机）的配置问题，下面是几个最可能的方向：

1. 接收机的IP转发功能正常，但ICMP转发被限制

iperf3默认用的是TCP协议（端口5201），而ping用的是ICMP协议。很多嵌入式网络设备（比如你用的这个接收机）会默认允许TCP/UDP流量转发，但对ICMP包做了特殊限制——比如只允许本机接收ICMP（所以PC1能ping通接收机本身），但不把ICMP包转发给下一跳的PC2。这种情况下TCP流量不受影响，但ping就会失败。

2. 接收机的单向转发规则

有些设备可能会配置单向的流量转发策略：比如允许从PC2所在的端口（接收机连PC2的口）转发流量到AP侧，但反过来禁止从AP侧过来的流量转发到PC2口。不过这里有个矛盾点：iperf3能双向互通，说明TCP的反向流量是能过的，所以这个可能性相对低，但也可以排查下有没有类似的规则。

3. ARP代理或二层转发的异常

虽然所有设备都在同一个网段（10.23.200.x），但PC1和PC2不在同一个二层广播域，必须通过三层设备（AP或接收机）做ARP代理才能互通。如果接收机的ARP代理功能没有开启，或者ARP表中没有PC2的条目，可能会导致PC1发的ping包到了接收机后，无法正确转发给PC2。不过iperf3能正常工作，说明TCP连接的ARP解析是正常的，这个可能性也偏低，但可以作为排查的补充项。

排查建议 #

给你几个实操的排查步骤，按优先级来：

• 先查接收机的ICMP过滤规则：如果是Linux系统的接收机，执行iptables -L看看有没有拦截ICMP的规则；如果是嵌入式设备，进管理界面找“防火墙”或“流量过滤”选项，临时关闭所有ICMP相关的限制试试。
• 确认接收机的IP转发状态：Linux系统执行cat /proc/sys/net/ipv4/ip_forward，如果输出是0说明转发没开，临时执行echo 1 > /proc/sys/net/ipv4/ip_forward开启后再测试；嵌入式设备找“IP转发”或“路由转发”的开关打开。
• 抓包验证：在接收机的两个接口（连AP的口和连PC2的口）分别抓包，看PC1发的ping请求有没有到达接收机，有没有被转发给PC2；同时看PC2的ping回复有没有回到接收机，有没有被转发给AP。这是最直接定位问题的方法。

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