碰到这种跨主机、VM和路由器的连通性问题确实挺挠头的，我先结合你给出的信息梳理下核心现象，再聊聊可能的排查方向和解决思路。

核心现象复盘 #

先把关键信息捋清楚，方便定位问题：

• 拓扑：主机与路由器通过单物理链路连接，网桥br-client绑定VLAN接口wan0.202，VM通过vnet0接入网桥
• 连通性：VM ↔ 主机网桥 ✅；路由器 ↔ 主机网桥 ✅；VM ↔ 路由器 ❌
• ARP细节：ARP请求双向能正常接收，但路由器发给VM的ARP响应，主机网桥抓不到，且主机物理口wan0也看不到目的为VM MAC的VLAN帧（但路由器那边能确认已经发送）
• 环境：Ubuntu 16.04/18.04/20.04混合部署，部分是升级上来的系统，部分是全新安装的20.04；使用ifupdown而非netplan，通过virt-install创建VM

可能的原因分析与排查步骤 #

1. 主机物理口的VLAN处理/转发规则问题 #

你提到主机wan0抓不到VM MAC的VLAN帧，但路由器已经发出了，首先要确认主机这边的VLAN配置是否正确，有没有把wan0.202的流量正确转发到网桥：

• 检查主机的桥接转发配置：确认net.ipv4.ip_forward已开启，同时VLAN接口的流量没被iptables/nftables拦截

  sysctl net.ipv4.ip_forward
  iptables -L -n -v | grep -i br-client
  iptables -L -n -v | grep -i wan0.202
  

• 检查网桥的MAC学习表：看看网桥br-client有没有学习到VM的MAC地址，以及路由器的MAC地址

  bridge fdb show dev br-client
  

  如果网桥里没有VM的MAC条目，说明网桥没把VM的流量关联到vnet0；如果没有路由器的MAC，那大概率是wan0.202的转发环节出了问题。

2. libvirt的网桥转发配置问题 #

虽然你用的是自定义网桥（不是libvirt默认的virbr0），但libvirt可能会对vnet0接口设置额外规则：

• 检查libvirt的网络过滤规则：看看有没有限制VM和路由器之间的流量

  virsh net-list --all
  virsh net-dumpxml <你的网桥名称>  # 自定义网桥需对应查看配置
  

• 确认vnet0接口的转发规则：可以检查ebtables是否有拦截流量的规则

  ebtables -L -v
  

3. 内核版本/驱动兼容性问题 #

你提到全新安装的20.04更容易出问题，且不同内核版本（5.4.0-137 vs 5.4.0-146）表现不同，这很可能和内核的网桥/VLAN驱动有关：

• 尝试降级到能正常工作的内核版本（比如5.4.0-137），看看问题是否消失，验证是否是内核更新引入的bug
• 检查主机网卡驱动：确认wan0对应的网卡驱动是否为最新版本，有没有已知的VLAN/桥接兼容性问题

4. MAC地址相关的异常 #

你怀疑是MAC地址冲突，目前看VM的MAC（52:54:00:6c:23:ef）和主机网桥的MAC（48:21:0b:35:ae:51）没有重复，但可以进一步排查：

• 检查整个子网内的MAC地址是否重复：在路由器上查看ARP表，看看有没有多个IP对应同一个MAC，或者同一个MAC对应多个IP
• 尝试手动修改网桥MAC地址：有时候网桥会继承物理口的MAC，可能导致转发异常，手动设置一个独有的MAC试试

  ip link set dev br-client down
  ip link set dev br-client address 00:11:22:33:44:55  # 选择一个未使用的MAC地址
  ip link set dev br-client up
  

额外调试建议 #

在主机的br-client、wan0.202、vnet0三个接口同时抓包，对比流量走向，能更清晰看到ARP响应在哪个环节丢失：

# 在三个终端分别执行
tcpdump -i br-client -e arp and host 192.168.202.234  # VM的IP
tcpdump -i wan0.202 -e arp and host 192.168.202.234
tcpdump -i vnet0 -e arp and host 192.168.202.234

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