VMware中Ubuntu网络配置：netplan+systemd-networkd实战指南

简介：本资源是一份面向Linux虚拟化初学者与运维新手的VMware环境下Ubuntu网络配置实操指南，聚焦NAT模式联网这一高频痛点问题。文档详细拆解了从VMware虚拟网络设置、vmnet8信息获取，到Ubuntu系统内IPv4手动配置（含IP段192.168.145.X/24、网关与DNS设定）、Windows主机服务启用（VMware NAT Service与DHCP Service）的完整闭环流程，附关键界面路径说明与参数取值依据，具备强可复现性。资源为单文件Word文档（.doc格式），体积精简仅63KB，内容紧凑无冗余，适合作为速查笔记或实验预习材料。目前已有1014人学习下载，适合在VMware 7.1.0+Ubuntu 10.10典型旧版本环境中快速搭建连通网络，亦可迁移参考至其他NAT场景。

1. VMware里Ubuntu网络连接设置：为什么刚装好的系统连不上网、ping不通主机、甚至ifconfig都看不到eth0？

你刚在VMware Workstation里装完Ubuntu 22.04或24.04，桌面一出来就点开浏览器——空白页；ping 8.8.8.8报connect: Network is unreachable；ip a一看，只有lo回环接口，ens33或ens32根本不显示；更玄的是，主机（Windows/macOS）能正常上网，虚拟机却像被掐了网线。这不是Ubuntu装错了，也不是ISO坏了，而是VMware默认的网络模式与Ubuntu内核驱动、netplan配置、systemd-networkd服务三者没对齐。这个问题高频出现在 VMware Workstation Pro 17+、Player 17、Fusion 13+ 环境下，尤其 Ubuntu 22.04 LTS 及之后版本全面启用 netplan + systemd-networkd 后，传统/etc/network/interfaces写法彻底失效。它不挑人——新手会卡在“连不上”三字上反复重装，老手也常因忽略vmxnet3驱动加载或 DHCP 超时阈值而浪费两小时查日志。本文只讲一件事：用最小干预、最稳路径，在 VMware 里让 Ubuntu 的网络从“黑匣子”变成“可诊断、可复现、可回滚”的确定性状态。不讲原理堆砌，不推GUI点点点，每一步命令都带验证逻辑和失败兜底。

2. 确认VMware网络适配器类型与Ubuntu驱动匹配：别让网卡在内核里“隐身”

VMware虚拟机的网络能力，本质是宿主机通过虚拟化层向Guest OS暴露的一块“假网卡”。这块卡的型号（e1000e/vmxnet3/bridged/NAT）直接决定Ubuntu能否识别、加载驱动、获取IP。很多人跳过这步直接改配置，结果ip link里压根没设备名，后续所有操作都是空中楼阁。

2.1 查看当前VMware虚拟网卡型号（宿主机侧）

关闭Ubuntu虚拟机（不是挂起），在VMware Workstation界面右键虚拟机 →Settings → Hardware → Network Adapter。重点看两项：

• Network connection：选中NAT mode（最常用，适合上网+SSH访问）、Bridged mode（需宿主机同网段，适合当独立设备）、Host-only mode（仅宿主互通，无外网）；
• Network adapter type：下拉菜单里必须选VMXNET3（推荐）或E1000E（兼容性更好）。绝对不要选E1000（老旧，Ubuntu 22.04+ 默认不加载其驱动）或Custom（除非你明确知道物理网卡绑定规则）。

提示：VMXNET3是VMware优化的高性能驱动，支持多队列、TSO/LRO卸载，但依赖open-vm-tools中的vmw_vmci和vmxnet3内核模块；E1000E模拟Intel千兆网卡，驱动内置Linux主线内核，兼容性无敌，但性能略低。新手首次调试建议先用E1000E，排除驱动问题后再切回VMXNET3。

2.2 在Ubuntu中验证网卡是否被内核识别

