VMware NAT 模式 Ubuntu 20.04 静态 IP 配置指南

1. 为什么虚拟机里的 Ubuntu 值得配一个固定 IP

刚接触 vmware 虚拟机安装教程的朋友，大概率都会经历这么一段：装好 ubuntu 20.04，网络用默认的 NAT，能上网、能 apt install，一切岁月静好。直到某天你想用 SSH 连进去、想跑个数据库对外提供服务、想把宿主机上的代码同步进去，才发现每次重启后 IP 都变了，昨天连的是 192.168.x.129，今天变成 192.168.x.131，脚本里的那串地址直接失效。这就是我坚持在任何一台长期使用的虚拟机上配静态 IP 的原因——不是强迫症，是省命。

这篇内容就是把我这些年反复折腾 vmware + ubuntu 20.04 网络配置的经验，完整地摊开讲一遍。核心围绕 vmware 的 NAT 模式，讲清楚怎么给 ubuntu 20.04 设置一个永远不会变的静态 IP，为什么 NAT 模式下要这么配，配的时候哪些参数是从哪来的，配完为什么会掉，掉完怎么救。适合刚上手的运维新人、需要在本地搭开发环境的程序员、以及想学网络配置但一直被各种教程带偏的同学。不管你之前有没有碰过 netplan 或者 networkd，读完都能自己动手搞定，并且明白每一步背后的道理。

我先把结论摆在这：在 NAT 模式下配静态 IP，最关键的三个数字是子网网段、网关地址和DNS 地址，它们全部来自 VMware 的虚拟网络编辑器，不是拍脑袋编的。把这三个数找准，剩下的就是把它们写进 ubuntu 20.04 的 netplan 配置文件里，重启生效。听起来简单，但每个环节都有坑，下面一步步来。

1.1 NAT 模式到底做了什么

很多人用 NAT 模式是因为它“开箱即用”——虚拟机不用额外配置就能上网。但很少有人真正搞清楚它在背后干了什么。VMware 在宿主机上装了一块叫VMnet8的虚拟网卡，所有 NAT 模式下的虚拟机都接到这块虚拟交换机上，形成一个封闭的内网。虚拟机要访问外网时，请求先发到 VMware 的 NAT 设备（通常就是这个网段里的 .2 地址），由它帮你做一次地址转换，把你的私有 IP 换成宿主机的 IP 再发出去，回来的数据包再转回来。整个过程你在虚拟机里是无感的，看起来就像直接联网。

理解了这一点，静态 IP 的配置逻辑就顺了。因为 NAT 网络是一个由 VMware 自己规划好的内网，网关是固定的，网段是固定的，DHCP 池也是固定的。你要做的不是“创造一个 IP”，而是从 VMware 已经划好的地盘里，挑一个不在 DHCP 分配范围内的地址，声明成我自己的。这就解释了为什么不能随便写个 192.168.1.100 就行——那可能根本不在你的 VMnet8 网段里，写了也上不了网。

注意：NAT 模式下虚拟机之间可以互相通信，宿主机也能访问虚拟机，但局域网里其他物理机器默认访问不到你的虚拟机。如果确实需要被外部机器访问，后面我会讲端口转发的办法，不需要改成桥接。

1.2 动态 IP 带来的三个真实麻烦

先说为什么非得固定，而不是“每次 ip a 看一眼就行”。第一个麻烦是远程连接不稳定。你配好 SSH 之后，用 MobaXterm 或者 VS Code Remote 连上去写代码，虚拟机一重启 IP 一变，连接全部断开，工具栏里的会话得重新建。如果是用 Ansible、脚本批量管理好几台机器，那更崩溃，配置里的地址全成了摆设。第二个麻烦是服务绑定出问题。有些中间件启动时会读取本机 IP 写进配置文件或者注册中心，IP 一变，服务之间的调用直接 404。第三个麻烦是端口转发失效。NAT 模式下想让宿主机固定访问虚拟机上的某个服务，得在 VMware 里做端口转发，而端口转发必须指向一个固定的虚拟机 IP，IP 变了你得重新配。

