📝 故障记录：QEMU TAP 网络双向 Ping 不通排查与解决

1. 故障现象 (Symptoms)

• Guest 侧 IP： 192.168.1.1/24 (eth_base)
• Host 侧 IP： 192.168.1.2/24 (tap0)
• 现象： 双方网卡状态均 UP，且处于同一子网，但互相 Ping 不通。

2. 排查过程与根本原因 (Troubleshooting & Root Cause)

• 第一步：验证 L2 链路 (ARP 检测)。 在两端互 Ping 后执行 arp -a。结果显示双方都能正确解析出对方的 MAC 地址。
  • 结论： QEMU 启动参数无误，虚拟“网线”已正确连接，L2 数据链路层完全畅通。
• 第二步：排查 L3 路由。 检查 Host 侧的 ARP 与路由表（ip route | grep 192.168.1.0），发现 192.168.1.0/24 网段除了 tap0，还被另一个网桥接口（br0，IP 为 192.168.1.100）占用。
  • 结论： 典型的系统路由表冲突（Subnet Collision）。Linux 内核将发往 192.168.1.x 的流量错误地路由给了 br0（或僵尸 Docker 网桥），导致流量被劫持，根本没有进入 tap0。

3. 最终解决步骤 (Resolution Steps)
核心思路： 将产生冲突的网桥（br0）迁移到其他网段，确保 tap0 独占 192.168.1.x 网段的路由。

在 Host 机依次执行以下命令：

# 1. 剥离冲突网桥 (br0) 上的旧 IP，释放 192.168.1.x 网段
sudo ip addr del 192.168.1.100/24 dev br0

# 2. 将冲突网桥迁移到一个全新的、无冲突的网段 (例如 200 网段)
sudo ip addr add 192.168.200.100/24 dev br0

# 3. 验证路由表，确保 192.168.1.0/24 只有 tap0 一条记录
ip route | grep 192.168.1.0
# 正确输出应仅包含类似: 192.168.1.0/24 dev tap0 proto kernel scope link src 192.168.1.2

4. 虚拟网络排错“黄金三板斧” (Cheat Sheet)
以后遇到类似情况，按此顺序排查：

1. 一查底层链路： 互相 ping 之后看 arp -a。有 MAC 证明线通了，没 MAC 去查 QEMU/Docker 启动配置。
2. 二查路由冲突： ip route 查看目标网段。Linux 下多网卡同网段是万恶之源，必须确保网段唯一。
3. 三查防火墙： iptables -nvL。能 ARP 解析但不能 Ping，且路由没冲突的，100% 是被 INPUT 或 FORWARD 链 DROP 掉了。