启动Ubuntu，打开终端，执行：

lspci | grep -i ethernet

正常输出应类似：

02:01.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)

或（若选E1000E）：

02:01.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)

如果没有任何输出，说明VMware没把网卡暴露给Guest，回到第2.1步检查设置并重启虚拟机。

如果输出有设备但ip a不显示对应接口（如ens33），继续查驱动：

lsmod | grep -E "(vmxnet3|e1000e)"

• 对VMXNET3：应看到vmxnet3模块已加载；
• 对E1000E：应看到e1000e模块已加载。

若无输出，手动加载：

# VMXNET3 sudo modprobe vmxnet3 # E1000E sudo modprobe e1000e

然后验证接口是否出现：

ip link show | grep -A1 "state UP\|state DOWN" | grep -E "^[0-9]+:"

此时应看到类似2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP>的行。若仍无，说明内核未启用该驱动——Ubuntu 22.04+ 默认启用，极小概率需检查/etc/default/grub中GRUB_CMDLINE_LINUX是否含vmxnet3.disable=1（罕见，一般不用动）。

2.3 确认网卡命名规则（Predictable Network Interface Names）

Ubuntu 15.04+ 默认启用可预测网卡名（如ens33,enp0s3），而非旧式eth0。名字由PCI插槽位置决定，每次重启不会变，但克隆虚拟机后可能变。查当前实际接口名：

ip -br link | awk '{print $1}'

输出类似：

lo ens33

记下这个名称（后文配置全用它，比如ens33），千万别硬写eth0——这是90%配置失败的第一原因。

3. 用netplan精准控制网络行为：NAT/Bridged模式下的DHCP与静态IP双路径

Ubuntu 17.10起，netplan成为官方网络配置工具，取代了/etc/network/interfaces。它用YAML声明式语法，由systemd-networkd或NetworkManager后端执行。VMware场景下，必须用systemd-networkd后端（轻量、无GUI依赖、启动快），禁用NetworkManager（它会和netplan抢控制权，导致配置不生效）。

3.1 停用NetworkManager，启用systemd-networkd

# 停用NetworkManager（避免冲突） sudo systemctl stop NetworkManager sudo systemctl disable NetworkManager # 启用systemd-networkd sudo systemctl enable systemd-networkd sudo systemctl start systemd-networkd # 验证状态 sudo systemctl status systemd-networkd | grep "active (running)"

注意：此操作不影响图形界面联网（GNOME/KDE仍可用NetworkManager，但VMware虚拟机通常无GUI或用CLI，我们走纯systemd路径更稳）。若你坚持用GUI，可跳过此步，但后续netplan配置必须指定renderer: NetworkManager，且确保NetworkManager服务运行。

3.2 编写netplan配置文件（/etc/netplan/01-network-manager-all.yaml）

进入/etc/netplan/目录，备份原文件（如有）：

