简介针对VMware虚拟机中Ubuntu系统无法上网的常见问题这份doc文档提供了一套基于NAT模式的完整配置方案。内容以VMware 7.1.0与Ubuntu 10.10为例适合刚接触虚拟机网络设置的初学者。资源为单份doc格式说明书体积仅63KB下载后即可快速查阅。目前已有988人学习使用。文档从修改虚拟机以太网模式开始详细讲解如何通过主机ipconfig获取vmnet8信息再进入Ubuntu网络连接界面手动配置IPv4地址、子网掩码、网关及DNS服务器并补充Windows服务中开启VMware NAT Service与DHCP Service的排错步骤。按此流程可逐步理清NAT模式下宿主机与虚拟机的网络对应关系解决配置后仍无法上网的问题。整个说明步骤明确适合边操作边对照。 装完Ubuntu后打开终端敲ping baidu.com结果一串串的Network is unreachable——这个场景我见过太多次了。每次有人问我VMware里Ubuntu怎么联网我几乎都能猜到问题出在哪大部分时候根本不是你Ubuntu装错了而是虚拟机网络模式、宿主机服务和网卡驱动这几个环节里有某一环悄悄出了岔子。这篇文章围绕VMware Workstation里安装Ubuntu后的网络连接设置把NAT、桥接、仅主机三种模式讲清楚给出从宿主机到虚拟机一步步排查的思路再手把手教你配静态IP、做端口转发、搞定SSH远程和开发板挂载场景。不管是刚装好系统准备apt install的新手还是被网络问题折腾了半天的老手都值得对照着过一遍。1. 先搞清楚三种网络模式的区别再动手改配置很多人一上来就开改配置文件改完还是不通最后发现问题是模式选错了。VMware的三种网络模式本质上是虚拟机网卡接入宿主机网络的不同方式理解它们之后再动手效率完全不一样。1.1 NAT模式默认方案多数场景不用改NAT模式网络地址转换是VMware安装后默认给虚拟机用的模式。虚拟机通过虚拟网卡连到虚拟交换机VMnet8上再由宿主机的VMware NAT服务做地址转换把虚拟机的流量伪装成宿主机的流量发出去。打个比方宿主机相当于小区的大门家里装了个路由器NAT服务虚拟机是躲在路由器后面的住户。住户可以自由出去上网但外面的人看不到住户的存在也直接访问不到住户的电脑。NAT模式下虚拟机的IP是VMnet8网段内的地址比如192.168.x.x网关是192.168.x.2。日常跑apt install、访问网站、下载Docker镜像、看文档这个模式完全够用。宿主机换网络环境比如从家里的WiFi换到公司的有线网虚拟机网络不受影响这也是它作为默认模式的原因。1.2 桥接模式让虚拟机在局域网里单独立户桥接模式Bridged是把虚拟机的虚拟网卡直接桥接到宿主机的物理网卡上。逻辑上虚拟机成了和宿主机并列的一个独立设备它自己在局域网里获取IP局域网里的其他设备路由器、其他电脑、手机都能直接看到它、访问它。桥接模式适合什么场景你要在虚拟机里跑一个Web服务然后让办公室其他人通过局域网IP直接访问或者你要组建一个开发板NFS文件挂载的环境需要开发板、宿主机、虚拟机三者互相ping通。缺点也很明确宿主机一旦切换网络环境虚拟机的IP可能失效而且如果路由器开启了AP隔离桥接模式下虚拟机和局域网其他设备也是不通的。1.3 仅主机模式隔离环境专用的封闭网络仅主机模式Host-only下虚拟机只能和宿主机通信不能访问外网。它使用VMnet1虚拟网卡属于一个封闭岛国。有些人觉得这个模式没用其实它在安全测试、恶意软件分析、内网环境模拟这些要求隔离的场景里很常用。日常使用中如果你只是想让虚拟机和宿主机之间互相传文件又不想让虚拟机碰到外网选这个模式最稳。1.4 选型建议使用场景推荐模式说明日常上网、装软件、更新系统NAT默认无需额外配置局域网内提供Web服务、SSH供他人访问桥接需要固定局域网IP和宿主机互传文件完全不碰外网仅主机隔离性最好开发板通过NFS挂载虚拟机目录桥接或仅主机保证同网段互通虚拟机里跑Docker并需要拉镜像NATDocker的默认bridge网络在NAT模式下最顺畅2. VMware里Ubuntu网络不通的完整排查链路网络不通的时候最忌讳瞎改配置。我自己的排查习惯是从外向里、从底向上先看宿主机上的VMware服务再看虚拟机里的网卡和IP最后才看路由和DNS。按这个顺序走一遍绝大多数问题都能定位。2.1 第一层宿主机上的VMware虚拟网卡和服务是否正常安装VMware Workstation后Windows的网络连接里会多出两块虚拟网卡VMnet1对应仅主机模式和VMnet8对应NAT模式。第一步先在Windows里确认这两块网卡存在且处于启用状态。如果被禁用虚拟机里的网络大概率直接瘫痪。接着打开Windows服务管理器WinR输入services.msc找到三个关键服务VMware NAT Service负责NAT模式的流量转发VMware DHCP Service负责给虚拟机分配IP地址VMware Authorization Service负责虚拟机启动和权限校验把它们的启动类型设为自动状态确保为正在运行。我遇到过不止一次安全软件把VMware NAT Service拦截掉的案例表现就是Ubuntu里网卡正常、配置没问题但死活上不了网最后发现是宿主机服务挂了。这三个服务是网络正常工作的前提排查顺序上永远是第一梯队。2.2 第二层Ubuntu里网卡有没有被识别、有没有拿到地址宿主机服务正常后进入Ubuntu终端执行两条命令ip addr ip link show先看有没有虚拟网卡常见名字是ens33、ens160、ens192再看网卡的状态是不是UP最后看有没有分配到IP地址。有网卡但状态是DOWN可以手动拉起sudo ip link set ens33 up如果ip addr里网卡显示有inet 192.168.x.x这样的地址说明DHCP动态主机配置协议已经分配成功了。如果只有127.0.0.1这个回环地址说明虚拟机根本没有从VMware DHCP服务拿到IP这时候可以手动触发一次DHCP请求sudo dhclient ens33Ubuntu 18.04及之后的版本默认用netplan管理网络systemd-networkd或NetworkManager作为renderer。如果你改了配置文件但没生效可以强行释放并重新获取地址sudo ip addr flush dev ens33 sudo dhclient ens332.3 第三层路由和DNS问题怎么区分拿到IP之后还不通就需要区分是路由问题还是DNS问题。我的方法论很简单ping 宿主机IP通不通不通说明虚拟机到宿主机这一跳有问题。ping 网关NAT模式下通常是192.168.x.2通不通不通说明默认路由有问题。ping 8.8.8.8或223.5.5.5通不通不通说明外网出口有问题。ping baidu.com通不通通如果不通但上一步通说明DNS解析有问题。判断逻辑是能ping通IP但不能ping通域名是DNS配置错误IP都ping不通是路由或者网关错误跟DNS没关系。如果发现默认路由丢失用ip route查看ip route show正常应该有一条形如default via 192.168.x.2 dev ens33的默认路由。没有就用sudo ip route add default via 192.168.x.2 dev ens33手动加但这是临时方案重启会丢根治还得靠改配置文件。3. 静态IP配置实战netplan和interfaces两种写法都要会为什么需要静态IP最简单的原因DHCP分配过来的IP是会变的。你今天用SSH连的是192.168.18.128明天重启了虚拟机IP可能变成192.168.18.135配置全得跟着改。开发板挂载、跑服务、搭集群的时候一个稳定不变的IP比什么都强。3.1 netplan新版Ubuntu的默认方式Ubuntu 18.04开始用netplan管理网络配置文件放在/etc/netplan/目录下通常是01-network-manager-all.yaml或类似名字。在改之前先把原文件备份一份sudo cp /etc/netplan/01-network-manager-all.yaml /etc/netplan/01-network-manager-all.yaml.bak然后用编辑器打开写这样一个静态IP配置network: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: no addresses: - 192.168.18.100/24 routes: - to: default via: 192.168.18.2 nameservers: addresses: - 223.5.5.5 - 119.29.29.29这里有几个容易踩的坑逐一说明renderer要看你的图形界面网络管理工具是NetworkManager还是systemd-networkd写反了会导致网络管理工具冲突。dhcp4: no表示关闭自动获取IP改用下面手写的地址。addresses里的子网掩码是CIDR写法/24等价于255.255.255.0漏掉或写错格式直接报错。NAT模式下默认网关永远是VMnet8网段的.2不是.1也不是.254这是VMware的固定习惯和家里路由器用.1当网关不一样。YAML文件对缩进极其敏感必须用空格不能用Tab。报错的时候先怀疑缩进。改完后执行sudo netplan apply然后重新ip addr确认IP已经变成自己写的那个。3.2 interfaces老版本Ubuntu的经典配法更老版本的Ubuntu16.04及之前用的是ifupdown配置文件在/etc/network/interfaces。虽然新系统不推荐了但很多老服务器、嵌入式系统的文档还在用这套写法看懂它没什么坏处auto ens33 iface ens33 inet static address 192.168.18.100 netmask 255.255.255.0 gateway 192.168.18.2 dns-nameservers 223.5.5.5改完重启网络服务sudo systemctl restart networking要注意如果一个系统同时装了NetworkManager又去改interfaces文件两边可能互相覆盖最后结果取决于NetworkManager是不是unmanaged状态。这种冲突很容易把人绕晕所以新系统一律建议统一用netplan这一套管理。3.3 静态IP配置的常见错误我总结过几次踩坑记录静态IP不生效基本逃不出这几个原因网卡名写错拿ip addr确认实际网卡名是ens33还是别的不是每个虚拟机都叫这个。IP和网关不在同一网段比如把IP设为192.168.18.100网关却写192.168.88.2这样路由必死。DNS未配置IP通了但域名解析不了多半是nameservers没写或者写错了。多个yaml文件冲突/etc/netplan下如果有多个yaml文件netplan会合并处理配置冲突时行为会变得诡异。建议只保留一个有效文件。权限不够改netplan文件必须用sudo。有个热搜词问Ubuntu怎么切换超级管理员其实日常操作就是sudo -i或者sudo su -切换后获得的root权限就是干这个用的不是什么神秘的密码问题。4. 虚拟网络编辑器里的隐形开关子网、DHCP与端口转发很多人在Ubuntu里折腾半天却忽略了VMware Workstation自带的虚拟网络编辑器。这个工具管着虚拟网络的底层参数属于最容易忽视的部分。4.1 子网网段和DHCP地址池怎么看怎么改菜单栏编辑→虚拟网络编辑器打开后能看到VMnet0、VMnet1、VMnet8这些条目。点击VMnet8下面的NAT设置和DHCP设置按钮里藏着关键信息子网IP默认是192.168.x.0/24这个网段决定了虚拟机IP的分配范围。NAT设置里的网关IP默认是192.168.x.2前面反复提到的网关就是它。DHCP设置里的起始IP和结束IP决定自动分配IP的区间。假设你家里局域网也是192.168.18.x网段和VMware的NAT网段冲突了虚拟机的网络可能出现诡异现象。这时可以在这里把VMnet8子网改成别的网段比如192.168.118.0/24改完后记得Ubuntu里的静态IP和网关也要同步改。4.2 对NAT模式做端口转发外部访问虚拟机的最优雅方案NAT模式下外部默认访问不到虚拟机。但通过端口转发可以实现别人访问宿主机IP的特定端口流量自动转发到虚拟机里的某个端口。举个例子你在vmware虚拟机的Ubuntu里装了SSH服务监听22端口。现在想让局域网里的同事通过宿主机IP访问这台虚拟机可以在虚拟网络编辑器里选择VMnet8 → NAT设置 → 添加端口转发把宿主机的2222端口转发到虚拟机的22端口。配置完成后同事在浏览器或者SSH客户端里连接宿主机IP:2222实际就连到了虚拟机的22端口。这比改成桥接模式暴露整个虚拟机更可控、更安全。4.3 启动虚拟机报无法连接到虚拟机怎么办热搜词里有一条很典型vmware workstation 无法连接到虚拟机。请确保您有权运行该程序。这个报错虽然不完全是网络配置问题但经常和网络服务混在一起出现。根据我的经验先做三件事右键VMware Workstation图标以管理员身份运行权限问题是最常见的诱因。回到服务管理器确认VMware Authorization Service是否在运行把它设为自动并启动。检查虚拟机设置里的网络适配器是否被误删或禁用特别是在编辑虚拟机设置里确认一下设备状态勾选了启动时连接。5. SSH远程连接与开发板挂载场景下的网络补充操作配置好基础网络后有两个高频场景值得单独说SSH远程登录和开发板挂载。5.1 NAT模式下用SSH连虚拟机的完整路径如果你习惯用Windows上的FinalShell、Xshell或终端直接操作Ubuntu先要给Ubuntu装SSH服务sudo apt update sudo apt install openssh-server sudo systemctl enable --now ssh然后按前面说的在虚拟网络编辑器里把宿主机的某个端口比如2222转发到虚拟机的22端口。之后就能在宿主机上执行ssh username127.0.0.1 -p 2222或者让局域网其他机器执行ssh username宿主机IP -p 2222。桥接模式下就不用这么绕直接ssh username虚拟机IP即可前提是Windows防火墙放行了22端口或SSH程序。5.2 开发板与虚拟机网络互通同网段是唯一原则很多做嵌入式开发的朋友会遇到开发板要挂载Ubuntu目录的情况——比如用NFS网络文件系统让开发板直接访问Ubuntu里的共享目录。这种场景下网络互通的硬性条件是开发板和虚拟机必须在同一个网段并且互相能ping通。实际操作上我建议把VMware虚拟机改成桥接模式或仅主机模式然后给Ubuntu配一个192.168.x.x网段的静态IP开发板也设成同网段的IP。测试顺序是Ubuntu能ping通开发板 → 开发板能ping通Ubuntu → 再谈NFS挂载。如果在开发板上能ping通Ubuntu的IP但挂载NFS超时优先检查Ubuntu上是否装了nfs-kernel-server并导出目录网络本身已经不是瓶颈了。5.3 配置网络过程中遇到过的一个容易忽略的坑还有一个细节容易被忽略修改网络配置前先把Ubuntu里不必要的桌面网络管理工具关掉。有些版本的Ubuntu桌面版同时存在NetworkManager和systemd-networkd两套管理工具如果netplan里renderer写的和实际使用的不一致会出现ip addr看着正常、但网络就是起不来的怪象。遇到这种玄学问题先nmcli device status看一眼网卡的状态是不是被NetworkManagerunmanaged了被托管的状态下网络管理逻辑完全不同。最后再分享一个个人习惯不管问题看起来多像Ubuntu配置问题我永远从宿主机服务层开始排查因为VMware虚拟网络本身就是一台小路由器路由器都没工作虚拟机里再怎么改也是白费力气。先看服务、再看网卡、再看IP、再看路由DNS按这个顺序来VMware里Ubuntu的网络问题90%都能在十分钟内解决。你折腾几小时的配置说不定最后只是宿主机上某个VMware服务没启动而已。本文还有配套的精品资源点击获取 VMware里Ubuntu网络配置详解：NAT、桥接、静态IP与故障排查
简介针对VMware虚拟机中Ubuntu系统无法上网的常见问题这份doc文档提供了一套基于NAT模式的完整配置方案。内容以VMware 7.1.0与Ubuntu 10.10为例适合刚接触虚拟机网络设置的初学者。资源为单份doc格式说明书体积仅63KB下载后即可快速查阅。目前已有988人学习使用。文档从修改虚拟机以太网模式开始详细讲解如何通过主机ipconfig获取vmnet8信息再进入Ubuntu网络连接界面手动配置IPv4地址、子网掩码、网关及DNS服务器并补充Windows服务中开启VMware NAT Service与DHCP Service的排错步骤。按此流程可逐步理清NAT模式下宿主机与虚拟机的网络对应关系解决配置后仍无法上网的问题。整个说明步骤明确适合边操作边对照。 装完Ubuntu后打开终端敲ping baidu.com结果一串串的Network is unreachable——这个场景我见过太多次了。每次有人问我VMware里Ubuntu怎么联网我几乎都能猜到问题出在哪大部分时候根本不是你Ubuntu装错了而是虚拟机网络模式、宿主机服务和网卡驱动这几个环节里有某一环悄悄出了岔子。这篇文章围绕VMware Workstation里安装Ubuntu后的网络连接设置把NAT、桥接、仅主机三种模式讲清楚给出从宿主机到虚拟机一步步排查的思路再手把手教你配静态IP、做端口转发、搞定SSH远程和开发板挂载场景。不管是刚装好系统准备apt install的新手还是被网络问题折腾了半天的老手都值得对照着过一遍。1. 先搞清楚三种网络模式的区别再动手改配置很多人一上来就开改配置文件改完还是不通最后发现问题是模式选错了。VMware的三种网络模式本质上是虚拟机网卡接入宿主机网络的不同方式理解它们之后再动手效率完全不一样。1.1 NAT模式默认方案多数场景不用改NAT模式网络地址转换是VMware安装后默认给虚拟机用的模式。虚拟机通过虚拟网卡连到虚拟交换机VMnet8上再由宿主机的VMware NAT服务做地址转换把虚拟机的流量伪装成宿主机的流量发出去。打个比方宿主机相当于小区的大门家里装了个路由器NAT服务虚拟机是躲在路由器后面的住户。住户可以自由出去上网但外面的人看不到住户的存在也直接访问不到住户的电脑。NAT模式下虚拟机的IP是VMnet8网段内的地址比如192.168.x.x网关是192.168.x.2。日常跑apt install、访问网站、下载Docker镜像、看文档这个模式完全够用。宿主机换网络环境比如从家里的WiFi换到公司的有线网虚拟机网络不受影响这也是它作为默认模式的原因。1.2 桥接模式让虚拟机在局域网里单独立户桥接模式Bridged是把虚拟机的虚拟网卡直接桥接到宿主机的物理网卡上。逻辑上虚拟机成了和宿主机并列的一个独立设备它自己在局域网里获取IP局域网里的其他设备路由器、其他电脑、手机都能直接看到它、访问它。桥接模式适合什么场景你要在虚拟机里跑一个Web服务然后让办公室其他人通过局域网IP直接访问或者你要组建一个开发板NFS文件挂载的环境需要开发板、宿主机、虚拟机三者互相ping通。缺点也很明确宿主机一旦切换网络环境虚拟机的IP可能失效而且如果路由器开启了AP隔离桥接模式下虚拟机和局域网其他设备也是不通的。1.3 仅主机模式隔离环境专用的封闭网络仅主机模式Host-only下虚拟机只能和宿主机通信不能访问外网。它使用VMnet1虚拟网卡属于一个封闭岛国。有些人觉得这个模式没用其实它在安全测试、恶意软件分析、内网环境模拟这些要求隔离的场景里很常用。日常使用中如果你只是想让虚拟机和宿主机之间互相传文件又不想让虚拟机碰到外网选这个模式最稳。1.4 选型建议使用场景推荐模式说明日常上网、装软件、更新系统NAT默认无需额外配置局域网内提供Web服务、SSH供他人访问桥接需要固定局域网IP和宿主机互传文件完全不碰外网仅主机隔离性最好开发板通过NFS挂载虚拟机目录桥接或仅主机保证同网段互通虚拟机里跑Docker并需要拉镜像NATDocker的默认bridge网络在NAT模式下最顺畅2. VMware里Ubuntu网络不通的完整排查链路网络不通的时候最忌讳瞎改配置。我自己的排查习惯是从外向里、从底向上先看宿主机上的VMware服务再看虚拟机里的网卡和IP最后才看路由和DNS。按这个顺序走一遍绝大多数问题都能定位。2.1 第一层宿主机上的VMware虚拟网卡和服务是否正常安装VMware Workstation后Windows的网络连接里会多出两块虚拟网卡VMnet1对应仅主机模式和VMnet8对应NAT模式。第一步先在Windows里确认这两块网卡存在且处于启用状态。如果被禁用虚拟机里的网络大概率直接瘫痪。接着打开Windows服务管理器WinR输入services.msc找到三个关键服务VMware NAT Service负责NAT模式的流量转发VMware DHCP Service负责给虚拟机分配IP地址VMware Authorization Service负责虚拟机启动和权限校验把它们的启动类型设为自动状态确保为正在运行。我遇到过不止一次安全软件把VMware NAT Service拦截掉的案例表现就是Ubuntu里网卡正常、配置没问题但死活上不了网最后发现是宿主机服务挂了。这三个服务是网络正常工作的前提排查顺序上永远是第一梯队。2.2 第二层Ubuntu里网卡有没有被识别、有没有拿到地址宿主机服务正常后进入Ubuntu终端执行两条命令ip addr ip link show先看有没有虚拟网卡常见名字是ens33、ens160、ens192再看网卡的状态是不是UP最后看有没有分配到IP地址。有网卡但状态是DOWN可以手动拉起sudo ip link set ens33 up如果ip addr里网卡显示有inet 192.168.x.x这样的地址说明DHCP动态主机配置协议已经分配成功了。如果只有127.0.0.1这个回环地址说明虚拟机根本没有从VMware DHCP服务拿到IP这时候可以手动触发一次DHCP请求sudo dhclient ens33Ubuntu 18.04及之后的版本默认用netplan管理网络systemd-networkd或NetworkManager作为renderer。如果你改了配置文件但没生效可以强行释放并重新获取地址sudo ip addr flush dev ens33 sudo dhclient ens332.3 第三层路由和DNS问题怎么区分拿到IP之后还不通就需要区分是路由问题还是DNS问题。我的方法论很简单ping 宿主机IP通不通不通说明虚拟机到宿主机这一跳有问题。ping 网关NAT模式下通常是192.168.x.2通不通不通说明默认路由有问题。ping 8.8.8.8或223.5.5.5通不通不通说明外网出口有问题。ping baidu.com通不通通如果不通但上一步通说明DNS解析有问题。判断逻辑是能ping通IP但不能ping通域名是DNS配置错误IP都ping不通是路由或者网关错误跟DNS没关系。如果发现默认路由丢失用ip route查看ip route show正常应该有一条形如default via 192.168.x.2 dev ens33的默认路由。没有就用sudo ip route add default via 192.168.x.2 dev ens33手动加但这是临时方案重启会丢根治还得靠改配置文件。3. 静态IP配置实战netplan和interfaces两种写法都要会为什么需要静态IP最简单的原因DHCP分配过来的IP是会变的。你今天用SSH连的是192.168.18.128明天重启了虚拟机IP可能变成192.168.18.135配置全得跟着改。开发板挂载、跑服务、搭集群的时候一个稳定不变的IP比什么都强。3.1 netplan新版Ubuntu的默认方式Ubuntu 18.04开始用netplan管理网络配置文件放在/etc/netplan/目录下通常是01-network-manager-all.yaml或类似名字。在改之前先把原文件备份一份sudo cp /etc/netplan/01-network-manager-all.yaml /etc/netplan/01-network-manager-all.yaml.bak然后用编辑器打开写这样一个静态IP配置network: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: no addresses: - 192.168.18.100/24 routes: - to: default via: 192.168.18.2 nameservers: addresses: - 223.5.5.5 - 119.29.29.29这里有几个容易踩的坑逐一说明renderer要看你的图形界面网络管理工具是NetworkManager还是systemd-networkd写反了会导致网络管理工具冲突。dhcp4: no表示关闭自动获取IP改用下面手写的地址。addresses里的子网掩码是CIDR写法/24等价于255.255.255.0漏掉或写错格式直接报错。NAT模式下默认网关永远是VMnet8网段的.2不是.1也不是.254这是VMware的固定习惯和家里路由器用.1当网关不一样。YAML文件对缩进极其敏感必须用空格不能用Tab。报错的时候先怀疑缩进。改完后执行sudo netplan apply然后重新ip addr确认IP已经变成自己写的那个。3.2 interfaces老版本Ubuntu的经典配法更老版本的Ubuntu16.04及之前用的是ifupdown配置文件在/etc/network/interfaces。虽然新系统不推荐了但很多老服务器、嵌入式系统的文档还在用这套写法看懂它没什么坏处auto ens33 iface ens33 inet static address 192.168.18.100 netmask 255.255.255.0 gateway 192.168.18.2 dns-nameservers 223.5.5.5改完重启网络服务sudo systemctl restart networking要注意如果一个系统同时装了NetworkManager又去改interfaces文件两边可能互相覆盖最后结果取决于NetworkManager是不是unmanaged状态。这种冲突很容易把人绕晕所以新系统一律建议统一用netplan这一套管理。3.3 静态IP配置的常见错误我总结过几次踩坑记录静态IP不生效基本逃不出这几个原因网卡名写错拿ip addr确认实际网卡名是ens33还是别的不是每个虚拟机都叫这个。IP和网关不在同一网段比如把IP设为192.168.18.100网关却写192.168.88.2这样路由必死。DNS未配置IP通了但域名解析不了多半是nameservers没写或者写错了。多个yaml文件冲突/etc/netplan下如果有多个yaml文件netplan会合并处理配置冲突时行为会变得诡异。建议只保留一个有效文件。权限不够改netplan文件必须用sudo。有个热搜词问Ubuntu怎么切换超级管理员其实日常操作就是sudo -i或者sudo su -切换后获得的root权限就是干这个用的不是什么神秘的密码问题。4. 虚拟网络编辑器里的隐形开关子网、DHCP与端口转发很多人在Ubuntu里折腾半天却忽略了VMware Workstation自带的虚拟网络编辑器。这个工具管着虚拟网络的底层参数属于最容易忽视的部分。4.1 子网网段和DHCP地址池怎么看怎么改菜单栏编辑→虚拟网络编辑器打开后能看到VMnet0、VMnet1、VMnet8这些条目。点击VMnet8下面的NAT设置和DHCP设置按钮里藏着关键信息子网IP默认是192.168.x.0/24这个网段决定了虚拟机IP的分配范围。NAT设置里的网关IP默认是192.168.x.2前面反复提到的网关就是它。DHCP设置里的起始IP和结束IP决定自动分配IP的区间。假设你家里局域网也是192.168.18.x网段和VMware的NAT网段冲突了虚拟机的网络可能出现诡异现象。这时可以在这里把VMnet8子网改成别的网段比如192.168.118.0/24改完后记得Ubuntu里的静态IP和网关也要同步改。4.2 对NAT模式做端口转发外部访问虚拟机的最优雅方案NAT模式下外部默认访问不到虚拟机。但通过端口转发可以实现别人访问宿主机IP的特定端口流量自动转发到虚拟机里的某个端口。举个例子你在vmware虚拟机的Ubuntu里装了SSH服务监听22端口。现在想让局域网里的同事通过宿主机IP访问这台虚拟机可以在虚拟网络编辑器里选择VMnet8 → NAT设置 → 添加端口转发把宿主机的2222端口转发到虚拟机的22端口。配置完成后同事在浏览器或者SSH客户端里连接宿主机IP:2222实际就连到了虚拟机的22端口。这比改成桥接模式暴露整个虚拟机更可控、更安全。4.3 启动虚拟机报无法连接到虚拟机怎么办热搜词里有一条很典型vmware workstation 无法连接到虚拟机。请确保您有权运行该程序。这个报错虽然不完全是网络配置问题但经常和网络服务混在一起出现。根据我的经验先做三件事右键VMware Workstation图标以管理员身份运行权限问题是最常见的诱因。回到服务管理器确认VMware Authorization Service是否在运行把它设为自动并启动。检查虚拟机设置里的网络适配器是否被误删或禁用特别是在编辑虚拟机设置里确认一下设备状态勾选了启动时连接。5. SSH远程连接与开发板挂载场景下的网络补充操作配置好基础网络后有两个高频场景值得单独说SSH远程登录和开发板挂载。5.1 NAT模式下用SSH连虚拟机的完整路径如果你习惯用Windows上的FinalShell、Xshell或终端直接操作Ubuntu先要给Ubuntu装SSH服务sudo apt update sudo apt install openssh-server sudo systemctl enable --now ssh然后按前面说的在虚拟网络编辑器里把宿主机的某个端口比如2222转发到虚拟机的22端口。之后就能在宿主机上执行ssh username127.0.0.1 -p 2222或者让局域网其他机器执行ssh username宿主机IP -p 2222。桥接模式下就不用这么绕直接ssh username虚拟机IP即可前提是Windows防火墙放行了22端口或SSH程序。5.2 开发板与虚拟机网络互通同网段是唯一原则很多做嵌入式开发的朋友会遇到开发板要挂载Ubuntu目录的情况——比如用NFS网络文件系统让开发板直接访问Ubuntu里的共享目录。这种场景下网络互通的硬性条件是开发板和虚拟机必须在同一个网段并且互相能ping通。实际操作上我建议把VMware虚拟机改成桥接模式或仅主机模式然后给Ubuntu配一个192.168.x.x网段的静态IP开发板也设成同网段的IP。测试顺序是Ubuntu能ping通开发板 → 开发板能ping通Ubuntu → 再谈NFS挂载。如果在开发板上能ping通Ubuntu的IP但挂载NFS超时优先检查Ubuntu上是否装了nfs-kernel-server并导出目录网络本身已经不是瓶颈了。5.3 配置网络过程中遇到过的一个容易忽略的坑还有一个细节容易被忽略修改网络配置前先把Ubuntu里不必要的桌面网络管理工具关掉。有些版本的Ubuntu桌面版同时存在NetworkManager和systemd-networkd两套管理工具如果netplan里renderer写的和实际使用的不一致会出现ip addr看着正常、但网络就是起不来的怪象。遇到这种玄学问题先nmcli device status看一眼网卡的状态是不是被NetworkManagerunmanaged了被托管的状态下网络管理逻辑完全不同。最后再分享一个个人习惯不管问题看起来多像Ubuntu配置问题我永远从宿主机服务层开始排查因为VMware虚拟网络本身就是一台小路由器路由器都没工作虚拟机里再怎么改也是白费力气。先看服务、再看网卡、再看IP、再看路由DNS按这个顺序来VMware里Ubuntu的网络问题90%都能在十分钟内解决。你折腾几小时的配置说不定最后只是宿主机上某个VMware服务没启动而已。本文还有配套的精品资源点击获取