VMware NAT 模式下 Ubuntu22 DNS 解析失败问题排查与彻底解决VMware NAT 模式下 Ubun

VMware NAT 模式下 Ubuntu22 DNS 解析失败问题排查与彻底解决

在日常开发中，我们常通过 VMware 搭建 Ubuntu 虚拟机进行开发工作，而 NAT 模式因无需额外配置 IP、直接借助宿主机网络访问外网成为主流选择。但近期在 Ubuntu22 虚拟机中遇到了典型问题：能 ping 通公网 IP 和 VMware NAT 网关，却无法解析域名，执行ping www.baidu.com时报错Temporary failure in name resolution，导致无法拉取 Git 代码、访问外网域名。本文将结合实际排查过程，梳理问题根源、完整解决步骤，并总结避坑要点，为同类场景提供可直接复用的解决方案。

一、问题现象与初步定位

1. 核心问题现象

执行ping 180.101.49.11（百度公网 IP）、ping 192.168.234.2（VMware NAT 网关）均能正常响应，0 丢包；
执行ping www.baidu.com、ping github.com等域名请求，提示Temporary failure in name resolution，域名解析完全失效；
虚拟机网卡状态正常（ip a显示 ens33 为 UP 状态），已获取动态 IP（192.168.234.128）。

2. 初步定位结论

从现象可直接判断：网络链路层面无任何故障（虚拟机↔NAT 网关↔公网 IP 连通正常），问题根源聚焦在Ubuntu22 系统的 DNS 域名解析服务配置异常，系统无法将域名转换为对应的公网 IP。

二、深层问题根源分析

结合 Ubuntu22 系统特性和 VMware NAT 模式环境，梳理出解析失败的两大核心原因：

systemd-resolved 服务未配置公网上游 DNS：Ubuntu18.04 + 默认依赖systemd-resolved作为核心 DNS 解析服务，系统默认的/etc/resolv.conf指向本地存根解析器127.0.0.53（该地址为systemd-resolved的本地代理），但未为该服务配置任何公网上游 DNS 服务器，导致解析器无有效数据源；
resolv.conf 软链接关联异常：/etc/resolv.conf作为系统 DNS 配置的入口文件，其软链接未正确关联到systemd-resolved的动态有效配置，导致系统 DNS 请求无法被正常解析服务处理；
VMware NAT 模式的环境依赖：NAT 模式下虚拟机的网络转发完全依赖宿主机的 VMware 虚拟网络服务，若宿主机 DHCP/NAT 服务未运行，会间接导致虚拟机 DNS 配置无法正常获取，但本次排查中已验证网关连通正常，排除该因素。

三、针对性解决步骤（VMware NAT 模式专属）

解决思路围绕配置解析服务公网 DNS→重建软链接打通请求链路→验证解析效果展开，所有操作均为系统级永久配置，重启虚拟机 / 宿主机、重启网络后配置不丢失，按顺序执行即可。

前提准备：验证 VMware NAT 网关连通性

先确认虚拟机与 NAT 网关的连通性，这是后续所有操作的基础，执行以下命令（替换为你的 NAT 网关 IP，通常为虚拟机 IP 同网段最后一位为 2）：

bash

运行

# 测试NAT网关连通性，需0丢包正常响应
ping 192.168.234.2 -c 3

若网关无法 ping 通，需在 Windows 宿主机执行：打开services.msc，重启VMware DHCP Service和VMware NAT Service；或在 VMware 中打开「虚拟网络编辑器」，选择 VMnet8 点击「还原默认设置」。

步骤 1：配置 systemd-resolved 公网上游 DNS

编辑systemd-resolved的核心配置文件，添加国内稳定的公网 DNS 服务器（阿里云 / 腾讯，解析速度快、适配国内网络）：

bash

运行

# 编辑resolved主配置文件，需sudo权限
sudo nano /etc/systemd/resolved.conf

将文件中[Resolve]段下的DNS行取消注释（删掉 #），添加以下配置（保留其他行默认注释）：

ini