sudo cp /etc/netplan/*.yaml /tmp/netplan-backup.yaml 2>/dev/null || echo "no yaml found"

创建新配置（以NAT模式为例，自动获取IP）：

sudo tee /etc/netplan/01-network-manager-all.yaml << 'EOF' # This is the network config written by 'subiquity' network: version: 2 renderer: systemd-networkd ethernets: ens33: # ← 替换为你2.3节查到的实际接口名！ dhcp4: true dhcp6: false # 可选：设置DHCP超时，防卡死 dhcp4-overrides: timeout: 30 EOF

保存后应用：

sudo netplan apply

验证：

# 等10秒，查IP ip -4 addr show ens33 | grep "inet " | awk '{print $2}' # 查路由 ip route | grep "default via" # 测试连通性 ping -c 3 8.8.8.8

若成功，你会看到类似192.168.174.128/24的IP（NAT模式典型段），default via 192.168.174.2，且ping通。

3.3 Bridged模式静态IP配置（需与宿主机同网段）

若选Bridged，需手动设IP（避免DHCP冲突）。假设宿主机WiFi网段是192.168.1.0/24，网关192.168.1.1，给Ubuntu分配192.168.1.100：

sudo tee /etc/netplan/01-network-manager-all.yaml << 'EOF' network: version: 2 renderer: systemd-networkd ethernets: ens33: # ← 替换为你的真实接口名 dhcp4: false addresses: [192.168.1.100/24] gateway4: 192.168.1.1 nameservers: addresses: [8.8.8.8, 114.114.114.114] EOF

再sudo netplan apply。验证：

# IP应为192.168.1.100 ip -4 addr show ens33 | grep "inet " # 路由应指向宿主机网关 ip route | grep "default via 192.168.1.1" # 宿主机ping虚拟机 # Windows: ping 192.168.1.100 # macOS: ping 192.168.1.100

关键参数说明：

• addresses: 必须带子网掩码（/24表示255.255.255.0），不能只写192.168.1.100；
• gateway4: 必须是宿主机在该网段的IP（不是VMware虚拟网卡IP），查宿主机ipconfig（Win）或ifconfig（macOS）；
• nameservers: DNS服务器，避免nslookup google.com失败。

4. VMware Tools（open-vm-tools）深度集成：解决剪贴板共享、时间同步、分辨率自适应三大刚需

很多用户以为“网络通了就万事大吉”，结果发现复制粘贴不了、虚拟机时间越跑越慢、窗口拉伸后显示模糊——这些全是open-vm-tools（VMware官方开源工具集）没装或没启的锅。它不是可选插件，而是VMware虚拟机的基础运行时组件，尤其影响网络稳定性（如DHCP租期续订、host-only网络发现）。

4.1 安装open-vm-tools核心包

Ubuntu仓库已预装open-vm-tools，但常缺桌面集成包。执行：

sudo apt update sudo apt install -y open-vm-tools open-vm-tools-desktop # 若用minimal安装（无GUI），只需： # sudo apt install -y open-vm-tools

验证安装：

dpkg -l | grep open-vm-tools # 应看到 open-vm-tools, open-vm-tools-desktop 两行，状态 ii（installed）

4.2 启用关键systemd服务

open-vm-tools由多个服务组成，必须启用才能生效：

# 时间同步服务（解决虚拟机时间漂移） sudo systemctl enable vmtoolsd sudo systemctl start vmtoolsd # 剪贴板/拖拽服务（需桌面环境） sudo systemctl enable vmtoolsd --now # 分辨率自适应（需安装open-vm-tools-desktop后才有） # GNOME/KDE下自动生效，无需额外操作

验证时间同步：

# 查vmtoolsd是否在同步 sudo vmtoolsd -n vmusr --cmd "info-get guestinfo.toolsVersion" # 输出应为数字（如 12.3.0），非空即正常 # 查时间状态 timedatectl status | grep "System clock synchronized" # 应为 yes

4.3 配置文件微调（解决NAT模式下DNS劫持）

VMware NAT模式会注入自己的DNS（192.168.174.2），有时导致解析慢或失败。可在netplan中强制指定DNS，或修改VMware虚拟网络编辑器：

• 打开VMware →Edit → Virtual Network Editor→ 选VMnet8 (NAT)→NAT Settings→ 记下Gateway IP（如192.168.174.2）；
• 在netplan的nameservers中加入该IP（作为备用）：

  nameservers: addresses: [8.8.8.8, 114.114.114.114, 192.168.174.2]

血泪经验：某次客户环境DNS总超时，查日志发现systemd-resolved在/run/systemd/resolve/stub-resolv.conf里硬编码了127.0.0.53，而open-vm-tools的DNS注入被覆盖。最终方案是sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf强制使用systemd-resolved，再在netplan里设dhcp4-overrides: { use-dns: false}，彻底绕过DHCP DNS。

5. 常见问题排查：5个真实翻车现场与10分钟自救指南

网络配置最怕“试了没用，不知哪错”。以下5个问题，按发生频率排序，每个都附现象→原因→解决三步法，实测有效。

5.1 现象：ip a显示接口DOWN，sudo ip link set ens33 up后立刻DOWN

• 原因：VMware虚拟网卡被禁用（虚拟机设置里取消勾选），或vmxnet3/e1000e驱动未加载，或接口被systemd-networkd锁定。
• 解决：
  1. 关机 → VMware设置 → Network Adapter → 确保Connected和Connect at power on勾选；
  2. 启动后执行sudo modprobe vmxnet3（或e1000e）；
  3. 查systemd-networkd日志：journalctl -u systemd-networkd -n 50 --no-pager | grep ens33，若见Could not set interface ens33 up: Device or resource busy，执行sudo systemctl restart systemd-networkd。

5.2 现象：ping 8.8.8.8通，但ping www.google.com超时

• 原因：DNS解析失败。常见于/etc/resolv.conf被覆盖、systemd-resolved未启用、或VMware NAT DNS不可达。
• 解决：
  1. 查当前DNS：cat /etc/resolv.conf，若指向127.0.0.53，则systemd-resolved在工作；
  2. 测试DNS：nslookup google.com 8.8.8.8，若通 → DNS服务器问题；若不通 → 本地解析链故障；
  3. 临时修复：echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf；
  4. 永久修复：在netplan中明确nameservers，并执行sudo netplan apply。

5.3 现象：Bridged模式下，虚拟机能上网，但宿主机ping不通虚拟机IP

• 原因：宿主机防火墙拦截（Windows Defender Firewall / macOS Firewall），或VMware Bridged模式绑定到错误的物理网卡（如绑到禁用的蓝牙网卡）。
• 解决：
  1. Windows：Windows Defender Firewall → Advanced settings → Inbound Rules → New Rule → Program → C:\Program Files (x86)\VMware\VMware Workstation\vmware-vmx.exe → Allow；
  2. macOS：System Preferences → Security & Privacy → Firewall → Firewall Options → Allow incoming connections for VMware Fusion；
  3. VMware Bridged设置：Virtual Network Editor → VMnet0 → Bridged → Replicate physical network connection state → 下拉选你正在用的网卡（如 Wi-Fi）。

5.4 现象：sudo netplan apply报错Error in network definition: Unknown key dhcp4-overrides

• 原因：netplan版本过低（<0.103）。Ubuntu 20.04默认netplan 0.101，不支持dhcp4-overrides；22.04+ 默认0.104+ 支持。
• 解决：
  1. 查版本：netplan version；
  2. 若 <0.103，删掉dhcp4-overrides块，或升级netplan：

     sudo apt install -y python3-netplan # Ubuntu 20.04可手动编译，但更推荐换用基础DHCP配置

  3. 降级写法（兼容所有版本）：

     ens33: dhcp4: true # 删除 dhcp4-overrides 整块

5.5 现象：克隆虚拟机后，网络完全消失，ip a只有lo

• 原因：克隆导致MAC地址重复，systemd-networkd生成的70-persistent-net.rules（已废弃）或netplan的match规则失效，新网卡被识别为ens34但配置仍指向ens33。
• 解决：
  1. 查新接口名：ip -br link | awk '{print $1}'；
  2. 修改/etc/netplan/01-network-manager-all.yaml中ens33为新名字（如ens34）；
  3. 清理旧网卡残留（可选）：

     sudo rm /etc/systemd/network/10-netplan-*.network 2>/dev/null sudo systemctl restart systemd-networkd

6. 进阶技巧：用systemd-networkd实现网络故障自动恢复与多网卡策略路由

当你的Ubuntu虚拟机需要同时接入NAT（上网）和Host-only（与宿主机通信）两个网络，或遇到DHCP服务器偶尔失联时，静态配置+脚本兜底太糙。systemd-networkd原生支持link-local fallback、多网关优先级、路由表隔离，比写shell脚本可靠十倍。

6.1 双网卡场景：NAT + Host-only 共存配置

假设：

• ens33→ NAT模式（上网，DHCP获取192.168.174.x）
• ens34→ Host-only模式（与宿主机通信，静态IP192.168.18.100/24）

netplan配置如下：

network: version: 2 renderer: systemd-networkd ethernets: ens33: dhcp4: true dhcp4-overrides: route-metric: 100 # 低优先级网关 ens34: addresses: [192.168.18.100/24] routes: - to: 192.168.18.0/24 via: 192.168.18.1 metric: 50 # 高优先级，仅用于该网段 # 禁用默认网关，避免抢路 dhcp4: false

关键点：

• route-metric控制网关优先级：数值越小，优先级越高。ens34不设网关，ens33设metric: 100，确保外网走NAT；
• routes块为ens34单独加一条直连路由，保证192.168.18.0/24网段（宿主机）可达；
• 宿主机Host-only网卡IP需设为192.168.18.1（VMware Virtual Network Editor → VMnet1 → Subnet IP）。

验证：

# 外网 curl -I https://google.com | head -1 # 宿主机（假设其Host-only IP为192.168.18.1） ping -c 3 192.168.18.1 # 查路由表 ip route show table main | grep -E "(default|192.168.18)" # 应见：default via 192.168.174.2 dev ens33 metric 100 # 和：192.168.18.0/24 dev ens34 proto kernel scope link src 192.168.18.100 metric 50

6.2 DHCP失联时自动切静态IP（Link-Local Fallback）

当NAT DHCP服务器宕机，ens33获取不到IP，systemd-networkd可自动启用169.254.0.0/16链路本地地址，保证基础通信。但更实用的是——fallback到预设静态IP：

ens33: dhcp4: true addresses: [192.168.174.200/24] # fallback IP gateway4: 192.168.174.2 # 启用fallback（需systemd >= 246） dhcp4-overrides: use-routes: false

注意：此功能依赖较新systemd，Ubuntu 22.04+ 默认支持。原理是systemd-networkd在DHCP超时后，将addresses中的IP作为静态地址启用。

6.3 一键诊断脚本：把10分钟排查压缩成1条命令

把高频检查打包成脚本，放在~/bin/netdiag：

#!/bin/bash echo "=== 网卡识别 ===" lspci | grep -i ethernet echo -e "\n=== 接口状态 ===" ip -br link echo -e "\n=== IP与路由 ===" ip -4 addr show ip route echo -e "\n=== DNS解析 ===" cat /etc/resolv.conf nslookup google.com 8.8.8.8 2>/dev/null | head -3 echo -e "\n=== VMware Tools ===" systemctl is-active vmtoolsd sudo vmtoolsd -n vmusr --cmd "info-get guestinfo.toolsVersion" 2>/dev/null echo -e "\n=== 日志线索 ===" journalctl -u systemd-networkd -n 20 --no-pager | grep -E "(ens33|error|fail)"

赋予执行权：

mkdir -p ~/bin chmod +x ~/bin/netdiag # 加入PATH（~/.bashrc末尾加：export PATH="$HOME/bin:$PATH"）

以后只要netdiag，所有关键信息一页刷出，比翻10个命令快得多。

我干这行八年，给上百台VMware Ubuntu调过网，结论很朴素：90%的问题不在Ubuntu，而在VMware设置与netplan的耦合点没对齐。记住三个锚点——网卡型号（VMXNET3/E1000E）、接口名（ip -br link）、netplan后端（systemd-networkd）——其他都是变量。每次重装前，先lspci | grep eth确认硬件存在，再ip a看接口名，最后netplan apply，基本零翻车。希望帮到你。

本文还有配套的精品资源，点击获取