前言
在使用 VMware Workstation 搭建 Ubuntu / ROS 开发环境时，虚拟机网络通常会选择 NAT 或 桥接（Bridged） 模式。
NAT 模式配置简单，但虚拟机与宿主机不在同一局域网网段。对于 ROS 多机通信、树莓派、机器人、嵌入式设备联调等场景，桥接模式往往更加方便，因为虚拟机会像一台真实设备一样直接接入物理局域网。
本文记录一次实际遇到的问题：
VMware 虚拟机使用 NAT 模式可以正常联网，但切换到桥接模式后无法获取 IP 地址，
dhclient不断发送DHCPDISCOVER，却始终收不到DHCPOFFER。
最终通过抓包、静态 IP、ARP、路由和 DNS 测试定位到：VMware 桥接链路实际上是通的，真正异常的是 DHCP 自动地址分配。
最终采用固定静态 IP 的方式解决问题，并实现虚拟机桥接联网。
一、实验环境
Windows 宿主机
系统：
text
Windows 11无线网卡：
text
Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network AdapterWindows WLAN 地址：
text
IPv4：192.168.0.101
掩码：255.255.255.0
网关：192.168.0.1VMware
使用 VMware Workstation，虚拟机网络配置为：
text
VMnet0
网络类型：桥接模式
桥接至：Killer(R) Wi-Fi 6 AX1650iUbuntu 虚拟机
虚拟网卡：
text
ens33MAC 地址：
text
00:0c:29:35:55:3bUbuntu 使用 Netplan + NetworkManager 管理网络。
Netplan 配置文件：
bash
/etc/netplan/01-network-manager-all.yaml二、最初的问题
虚拟机切换到桥接模式以后：
bash
ping baidu.com出现：
text
ping: baidu.com: Temporary failure in name resolution最开始使用：
bash
ifconfig甚至只能看到：
text
docker0
lo于是首先检查网卡：
bash
ip -br link结果：
text
lo UNKNOWN
ens33 DOWN
docker0 DOWN说明 VMware 虚拟网卡其实已经被 Ubuntu 正确识别，只是接口处于 DOWN 状态。
手动启动：
bash
sudo ip link set ens33 up再次查看：
bash
ip -br link变成：
text
ens33 UP说明：
VMware 虚拟网卡、Ubuntu 驱动以及虚拟链路本身都没有问题。
三、DHCP 无法获取 IP
接下来尝试：
bash
sudo dhclient -v ens33结果不断出现：
text
DHCPDISCOVER on ens33 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on ens33 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on ens33 to 255.255.255.255 port 67 interval 7但是始终没有：
text
DHCPOFFER
DHCPREQUEST
DHCPACK正常的 DHCP 流程应该是：
text
客户端 DHCP服务器
| |
|-------- DHCPDISCOVER --------->|
| |
|<--------- DHCPOFFER -----------|
| |
|--------- DHCPREQUEST --------->|
| |
|<---------- DHCPACK ------------|而当前实际情况是：
text
Ubuntu
|
| DHCPDISCOVER
↓
???完全收不到 Offer。
四、先用 NAT 排除 Ubuntu 自身问题
这是整个排障过程中非常重要的一步。
将 VMware 网络适配器临时切换为：
text
NAT 模式然后执行：
bash
sudo dhclient -r ens33
sudo ip link set ens33 up
sudo dhclient -v ens33这一次马上成功：
text
DHCPDISCOVER ...
DHCPOFFER of 192.168.233.128 from 192.168.233.254
DHCPREQUEST ...
DHCPACK ...
bound to 192.168.233.128查看 IP：
bash
ip -4 addr show ens33得到：
text
inet 192.168.233.128/24查看路由：
bash
ip route存在：
text
default via 192.168.233.2 dev ens33测试公网：
bash
ping -c 4 8.8.8.8成功。
测试 DNS：
bash
ping -c 4 baidu.com同样成功。
因此可以确定：
text
Ubuntu 网络栈 正常
ens33 正常
DHCP 客户端 正常
DNS 正常
VMware 虚拟网卡 正常
NAT 正常故障只存在于：
text
VMware 桥接模式五、检查 VMware Bridge Protocol
在 Windows 中打开：
text
控制面板
→ 网络和 Internet
→ 网络连接
→ WLAN
→ 属性检查：
text
VMware Bridge Protocol确保已经勾选。
也可以使用 PowerShell：
powershell
Get-NetAdapterBinding -Name 'WLAN' -ComponentID vmware_bridge | Format-List正常应该看到：
text
DisplayName : VMware Bridge Protocol
ComponentID : vmware_bridge
Enabled : True本机检查结果正是：
text
Enabled : True因此桥接协议确实绑定在 Killer Wi-Fi 网卡上。
六、检查 VMware Bridge 驱动
进一步在 Windows CMD 中执行：
cmd
sc query vmnetbridge结果：
text
SERVICE_NAME: vmnetbridge
TYPE : 1 KERNEL_DRIVER
STATE : 4 RUNNING继续检查驱动：
cmd
driverquery | findstr /i vmnet得到：
text
VMnetBridge
VMnetUserif
VMnetAdapter检查网络组件：
cmd
netcfg -s n | findstr /i vmware得到：
text
vmware_bridge VMware Bridge Protocol因此可以进一步排除：
VMware Bridge 驱动缺失或者未加载。
七、排除第三方网络过滤驱动干扰
Windows 上可能安装很多虚拟网络软件，例如：
text
Mihomo / Clash
Npcap
VirtualBox
MuMu 模拟器
Hyper-V
iNode查看 WLAN 上绑定的组件：
powershell
Get-NetAdapterBinding -Name 'WLAN' |
Format-Table DisplayName,ComponentID,Enabled -AutoSize其中发现：
text
VMware Bridge Protocol True
Npcap Packet Driver False
VirtualBox NDIS6 Bridged Driver False
MuMuVMM NDIS6 Bridged Driver False
Rawether NDIS 6.X SPR Protocol Driver True为了排除干扰，将 Rawether 临时关闭：
powershell
Disable-NetAdapterBinding -Name "WLAN" -ComponentID PCA_PCASP60再次查看：
text
Rawether NDIS 6.X SPR Protocol Driver False
VMware Bridge Protocol True同时关闭 Mihomo TUN。
不过重新测试：
bash
sudo dhclient -v ens33依然只有：
text
DHCPDISCOVER
DHCPDISCOVER说明 DHCP 问题仍然存在。
八、关键测试：不用 DHCP，手动设置静态 IP
这一步最终确定了故障性质。
Windows WLAN 当前信息：
text
Windows：
192.168.0.101/24
网关：
192.168.0.1因此选择一个暂时没有占用的地址：
text
192.168.0.250先在 Windows 中检查：
powershell
ping 192.168.0.250
arp -a | findstr 192.168.0.250确认没有设备占用。
然后 Ubuntu 中执行：
bash
sudo dhclient -r ens33
sudo ip link set ens33 up
sudo ip addr flush dev ens33
sudo ip addr add 192.168.0.250/24 dev ens33
sudo ip route replace default via 192.168.0.1 dev ens33查看：
bash
ip -4 addr show ens33结果：
text
inet 192.168.0.250/24查看路由：
bash
ip route结果：
text
default via 192.168.0.1 dev ens33
192.168.0.0/24 dev ens33九、静态 IP 下测试桥接
首先测试路由器：
bash
ping -c 4 192.168.0.1结果：
text
4 packets transmitted
4 received
0% packet loss成功。
再测试公网：
bash
ping -c 4 8.8.8.8结果同样：
text
0% packet loss继续查看 ARP：
bash
ip neigh show dev ens33得到：
text
192.168.0.1 lladdr cc:08:fb:56:7b:85 REACHABLE
192.168.0.101 lladdr 00:a5:54:af:e6:af REACHABLE这个结果非常关键。
它证明：
text
Ubuntu VM
↓
VMware VMnet0
↓
Killer Wi-Fi
↓
TP-Link 路由器整个二层网络实际上已经正常工作。
因此最终定位：
不是 VMware 桥接完全失效，而是桥接模式下 DHCP 自动获取地址失败。
十、解决 DNS 问题
设置静态 IP 后：
bash
ping -c 4 8.8.8.8成功，但是：
bash
ping baidu.com提示：
text
Temporary failure in name resolution查看：
bash
cat /etc/resolv.conf只有：
text
nameserver 127.0.0.53这里的 127.0.0.53 是 Ubuntu systemd-resolved 的本地 DNS Stub，并不是问题本身。
真正的问题是：
手动配置 IP 后，没有 DHCP 帮 ens33 下发上游 DNS。
因此执行：
bash
sudo resolvectl dns ens33 223.5.5.5 8.8.8.8
sudo resolvectl domain ens33 '~.'
sudo resolvectl default-route ens33 yes检查：
bash
resolvectl status ens33得到：
text
Current Scopes: DNS
Protocols: +DefaultRoute
DNS Servers: 223.5.5.5 8.8.8.8
DNS Domain: ~.刷新 DNS：
bash
sudo resolvectl flush-caches测试解析：
bash
resolvectl query baidu.com成功返回：
text
111.63.65.247
111.63.65.103
110.242.74.102
124.237.177.164再测试：
bash
ping -c 4 baidu.com结果：
text
4 packets transmitted
4 received
0% packet loss至此：
text
桥接 正常
IP 正常
网关 正常
公网 正常
DNS 正常十一、将静态 IP 永久写入 Netplan
前面的：
bash
ip addr add
ip route replace
resolvectl dns都属于临时配置，重启以后会丢失。
Ubuntu 当前 Netplan 文件：
bash
ls /etc/netplan/结果：
text
01-network-manager-all.yaml先备份：
bash
sudo cp /etc/netplan/01-network-manager-all.yaml \
/etc/netplan/01-network-manager-all.yaml.bak编辑：
bash
sudo nano /etc/netplan/01-network-manager-all.yaml配置为：
yaml
network:
version: 2
renderer: NetworkManager
ethernets:
ens33:
dhcp4: false
addresses:
- 192.168.0.250/24
routes:
- to: default
via: 192.168.0.1
nameservers:
addresses:
- 223.5.5.5
- 8.8.8.8注意：
YAML 文件必须使用空格缩进，不要使用 Tab。
十二、修复 Netplan 权限警告
执行：
bash
sudo netplan try出现：
text
Permissions for /etc/netplan/01-network-manager-all.yaml are too open.虽然配置可以正常工作，但 Netplan 认为权限过宽。
执行：
bash
sudo chmod 600 /etc/netplan/01-network-manager-all.yaml查看：
bash
ls -l /etc/netplan/01-network-manager-all.yaml正常应该类似：
text
-rw------- 1 root root ... 01-network-manager-all.yaml然后：
bash
sudo netplan try确认没有问题后：
bash
sudo netplan apply十三、最终验证
重启虚拟机：
bash
sudo reboot重启之后：
bash
ip -4 addr show ens33结果：
text
inet 192.168.0.250/24查看路由：
bash
ip route结果：
text
default via 192.168.0.1 dev ens33 proto static metric 100
192.168.0.0/24 dev ens33 proto kernel scope link src 192.168.0.250测试：
bash
ping -c 4 baidu.com结果：
text
4 packets transmitted
4 received
0% packet loss至此问题完全解决。
十四、最终网络结构
解决以后，网络结构如下：
text
TP-Link 路由器
192.168.0.1
│
│ Wi-Fi
│
Killer Wi-Fi AX1650i
│
┌──────────┴──────────┐
│ │
Windows 11 VMware Bridge
192.168.0.101 VMnet0
│
│
Ubuntu ens33
192.168.0.250此时 Windows、Ubuntu 虚拟机，以及同一路由器下的其他设备，都处于：
text
192.168.0.0/24同一局域网中。
这非常适合：
text
ROS / ROS2 多机通信
PuppyPi
树莓派
机器人控制器
嵌入式 Linux 开发板
网络摄像头
雷达等需要局域网设备互访的开发场景。
十五、这次问题的核心判断逻辑
整个排障过程中，最重要的不是不断修改 VMware 设置，而是逐层定位。
可以总结成：
text
ens33 是否存在？
│
├── 不存在 → VMware 虚拟网卡 / 驱动
│
└── 存在
↓
ens33 UP？
│
↓
DHCP 能获得 IP？
│ │
YES NO
│ ↓
│ NAT 是否正常？
│ │
│ ├── NO → Ubuntu / VMware 基础网络
│ │
│ └── YES
│ ↓
│ 桥接 DHCP 问题
│ ↓
│ 手动配置静态 IP
│ ↓
│ ping 网关是否成功？
│ │ │
│ NO YES
│ │ │
│ 二层桥接故障 桥接实际正常
│ ↓
│ 仅 DHCP 异常
│ ↓
│ 配置静态 IP
│ ↓
│ 配置 DNS
│ ↓
└──────────────→ 网络恢复十六、几个容易误判的地方
1. Temporary failure in name resolution 不代表一定是 DNS 的根本问题
最开始看到：
text
Temporary failure in name resolution很容易直接修改 /etc/resolv.conf。
但如果虚拟机连 IP 地址都没有，那么修改 DNS 没有意义。
正确顺序应该是：
text
网卡
↓
IP
↓
路由
↓
公网 IP
↓
DNS例如：
bash
ping 8.8.8.8都不通时，优先检查 IP/路由，而不是 DNS。
2. DHCPDISCOVER 能发出去，不代表桥接一定坏了
本次最开始：
text
DHCPDISCOVER
DHCPDISCOVER
DHCPDISCOVER没有 Offer。
很容易认为：
VMware Bridge 完全没有工作。
但后来静态 IP 测试发现：
bash
ping 192.168.0.1正常。
bash
ping 8.8.8.8也正常。
说明二层桥接实际上已经工作，只是 DHCP 自动分配异常。
3. NAT 正常是一个非常重要的排除依据
如果 NAT：
text
DHCPOFFER
DHCPACK
Internet OK
DNS OK那么一般可以快速排除：
text
Ubuntu 驱动
ens33
dhclient
Linux TCP/IP
VMware 虚拟网卡排查重点应该转移到桥接层。
4. 修改路由和 DHCP 一定要使用 sudo
例如：
bash
dhclient -v ens33可能报：
text
Permission denied
Operation not permitted正确写法：
bash
sudo dhclient -v ens33同样：
bash
ip route replace default via 192.168.0.1 dev ens33也需要：
bash
sudo ip route replace default via 192.168.0.1 dev ens33十七、最终使用的配置
VMware：
text
VMnet0
桥接模式
桥接到：
Killer(R) Wi-Fi 6 AX1650iUbuntu：
text
接口：ens33
IP：
192.168.0.250/24
Gateway：
192.168.0.1
DNS：
223.5.5.5
8.8.8.8Netplan：
yaml
network:
version: 2
renderer: NetworkManager
ethernets:
ens33:
dhcp4: false
addresses:
- 192.168.0.250/24
routes:
- to: default
via: 192.168.0.1
nameservers:
addresses:
- 223.5.5.5
- 8.8.8.8十八、总结
这次 VMware 桥接无法联网的问题，最终并不是：
text
Ubuntu 网卡驱动问题
VMware Bridge Protocol 缺失
VMnet0 配置错误
DNS 本身损坏真正的现象是：
text
NAT DHCP 正常
桥接 DHCP 异常
桥接 DHCPDISCOVER 可以发出
桥接 DHCPOFFER 收不到
但是：
桥接静态 IP 正常
ARP 正常
默认网关 正常
Internet 正常
DNS 手动配置后 正常因此最终解决方案是：
保留 VMware VMnet0 桥接模式，为 Ubuntu ens33 配置同一物理局域网中的永久静态 IP，同时设置默认网关和 DNS。
最终网络：
text
Windows：192.168.0.101
Ubuntu：
192.168.0.250
Router：
192.168.0.1虚拟机不仅能够正常访问 Internet，还真正进入了物理局域网。
对于 ROS、机器人、树莓派以及嵌入式开发而言，这种固定桥接 IP 的配置实际上比 DHCP 更实用，因为设备地址固定以后，多机通信、SSH、ROS 节点配置以及调试都会更加方便。
一句话排障经验
VMware 桥接模式下 DHCP 一直只有 DHCPDISCOVER 时，不要马上认定桥接彻底坏了。先给虚拟机手动配置一个与宿主机同网段的静态 IP，然后 ping 物理网关。如果网关和公网都能通，说明桥接链路本身是正常的，问题只是 DHCP。