我自己踩过最狠的一次，是在一台虚拟机上跑 MinIO 做对象存储测试，本地应用连的是 192.168.x.130。结果某天宿主机断电重启，虚拟机的 IP 变成 131，应用报了一下午的连接超时，我愣是排查了 API 网关、防火墙、路由，最后才发现是 IP 变了。从那以后，凡是生命周期超过一天的虚拟机，我第一件事就是固定 IP。这个教训值好几杯咖啡。

1.3 静态 IP 方案选型：为什么优先 NAT 而不是桥接

固定 IP 其实有两条路：NAT 模式和桥接（Bridged）模式。很多人一听说要静态 IP，第一反应是改桥接，觉得“桥接就是跟真机一样，配起来更直观”。我不否认桥接有它的场景，但在本地开发和测试环境里，我更推荐 NAT 打底。原因是桥接会让虚拟机和宿主机处于同一个局域网，占用公司或家里路由器的 DHCP 地址，IP 段还受路由器管控，换个网络环境（比如从公司带回家）IP 又得重配。NAT 则完全自成一个封闭内网，跟外部网络解耦，无论换到哪个 Wi-Fi，你那套 192.168.x.x 的规划都不受影响，稳定得让人安心。

当然桥接也不是没用武之地。如果虚拟机要作为局域网内的服务节点，被同事的电脑、手机直接访问，桥接确实更方便，配合路由器里的静态 DHCP 绑定也能固定下来。但综合易用性和隔离性，我的建议是：本地开发、学习、测试，一律 NAT 加静态 IP；只有确实需要被局域网其他设备访问时，才考虑桥接。这篇文章聚焦 NAT，这也是搜索量最大、问题最多的场景。

2. 动手前必须搞清楚的几个网络概念

配置之前，我想先把几个概念理清楚，因为你会发现那些网上的教程之所以互相矛盾，根本原因就是没讲清楚这些参数的来源。有人写 192.168.10.0，有人写 192.168.100.0，有人写 192.168.0.0，你不知道该信谁。其实答案只有一个：去你的 VMware 虚拟网络编辑器里看。每个人机器上的 VMnet8 子网都是安装时随机或者自行设定的，没有统一标准。所以与其抄别人的地址，不如学会看懂自己机器上的参数。

2.1 VMware 虚拟网络的三层结构：VMnet、DHCP、NAT 设备

打开 VMware Workstation 的“编辑”→“虚拟网络编辑器”，勾选右下角的“更改设置”拿到管理员权限，你就能看到 VMnet0、VMnet1、VMnet8 等等。VMnet0 是桥接用的，VMnet1 是仅主机模式（Host-only），VMnet8 就是我们 NAT 模式对应的网络。选中 VMnet8，你会看到三块关键信息：子网 IP（比如 192.168.159.0）、子网掩码（一般是 255.255.255.0，也就是 /24）、以及下面 NAT 设置和 DHCP 设置里的具体参数。这三块拼起来，就是你的静态 IP 配置的全部素材。

NAT 设置里有一个“网关 IP”，这就是你要填在 netplan 里的 gateway 地址，通常是子网的第二个可用地址，比如 192.168.159.2。DHCP 设置里有“起始 IP 地址”和“结束 IP 地址”，比如 192.168.159.128 到 192.168.159.254，这一段是 VMware 自动分配的池子。你要选一个不在 DHCP 池里、也不等于网关、也不等于广播地址的地址，比如 192.168.159.10，把它写死给虚拟机用。这样就避免了跟别的虚拟机抢地址，也不会跟 VMware 自己的服务冲突。

2.2 网段规划与地址分配表

有了上面的表，网段规划其实就水到渠成了。假设你的 VMnet8 子网是 192.168.159.0/24，那么 .1 一般是宿主机上 VMnet8 虚拟网卡的地址（VMware 会自动占用），.2 是 NAT 网关，.254 是广播地址，128 之后是 DHCP 池。那么在 3 到 127 之间，就是我们可以自由发挥的静态地址区间。如果你只固定一台机器，随便挑个 .10 就行；如果要固定好几台，建议做个简单的规划表，比如 .11 给开发环境、.12 给测试数据库、.13 给 Jenkins，心里有数，后期维护不头大。

