目录
VMware OpenWrt 因路由器损坏导致网络异常的排查与解决
背景
之前在 VMware 中搭建了一套 OpenWrt 环境，宿主机通过有线网卡连接路由器（IP：192.168.1.5，网关：192.168.1.1），VMware 网络适配器设为桥接模式，桥接到宿主机的有线网卡。OpenWrt 的 LAN 口配置为同网段静态 IP 192.168.1.100，一切正常运行。
后来路由器损坏，电脑改为 WiFi 无线网卡上网，随后发现 OpenWrt 网络完全异常——宿主机与 OpenWrt 互相 ping 不通，SSH 也无法连接，甚至 OpenWrt 启动页面的绿色网络状态 banner 也不显示了。
问题排查过程
第一轮：检查常见配置问题
| 排查项 | 结果 | 结论 |
|---|---|---|
| VMware 网络适配器模式 | 已设为桥接模式 | 不是 NAT 问题 |
OpenWrt /etc/config/network 配置 |
br-lan 绑定了 eth0，IP 和子网掩码正确 |
配置本身没问题 |
ip addr 查看 IP 是否生效 |
br-lan 已拿到 192.168.1.100/24 |
IP 已生效 |
| 路由表 | 默认网关 192.168.1.1，路由正确 |
路由没问题 |
| WAN 口配置 | 不存在 WAN 配置 | 不会阻塞启动 |
| ARP 表 | 宿主机和网关的 MAC 均为 00:00:00:00:00:00，Flags 为 0x0 |
二层完全不通 |
第二轮：深入排查二层连通性
- OpenWrt 侧
ping 192.168.1.5（宿主机）→ 100% 丢包 - OpenWrt 侧
ping 192.168.1.1（网关）→ 100% 丢包 - ARP 表显示无法学到任何设备的 MAC 地址
结论：数据帧根本没从虚拟机发出到物理网络。
第三轮：定位根本原因
检查 VMware 虚拟网络编辑器中桥接到的目标网卡——发现桥接的是 Realtek Gaming 2.5GbE Family Controller（有线网卡）。
此时执行 ipconfig，发现宿主机 192.168.1.5 实际走的是 WLAN（无线网卡），有线网卡的状态是 "媒体已断开连接"。
根本原因找到了：
路由器损坏后，电脑改用 WiFi 上网，有线网卡处于未插线状态。VMware 桥接仍然指向那张没有连接的有线网卡，虚拟机的数据包通过桥接驱动发到一张物理上断开的网卡上，自然无法进入物理网络。这就是为什么配置全对、但二层始终不通的原因。
那么问题来了：为什么不能直接把桥接目标改为无线网卡？
WiFi 网卡桥接在 VMware 中存在天然的局限性：
- 部分无线网卡驱动不支持桥接所需的混杂模式
- WPA2/WPA3 加密下桥接成功率更低
- 路由器开启 AP 隔离也会阻止设备互通
所以即使桥接目标选对了，走 WiFi 网卡也不能保证一定通。
最终方案：NAT + 仅主机 双网卡
既然无法依赖有线网卡桥接，也不能保证 WiFi 桥接正常工作，采用了一个更可靠的替代方案：
| 网卡 | 模式 | 网段 | 用途 |
|---|---|---|---|
| 网卡 1（原有 eth0） | NAT | DHCP 自动获取 | 让 OpenWrt 通过宿主机 WiFi 访问外网 |
| 网卡 2（新增 eth1） | 仅主机 | 192.168.47.0/24（VMnet1） |
宿主机与 OpenWrt 之间互通 |
操作步骤
1. VMware 设置
- 关闭 OpenWrt 虚拟机
- 右键 VM → 设置 → 将现有网络适配器改为 NAT 模式
- 点击 添加 → 网络适配器 → 设为 仅主机模式
- 启动虚拟机
2. 检测新网卡
ls /sys/class/net/输出中出现新增的 eth1，即为仅主机网卡。
3. 配置 /etc/config/network
新增 hostonly 接口：
cat >> /etc/config/network << 'EOF'
config interface 'hostonly'
option device 'eth1'
option proto 'static'
option ipaddr '192.168.47.100'
option netmask '255.255.255.0'
EOF重新加载网络：
/etc/init.d/network reload验证 IP 生效：
ip addr show eth1输出 inet 192.168.47.100/24，配置成功。
4. 测试连通性
从宿主机 PowerShell：
ssh root@192.168.47.100返回 Connection refused——这表明网络层已通，只是服务端拒绝了连接。
额外修复：dropbear SSH 监听范围问题
Connection refused 而非超时，说明数据包已到达 OpenWrt。排查 SSH 服务状态：
netstat -tlnp | grep 22输出：
tcp 0 0 192.168.1.100:22 0.0.0.0:* LISTEN 4457/dropbear问题： dropbear 只监听了旧的 192.168.1.100，不接受来自 192.168.47.100（新网卡）的连接。
修复：让 dropbear 监听所有网络接口。
uci set dropbear.@dropbear[0].Interface=''
uci commit dropbear
/etc/init.d/dropbear restart再次 SSH：
ssh root@192.168.47.100成功连接。
总结
| 问题 | 原因 | 解决 |
|---|---|---|
| 宿主机与 VM 互 ping 不通 | 桥接目标为已断开的有线网卡 | 改为 NAT + 仅主机双网卡 |
| SSH Connection refused | dropbear 只监听旧 IP | 清空 Interface 绑定，监听所有接口 |
核心教训：VMware 桥接模式依赖的物理网卡必须处于活动连接状态。 当上网方式从有线切换到无线时（例如路由器损坏），原来绑定的有线网卡就失效了。双网卡方案（NAT + 仅主机）是 WiFi 场景下最稳定可靠的替代方案——NAT 保证 VM 能上网，仅主机保证宿主机与 VM 始终互通，不再受物理网络变化的影响。
0 条评论