NAT模式下VMware的虚拟机DNS解析失败的问题解决

当我在虚拟机上下载失败后，尝试ping baidu.com

发现域名解析有问题!!

问题症状:

bash 复制代码

E: 无法下载 https://repo.huaweicloud.com/ubuntu/pool/main/libe/liberror-perl/liberror-perl_0.17029-1_all.deb  暂时不能解析域名"repo.huaweicloud.com"
E: 无法下载 https://repo.huaweicloud.com/ubuntu/pool/main/g/git/git-man_2.34.1-1ubuntu1.15_all.deb  暂时不能解析域名"repo.huaweicloud.com"
E: 无法下载 https://repo.huaweicloud.com/ubuntu/pool/main/g/git/git_2.34.1-1ubuntu1.15_amd64.deb  暂时不能解析域名"repo.huaweicloud.com"
E: 有几个软件包无法下载，要不运行 apt-get update 或者加上 --fix-missing 的选项再试试？

delusion@delusion-virtual-machine:~/projects$ ping baidu.com
ping: baidu.com: 域名解析出现暂时性错误

(我的虚拟机和主机windows是nat桥接模式，我的主机的DNS是正常的)

先查看当前配置

bash 复制代码

cat /etc/resolv.conf

结果:

bash 复制代码

delusion@delusion-virtual-machine:~/projects$ cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .
delusion@delusion-virtual-machine:~/projects$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens33)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

我当前的/etc/resolv.conf显示其为systemd-resolved的软链接，127.0.0.53是本地DNS存根解析器（并非真正的上游DNS服务器），真正的外网DNS配置由systemd-resolved服务管理，这也是你直接修改/etc/resolv.conf无效、且NAT模式下仍解析失败的核心原因。下面按步骤排查修复：

第一步：先查看当前上游DNS服务器状态（定位问题根源）

首先执行命令查看systemd-resolved的实际上游DNS配置，确认是否未获取到有效外网DNS：

bash 复制代码

resolvectl status

关键输出解读

找到带有Uplink标识的网络接口（通常是ens33/eth0等NAT对应的网卡）
查看该接口下的DNS Servers字段：如果显示为空、或为无效地址（非公网DNS），则说明上游DNS未正确配置，导致解析失败

第二步：临时配置上游DNS（快速验证有效性）

先通过resolvectl命令临时设置公网DNS，无需修改配置文件，快速验证是否能解决解析问题：

bash 复制代码

# 替换ens33为你的实际网卡名（可从resolvectl status输出中找到，如eth0）
sudo resolvectl dns ens33 223.5.5.5 223.6.6.6 8.8.8.8
# 刷新DNS缓存
sudo resolvectl flush-caches

立即测试解析效果

bash 复制代码

# 测试百度域名解析
ping -c 4 baidu.com
# 或用nslookup验证
nslookup baidu.com

如果此时能正常解析并ping通，说明DNS配置本身无问题，只需将该配置永久化即可；若仍失败，继续下一步排查。

第三步：永久配置DNS（解决重启后失效问题）

通过修改systemd-resolved的主配置文件，实现DNS永久生效，无需担心被系统覆盖：

编辑systemd-resolved配置文件
bash 复制代码
```
sudo nano /etc/systemd/resolved.conf
```

取消[Resolve]段落下DNS注释，并添加公网DNS地址（如下配置）

ini 复制代码

[Resolve]
DNS=223.5.5.5 223.6.6.6 8.8.8.8  # 阿里+Google DNS，国内优先阿里
# DNSOverTLS=no
# MulticastDNS=no
# DNSSEC=no
# Cache=no-negative
# DNSStubListener=yes
# ReadEtcHosts=yes

保存退出（nano编辑器按Ctrl+O保存，Ctrl+X退出）
重启systemd-resolved服务使配置生效
bash 复制代码
```
sudo systemctl restart systemd-resolved
```

验证永久配置是否生效

bash 复制代码

# 查看上游DNS是否已更新
resolvectl status
# 再次测试域名解析
ping baidu.com

第四步：排查VMware NAT模式的DHCP/DNS配置（关键补充）

若上述步骤仍无效，说明VMware的NAT网络本身未正确分配DNS，需检查主机端VMware的虚拟网络配置：

关闭虚拟机（必须完全关机，不可挂起）
在主机上打开VMware Workstation → 点击顶部菜单栏编辑 → 虚拟网络编辑器
选择VMnet8（NAT模式对应的虚拟网络），点击更改设置（需管理员权限）
选中VMnet8，确保勾选使用本地DHCP服务将IP地址分配给虚拟机
点击NAT设置，在弹出的窗口中查看DNS服务器：
- 建议设置为公共DNS（如223.5.5.5或8.8.8.8），避免使用默认的主机DNS（可能存在转发问题）
- 点击确定保存NAT配置
点击DHCP设置，查看DHCP地址池是否正常（无需修改，确认未禁用即可），点击确定
点击应用→确定关闭虚拟网络编辑器

启动虚拟机，重新获取DHCP配置

bash 复制代码

# 重新获取IP和DNS（替换ens33为你的网卡名）
sudo dhclient -r ens33  # 释放旧配置
sudo dhclient ens33     # 获取新配置

再次用resolvectl status和ping baidu.com验证解析效果

第五步：额外排查（确保网络服务正常）

若以上步骤均无效，检查虚拟机网络服务是否正常运行：

bash 复制代码

# 检查NetworkManager服务（负责网络连接管理）
sudo systemctl status NetworkManager
# 若未运行，启动并设置开机自启
sudo systemctl start NetworkManager
sudo systemctl enable NetworkManager

# 检查网卡是否获取到有效IP（非169.254.x.x网段，该网段为DHCP获取失败）
ip addr

若网卡IP为169.254.x.x，说明DHCP获取失败，可重启VMware的虚拟网络服务（主机端：服务中重启VMware DHCP Service和VMware NAT Service）

总结

我看到的127.0.0.53是本地DNS存根，真正生效的是systemd-resolved的上游DNS配置；
优先通过resolvectl status查看上游DNS状态，用resolvectl dns临时验证DNS有效性；
永久配置需修改/etc/systemd/resolved.conf并重启对应服务；
若仍失效，排查主机端VMware VMnet8的NAT/DHCP DNS配置，确保DHCP能分配有效公网DNS。