这里补一个经常被忽略的细节：VMware 的 DHCP 池范围是可以在编辑器里改的。如果你觉得默认给的池子太宽，想留更多空间给静态地址，完全可以把它改小，比如改成 192.168.159.200 到 254。改完之后 DHCP 和静态地址互不干扰，更清爽。我自己习惯把池子改到 200 以后，前面 3 到 199 全留给静态规划，这样命名空间一下子宽敞了。

2.3 Ubuntu 20.04 的网络管理工具：netplan 与 NetworkManager

为什么单独讲工具？因为 ubuntu 20.04 的网络配置跟 centos 7 完全不是一套东西，很多从 centos7.9 配置静态 IP 教程过来的朋友，一上来就找/etc/sysconfig/network-scripts/ifcfg-eth0，结果发现根本没有这个目录。ubuntu 20.04 默认用的是netplan，它是一个基于 YAML 的前端工具，负责读取/etc/netplan/下的配置文件，然后翻译成后端渲染器的实际配置。桌面版 ubuntu 20.04 默认渲染器是 NetworkManager，服务器版是 systemd-networkd。这个区别很重要，因为它决定了你改完配置后怎么让它生效。

怎么确认自己用的是哪个渲染器？看/etc/netplan/目录下的文件，里面通常有一行renderer: NetworkManager或者renderer: networkd。桌面版你大概率会看到 NetworkManager。不过好消息是，用 netplan 写静态 IP 的语法对两者是一致的，只是生效和验证的方式略有不同。桌面版如果你更习惯图形界面，其实也可以直接在右上角网络菜单里点设置配静态 IP，但 YAML 方式更通用、更适合脚本化，也是我推荐的方式，服务器和桌面通吃。

提示：动手改 netplan 之前，先执行sudo cp /etc/netplan/xxx.yaml /etc/netplan/xxx.yaml.bak备份一下，改坏了能快速还原，这一步花不了三秒，救过我不下五次。

3. 从零开始的完整配置流程

概念理顺了，接下来就是纯实操。我按真实操作顺序走一遍：先在 VMware 里把参数抄下来，然后确认网卡名字，接着写 netplan 配置，最后应用并验证。整个过程十分钟以内能搞定，但每一步都别跳，尤其是抄参数和确认网卡名这两步，跳过必踩坑。

3.1 在 VMware 里确认并记录 NAT 网络参数

打开 VMware Workstation，菜单栏“编辑”→“虚拟网络编辑器”，点“更改设置”授权。选中 VMnet8（NAT 模式），记下三样东西：子网 IP（例如 192.168.159.0）、子网掩码（255.255.255.0）、以及点开“NAT 设置”看到的网关 IP（例如 192.168.159.2）。然后再点开“DHCP 设置”，看看起始和结束地址，比如 192.168.159.128 到 192.168.159.254。把这四个数字记在备忘录里，后面写配置全靠它们。

这一步有个坑要提醒：有些人看到 VMnet8 的“将主机虚拟适配器连接到此网络”没勾，导致宿主机没有 VMnet8 网卡，网关也连不通。正常情况下这个选项应该是勾选的，如果你发现没勾，勾上并点应用，Windows 会重新创建这块虚拟网卡。另外，如果你同时装了 Docker Desktop 或者其他虚拟化软件，可能会出现网段冲突，表现为虚拟机网络时通时断，这种时候换个不冲突的网段（比如把 VMnet8 改成 172.16.x.0）能解决大部分玄学问题。

3.2 编辑 VMware 的 DHCP 设置（可选但推荐）

前面说过，把 DHCP 池改小能让静态地址规划更舒服。操作很简单：在虚拟网络编辑器选中 VMnet8，点“DHCP 设置”，把起始 IP 改成 192.168.159.200，结束保持 254，确定应用。这样 3 到 199 就彻底解放了。这一步不是必须的，但做了之后你会少很多“明明配了静态 IP 偶尔还是会冲突”的诡异问题。尤其是虚拟机克隆场景，克隆出来的机器往往带着原来的 DHCP 痕迹，池子小一点能减少撞车概率。

需要说明的是，改 DHCP 池不会影响已经运行中的虚拟机，但对新开机的机器生效。如果你是在生产环境做类似操作，最好选在业务低峰期，避免正在做 DHCP 续约的机器短暂抖动。个人环境就随意了，改完直接下一步。

3.3 编写 netplan 配置文件

