------以 DolphinScheduler 部署为实际场景
⸻ 1. 背景说明 1.1 使用场景 • 宿主机：Windows（VMware Workstation）
• 虚拟机系统：Ubuntu Server / Cloud Image
• 目标需求： • 虚拟机可访问外网
• 宿主机 / 其他主机可访问虚拟机内 DolphinScheduler Web 服务
• 涉及网络模式： • 桥接（Bridged） • NAT（最终采用）
⸻ 2. 初始问题描述
2.1 网络异常现象
• 虚拟机中执行 ip a：
• 网卡 ens33 存在
• 但无 IPv4 地址
• 执行 nmcli device status：
ens33 ethernet 未托管• 表现为： • 无法访问外网
• 宿主机无法访问虚拟机服务
• DolphinScheduler 无法对外提供服务
⸻ 3. 排查过程回顾（按时间与逻辑）
⸻ 3.1 桥接模式排查
尝试内容 • VMware 网络模式设置为 桥接
• 为虚拟机配置 DHCP / 静态 IP 遇到问题
• DHCP 不稳定，无法获取 IPv4
• 即使与宿主机同网段，仍无法互通
• 在 Wi-Fi、校园网或公司网络环境下尤其容易失败 结论 桥接模式在真实网络环境中依赖外部网络条件，稳定性不可控，不适合作为优先方案。
⸻ 3.2 NetworkManager 路线排查（关键误区） 排查思路
• 使用 NetworkManager 管理以太网（参考 Rocky / CentOS 经验） 具体尝试
• 修改 netplan，指定 renderer: NetworkManager
• 配置： • 90-force-managed.conf
• 10-ethernet-managed.conf
• 重启 NetworkManager 实际结果
• nmcli device status 始终显示：
ens33 ethernet 未托管根本原因（关键结论） Ubuntu Server / Cloud 镜像中，NetworkManager 默认不管理以太网 这是系统设计行为，而非配置错误。
⸻ 4. 技术路线纠正（关键转折点）
4.1 Ubuntu Server 官方网络架构 Ubuntu Server 的标准网络管理路径为：
netplan
↓
systemd-networkd而不是：
NetworkManager👉 继续强行使用 NetworkManager 管理以太网是一条死路
⸻ 5. 最终解决方案（正确且稳定）
5.1 VMware 网络模式选择 最终选择：
NAT 模式 理由： • 不依赖外部网络环境
• DHCP 行为稳定 • 不受 Wi-Fi / 校园网 / 公司网限制
• 只需端口映射即可实现外部访问
• 更适合开发、测试、长期运行服务（如 DolphinScheduler）
⸻ 5.2 Ubuntu 网络配置（最终版）
5.2.1 Netplan 配置文件 路径：
/etc/netplan/01-networkd.yaml内容：
network:
version: 2
renderer: networkd
ethernets:
ens33:
dhcp4: true5.2.2 文件权限（非常关键）
sudo chown root:root /etc/netplan/01-networkd.yaml
sudo chmod 600 /etc/netplan/01-networkd.yaml若权限不正确，会出现：
Permissions for /etc/netplan/*.yaml are too open并导致配置无法生效。
5.2.3 启用并启动 systemd-networkd
sudo systemctl enable systemd-networkd
sudo systemctl start systemd-networkd确认状态：
systemctl status systemd-networkd应显示：
Active: active (running)5.2.4 应用网络配置
sudo netplan generate
sudo netplan apply- 成功判定标准
6.1 IPv4 获取成功
ip a
输出 ens33 inet 192.168.66.128/24ping -c 3 8.8.8.8
返回成功说明： • DHCP 正常 • 网关正常 • NAT 网络打通
⸻ 7. DolphinScheduler 在 NAT 模式下的访问方案
7.1 核心原则 • DolphinScheduler Web 服务必须监听：
接下来开放端口即可