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