现在进虚拟机。先用ip a或者ip link看一眼网卡名字。ubuntu 20.04 在 VMware 里，网卡名通常是ens33、ens160这种可预测命名，也可能是老式的eth0。注意别认错，VMware 虚拟机一般只有一块业务网卡，名字记下来。然后看看/etc/netplan/下现有的配置文件长啥样：

ls /etc/netplan/ # 常见输出：01-network-manager-all.yaml 或 00-installer-config.yaml

打开它看一眼，通常是 DHCP 的配置。我们要么改它，要么新建一个。我更推荐直接改现有的那个文件，比如sudo nano /etc/netplan/01-network-manager-all.yaml，把内容替换成下面这样。注意缩进必须用空格，两个空格一级，千万别用 Tab，YAML 对 Tab 是零容忍的。

network: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: no addresses: - 192.168.159.10/24 gateway4: 192.168.159.2 nameservers: addresses: - 223.5.5.5 - 114.114.114.114

逐行解释一下。renderer填什么取决于你 3.3 开头看到的原文件里是什么，原来是 NetworkManager 就保持一致，别乱改，改错了可能导致网络管理服务打架。ethernets下面是你的网卡名，填ens33。dhcp4: no表示关掉 IPv4 自动获取，这是静态 IP 的前提。addresses填你选好的静态地址，注意带上/24掩码，光写 IP 不写掩码会报错。gateway4填网关。nameservers填 DNS，我给了国内常用的两个公共 DNS，你可以换成公司内网 DNS。

注意：从较新的 netplan 版本开始，gateway4被标记为废弃，推荐用routes写法。但 ubuntu 20.04 自带的 netplan 版本对gateway4支持良好，用它是完全没问题的。如果你追求新写法，可以改成：routes: [{to: default, via: 192.168.159.2}]，效果一样。

3.4 应用配置并验证连通性

配置写好后，先别急着 apply，用sudo netplan try更稳。它会先应用配置，然后给你 120 秒确认，如果网络不通，时间一到会自动回滚。这是一个非常贴心的保险机制，避免你 apply 之后 SSH 断了再也连不上，只能删虚拟机重来。确认sudo netplan try显示 “Configuration accepted” 之后，可以再执行一次sudo netplan apply让它永久生效。

sudo netplan try # 确认键盘敲回车接受，或者等待自动回滚 # 应用并验证 sudo netplan apply ip a show ens33 ip route ping -c 4 192.168.159.2 ping -c 4 223.5.5.5 ping -c 4 www.baidu.com

验证要分层次做。ip a看 IP 是不是你写的那个；ip route看默认路由是不是指向网关；然后依次 ping 网关（验证链路）、ping 一个公网 IP（验证 NAT 出网）、ping 一个域名（验证 DNS）。三层都通，说明配置完全正确。如果前两个通、域名不通，那就是 DNS 的问题，回看 nameservers 部分。如果网关都 ping 不通，那问题在链路或网关地址抄错了。这种分层排查法能让你三分钟定位问题，而不是瞎重启。

3.5 配置 DNS 与 hosts 的小技巧

DNS 这块我单独拎出来讲，因为 ubuntu 20.04 的 DNS 解析链路有点绕。它默认装了systemd-resolved，你的/etc/resolv.conf往往是一个指向/run/systemd/resolve/stub-resolv.conf的软链接，直接改它没用，重启就丢。正确做法就是在 netplan 里写nameservers，让 netplan 把 DNS 推给 systemd-resolved。想确认当前生效的 DNS，用resolvectl status或者systemd-resolve --status，看那个 “DNS Servers” 一行是不是你配的。

另一个提升开发效率的小技巧是配 hosts。如果你经常用主机名访问虚拟机上的服务，比如dev.local，可以在虚拟机里也配一份/etc/hosts，把192.168.159.10 dev.local写进去。这样本机解析走 hosts，不依赖 DNS 服务器，响应更快。反过来，如果你想让宿主机也能用主机名访问虚拟机，那就去改宿主机的 hosts 文件，指向这个静态 IP，配合后面要讲的端口转发，体验非常丝滑。

4. 配置后经常翻车的几个地方与排查手法

配置本身真的不难，难的是那些“配完之后出问题”的场景。这一节我按我遇到过的高频故障来组织，每一个都给出排查思路和解决办法。这些都是网上教程很少展开、但实战里几乎必遇的坑。