[Resolve]
DNS=223.5.5.5 223.6.6.6 119.29.29.29  # 阿里云+腾讯公网DNS，空格分隔多地址
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#DNSOverTLS=no
#Cache=no-negative
#DNSStubListener=yes
#ReadEtcHosts=yes

保存并退出编辑器（nano 操作：Ctrl+O保存→回车确认→Ctrl+X退出），随后重启解析服务并设置开机自启：

bash

运行

# 重启服务加载新配置
sudo systemctl restart systemd-resolved
# 设置开机自启，避免后续重启失效
sudo systemctl enable systemd-resolved

步骤 2：重建 resolv.conf 软链接（关键！）

删除系统原有可能错乱的软链接，重新创建指向systemd-resolved动态有效配置的软链接，打通系统 DNS 请求与解析服务的链路：

bash

运行

# 删除原有软链接
sudo rm -f /etc/resolv.conf
# 重新创建软链接，指向resolved的动态配置文件
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

步骤 3：验证 DNS 解析与网络连通性

执行以下命令，依次验证域名解析、外网连通性，所有命令均需正常响应无报错：

bash

运行

# 测试百度域名解析与连通（3次ping，0丢包即为正常）
ping www.baidu.com -c 3
# 测试Git仓库域名（开发拉取代码必备）
ping github.com -c 2
# 精准测试DNS解析服务功能
resolvectl query www.baidu.com

正常验证结果参考

ping www.baidu.com：显示解析到的 IP（如 153.3.238.127），输出64 bytes from xxx: icmp_seq=1 ttl=128 time=xx ms，0 丢包；
resolvectl query www.baidu.com：30ms 左右快速解析出百度多个 IPv4/IPv6 地址，标注Information acquired via protocol DNS。

步骤 4：测试核心开发需求 —— 拉取 Git 代码

网络与解析恢复后，直接在项目目录执行 Git 拉取命令，验证最终开发场景可用性：

bash

运行

# 进入项目目录
cd ~/project/wht-jf/wht-api
# 拉取远程最新代码
git pull

若能正常拉取代码，说明 VMware NAT 模式下 Ubuntu22 的网络与 DNS 解析问题已彻底解决。

四、关键避坑要点（VMware+Ubuntu22 专属）

不要直接修改 /etc/resolv.conf：该文件是动态软链接文件，手动修改会被systemd-resolved服务实时覆盖，所有 DNS 配置需通过修改/etc/systemd/resolved.conf实现；
网络模式选择：NAT 模式不要与「仅主机模式」混淆，仅主机模式仅支持虚拟机与宿主机互通，无法访问外网；
宿主机虚拟服务必须运行：Windows 宿主机需确保VMware DHCP Service和VMware NAT Service始终处于运行状态，否则虚拟机无法获取网关和 IP；
防火墙拦截问题：Windows 宿主机防火墙默认可能拦截 VMware 虚拟网络转发，测试阶段可临时关闭防火墙，问题解决后可重新开启；
Netplan 配置无需额外修改：本次问题为解析服务配置异常，非网络参数配置问题，无需修改 Netplan 的网卡和网关配置，保持 DHCP 自动获取即可。

五、总结

本次问题是 VMware NAT 模式下 Ubuntu22 系统的典型 DNS 解析故障，核心矛盾并非网络链路不通，而是系统解析服务的配置缺失与链路关联异常。通过「配置公网 DNS 数据源→重建软链接打通请求链路」的两步核心操作，即可从根源解决问题，且所有配置均为系统级永久配置，满足长期开发使用需求。

该解决方案的核心逻辑可复用至所有 Ubuntu18.04 + 版本的 DNS 解析故障排查，核心要点为：

先通过 ping 公网 IP 和网关定位问题层面（链路 / 解析）；
基于systemd-resolved服务进行 DNS 配置，这是 Ubuntu 新版系统的标准方式；
确保/etc/resolv.conf软链接正确关联到解析服务的有效配置；
结合虚拟化环境特性，验证宿主机的虚拟网络服务状态。

通过以上步骤，可快速、高效解决 VMware+Ubuntu 开发环境中的 DNS 解析问题，保障日常开发的网络可用性。