4.1 重启后配置消失？netplan 文件权限与 YAML 缩进

“ubuntu 配置静态 IP 后重启配置没有了”是搜索频率极高的问题，我遇到过好几次，原因基本锁定在三个点上。第一，YAML 缩进错误。用 Tab 缩进、冒号后面没空格、层级对不齐，都会让 netplan 解析失败，但有时它不报错，直接忽略你的配置回退到别的来源，表现就是重启后 IP 变回去了。解决办法是用sudo netplan generate或者sudo netplan try检查语法，它会明确指出哪一行有问题。第二个原因是存在多个 netplan 配置文件冲突。如果你既改了 01 又新建了 99，两个文件描述同一块网卡，行为就很不可预测。原则是保持只有一个文件描述你的业务网卡。

第三个原因是文件权限。netplan 出于安全考虑会拒绝权限过松的配置文件，尤其是/etc/netplan/*.yaml如果被设成了 777 这种，它会警告甚至不加载。正确权限是 600 或 644，文件属主是 root。执行sudo chmod 600 /etc/netplan/xxx.yaml修一下就行。还有一个隐蔽情况：桌面版 NetworkManager 会接管网卡，如果你在图形界面里也手动设过静态 IP，可能跟 netplan 打架，这种时候去图形界面的网络设置里把它恢复成自动（DHCP），交给 netplan 管。

4.2 有 IP 但上不了网：网关、NAT 服务与转发

另一种典型症状是ip a能看到你要的静态 IP，但 ping 网关通、ping 外网不通。这基本是 NAT 出网环节的问题。先确认网关地址是不是抄对了——很多人把子网 IP 当成网关，写成 192.168.159.0，那是网络号不是网关，肯定不通。网关应该是 .2。其次检查 VMware 的 NAT 服务是否正常运行，Windows 下可以在服务管理器里找 VMware NAT Service 和 VMware DHCP Service，确保它们在运行状态。这两个服务挂了，NAT 直接失效。

再有一种情况是宿主机自身的网络出问题了。因为 NAT 是靠宿主机转发出去的，如果宿主机本身没联网，虚拟机自然也出不去。还有一种容易被忽略的：宿主机装了某些安全软件或者系统防火墙，拦截了 VMnet8 的转发流量。这种情况可以在宿主机上临时关闭防火墙测试，如果通了，说明是防火墙策略问题，需要放行 VMware 的相关进程。我给的建议是，排查时按“虚拟机内 → 网关 → 宿主机 → 外网”的顺序一层层验证，别一上来就怀疑最复杂的东西。

4.3 宿主机访问虚拟机、SSH 连接异常

NAT 模式下宿主机访问虚拟机相对简单，因为宿主机和虚拟机在同一个 VMnet8 网络上，直接用虚拟机静态 IP 就能 ping 通、SSH 上去。如果连不上，先看虚拟机里的防火墙。ubuntu 20.04 默认没装 ufw 的启用规则，但如果你启用了，得放行 22 端口：sudo ufw allow 22。其次确认 ssh 服务装了没：sudo apt install openssh-server并sudo systemctl enable --now ssh。

如果你需要从局域网其他机器访问这个虚拟机，就得用端口转发。在虚拟网络编辑器里选 VMnet8，点“NAT 设置”→“添加”，把宿主机的某个端口（比如 2222）映射到虚拟机的 192.168.159.10:22。之后局域网内其他机器用ssh -p 2222 宿主机IP就能连进来。这个功能很好用，配置也不算复杂，代价是端口冲突要自己规划好。我一般预留 2200 段专门给虚拟机的 SSH 转发，避免跟宿主机上的服务撞端口。

4.4 常见问题速查表

把高频问题整理成一张表，遇到问题先查表，能省不少时间。

5. 进阶玩法与长期维护

配置只是起点，怎么让这套静态 IP 方案长期稳定、易维护，才是真正体现经验的地方。这一节分享几个我常用的进阶技巧。

5.1 用 VMware 的 DHCP 保留代替手工写死

如果你不想动虚拟机内部的配置，其实还有一条路子：在 VMware 的 DHCP 设置里做“MAC 地址到 IP 的绑定”。选中 VMnet8，点 DHCP 设置，在列表里添加一条，把虚拟机的 MAC 地址绑定到一个固定的 IP。这样虚拟机继续用 DHCP，但每次拿到的都是同一个地址。好处是虚拟机内部零改动，坏处是依赖 DHCP 服务，且一旦 MAC 变化（比如克隆或者重建网卡）绑定就失效。我的做法是两者结合：正式环境用 netplan 写死，临时环境用 DHCP 保留，各取所需。

5.2 多台虚拟机批量固定 IP 的思路

当你手上有十几台虚拟机的时候，手工一台台改就是灾难。这时候思路是模板化 + 脚本化。先做一台“黄金镜像”，配好静态 IP 框架，然后把地址部分抽出来做成变量。克隆出新的虚拟机后，用一段小脚本自动改网卡名对应的 YAML 地址、改主机名、重启网络。伪代码大概长这样：

#!/bin/bash # 用法：./set-ip.sh 10 newhostname IP_SUFFIX=$1 HOSTNAME_NEW=$2 cat > /etc/netplan/01-netcfg.yaml <<EOF network: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: no addresses: - 192.168.159.${IP_SUFFIX}/24 gateway4: 192.168.159.2 nameservers: addresses: [223.5.5.5, 114.114.114.114] EOF chmod 600 /etc/netplan/01-netcfg.yaml hostnamectl set-hostname ${HOSTNAME_NEW} netplan apply echo "已设置 IP: 192.168.159.${IP_SUFFIX}, 主机名: ${HOSTNAME_NEW}"

这个脚本的思路是把“变的部分”（IP 尾号、主机名）参数化，不变的框架固化。配合前面的地址规划表，克隆完跑一下脚本，新机器就上线了。注意克隆之后 MAC 地址和 machine-id 会重复，建议先清理一下再配 IP，避免各种诡异问题。

5.3 快照、克隆与 IP 冲突

最后说一个特别容易被忽略的坑：克隆虚拟机导致的 IP 冲突。当你用 VMware 克隆一台已经配好静态 IP 的机器时，克隆出来的机器会带着原机器的静态 IP，两台机器同 IP，网络直接乱套，表现为时通时断、随机丢包。解决办法很简单，克隆之前把源机器的网卡配置清一下，或者克隆之后立刻改 IP 再启动网络。另外一个好习惯是，每次做完重要变更（比如刚配好静态 IP）就打一个快照，起个名字叫“静态IP已配置-20240101”之类，出问题一键回滚。我用快照救回过好几次被自己改崩的环境，成本几乎为零，收益巨大。

还有一个小细节：VMware 克隆时如果选择“创建完整克隆”，会重新生成 MAC 地址，但 machine-id 和 netplan 配置里的 IP 不会变，所以 IP 冲突和主机名冲突都要手动处理。养成“克隆后先断网、改完配置再联网”的习惯，能避免很多莫名其妙的问题。

6. 一些实操心得与备份建议

写了这么多技术细节，最后分享点我个人的使用体会。netplan 这套东西虽然一开始看着别扭，但它有个巨大的好处：配置文件是声明式的，写得清清楚楚，不像以前 centos 那种改一堆 ifcfg 文件还得记各种参数。只要你把网段、网关、DNS 这三个源头参数搞清楚，剩下就是填空。我现在配一台新机器基本五分钟搞定，靠的就是这套固定流程：抄参数、看网卡名、套模板、netplan try、分层验证。

另外强烈建议大家养成两个习惯。第一，改网络配置前一定备份原文件，我在 3.3 节里提到的备份命令不是走过场，是真的能救命。第二，配置完成后把关键参数（网段、网关、静态 IP、DNS）记到一个文档里，哪怕就是一个文本文件放在桌面。虚拟机多了以后，没有这张“账本”，你自己都会忘哪台机器用了哪个 IP。这些年在网络配置上踩的坑，一大半都不是技术难，而是信息没记录、参数抄错、状态没同步这类低级的细节问题。

对了，如果你是在公司环境里做这套配置，动手前最好跟网络管理员对一下网段规划，避免跟公司内网冲突。虽然 NAT 是封闭的，但万一你手贱改成桥接或者网段撞了，还是会影响别人。安全第一，稳妥配置，这才是长期运维的正道。