企业官网建设流程全解析

VMware 虚拟机「一边上网、一边 ping 开发板」：NAT + 桥接双网卡完整方案（含 DUP! 详解）

主机连着 WiFi 上网，开发板用网线直连电脑有线网口。虚拟机既要能apt update上网，又要能 ping 通开发板做 NFS/TFTP/交叉调试。网上教程要么让你用 NAT（上得了网、看不见板），要么让你用桥接（看得见板、上不了网），难道只能二选一？

结论先行：不用二选一。给虚拟机加第二块网卡，一块 NAT 专门上网，一块桥接专门连板，互不干扰。本文记录一次完整的配置 + 排障过程，包括桥接选错网卡、误用仅主机、169.254.x.x、netplan 缩进翻车、以及那个吓人的DUP!到底是怎么回事。

一、环境与目标

最终 IP 规划（全部设备在板卡链路上同网段）：

注意：你的网卡名、NAT 网段可能不同（比如 NAT 是192.168.161.0、桥接网卡叫ens34），一切以虚拟机里ip -br a的实际输出为准，本文的名字只是我这台机器的实例。

二、核心思路：两块网卡各司其职

VMware 的三种网络模式先掰扯清楚：

• NAT（VMnet8）：虚拟机通过主机共享上网，最省心、最稳定，但外部物理设备（你的开发板）看不见虚拟机。
• 桥接（VMnet0）：虚拟机通过指定的物理网卡直接接入物理二层网络，和网线对端的设备处于同一网段，可以互相 ping。桥接到哪块物理网卡是关键。
• 仅主机（VMnet1）：一个只连虚拟机和主机虚拟网卡的封闭网络，不接任何物理网卡——所以它天然到不了插在物理网口上的开发板（坑②详述）。

既然一块 NAT 管上网、一块桥接管连板，加第二块网卡把两者拼起来即可。最终拓扑可以概括为：ens37 经 VMnet8(NAT) 走主机 WiFi 出外网；ens33 经 VMnet0 桥接到 Realtek 有线网卡，与网线对端的开发板处在同一网段。

动手前三条铁律先记住：

1. 板子网线插在有线网卡上，VMnet0 桥接就必须绑定Realtek 有线网卡，不能选"自动"，更不能选 WiFi；
2. 桥接网卡只配同网段静态 IP，不写 gateway，否则它会抢默认路由把外网搞断；
3. 改完虚拟网络/网卡硬件，在虚拟机里sudo poweroff彻底关机再开机，"挂起"会保留旧网络状态。

三、完整配置步骤

3.1 虚拟网络编辑器（主机侧）

VMware 菜单：【编辑】→【虚拟网络编辑器】→ 左下角【更改设置】（提权）。

• VMnet0：选【桥接模式】，【已桥接至】下拉手动指定Realtek PCIe GbE Family Controller，不要用"自动"。
• VMnet8：NAT 模式，勾选【使用本地 DHCP 服务】，子网保持默认（我这里是192.168.199.0）。
• VMnet1：仅主机，子网保持默认192.168.72.0，本次用不到它，千万别改成192.168.0.0（坑④）。

点【应用】→【确定】。

3.2 给虚拟机添加第二块网卡（必须关机操作）

虚拟机内sudo poweroff彻底关机（挂起状态下【添加】可能是灰的）。然后【编辑虚拟机设置】（快捷键Ctrl+D）：

• 网络适配器 1→ 选【NAT 模式】，勾【启动时连接】；
• 点左下角【添加】→【网络适配器】→【完成】，新增网络适配器 2→ 选【桥接模式】，勾【启动时连接】，【复制物理网络连接状态】可勾可不勾；
• 【确定】后开机。

3.3 Windows 有线网卡配静态 IP

Win+R输入ncpa.cpl回车 → 右键接板子的【以太网（Realtek）】→【属性】→ 双击【Internet 协议版本 4 (TCP/IPv4)】：

• IP 地址：192.168.0.100
• 子网掩码：255.255.255.0
• 默认网关、DNS 全部留空（这块网卡只用来直连板子，不允许它产生默认路由）

3.4 Ubuntu 内用 netplan 固化网卡配置

开机后先确认实际网卡名：

ip-bra

我这台机器上：ens33是桥接网卡、ens37是 NAT 网卡（你机器上可能是 ens34/ens38，以实际为准）。

Ubuntu 22.04 桌面版默认让 NetworkManager 接管，netplan 文件通常是/etc/netplan/01-network-manager-all.yaml。编辑它：

sudonano/etc/netplan/01-network-manager-all.yaml

# Let NetworkManager manage all devices on this systemnetwork:version:2renderer:NetworkManagerethernets:ens33:# 桥接网卡：连开发板dhcp4:falseaddresses:-192.168.0.200/24# 注意：不写 gateway4 / routes，不写默认网关ens37:# NAT 网卡：上网dhcp4:true

应用：

sudochmod600/etc/netplan/01-network-manager-all.yamlsudonetplan applysleep5ip-bra

预期结果：ens33拿到192.168.0.200，ens37拿到192.168.199.x。

yaml 只能用空格缩进，绝对不能用 Tab；否则netplan apply后两块网卡都会变成没有 IP 的 UNKNOWN 状态（坑⑤）。

3.5 验证：三跳全通

ping-c3baidu.com# 第 1 跳：外网（走 ens37 NAT）ping-c3192.168.0.100# 第 2 跳：主机有线网卡（走 ens33 桥接）ping-c3192.168.0.133# 第 3 跳：开发板

三跳全通即收工。我这边的实测结果：

PING baidu.com (124.23.177.164): 3 packets transmitted, 3 received, 0% packet loss PING 192.168.0.133: 3 packets transmitted, 3 received, 0% packet loss $ ip neigh 192.168.199.2 dev ens37 lladdr 00:50:56:fc:7d:10 REACHABLE 192.168.0.133 dev ens33 lladdr ea:a1:50:1d:75:fd REACHABLE

之后板子要挂载虚拟机的 NFS/TFTP，服务器地址统一填192.168.0.200。

四、踩坑实录（全部实测踩过）

坑① 桥接选成了 WiFi 网卡 / “自动”

主机靠 WiFi 上网，VMnet0 默认"自动桥接"时经常挑中无线网卡；手动选错成MediaTek Wi-Fi 6时更直接——板子在有线网口上，流量却从天线发出去，物理上就是两条路。

现象：ping 192.168.0.133报Destination Host Unreachable，ip neigh里板子是FAILED/incomplete。

解决：VMnet0【已桥接至】手动锁定 Realtek PCIe GbE。另外，之前桥接"时灵时不灵"，很多时候只是因为当时网线没插、有线网卡处于"网络电缆被拔出"状态，桥接自然没有链路。

坑② 用"仅主机 VMnet1"连直连的板子

仅主机模式是一个封闭虚拟交换机，只连接虚拟机和主机上的 VMnet1 虚拟网卡，不绑定任何物理网卡。虚拟机的帧根本到不了 Realtek 物理口，更到不了网线对端的板子。

解决：网线直连板子的场景，第二块网卡必须用桥接（VMnet0 → Realtek），虚拟机和板子才在同一个二层广播域。仅主机适合"只跟主机通信、完全隔离"的场景，不适合接物理设备。

坑③ 网卡拿到169.254.x.x自动私有地址

169.254.0.0/16是 DHCP 失败后的 link-local 自动地址。当时我把 VMnet1 的 DHCP 关了、静态 IP 又没配对，网卡两头落空，于是自我分配了一个169.254.12.80，从这个地址发出去的 ping 全部Host Unreachable。

解决：桥接网卡明确写静态 IP（dhcp4: false+addresses）；NAT 网卡明确dhcp4: true。别让网卡"自谋生路"。

坑④ 把 VMnet1 子网改成192.168.0.0，引发 DUP!

为了凑板子网段，一度把 VMnet1 的子网也改成了192.168.0.0/24。结果 Windows 主机上VMnet1 虚拟网卡和 Realtek 物理网卡都处在192.168.0.0/24，两个接口一起回应，ping 主机时满屏DUP!（详细分析见第五章）。

解决：VMnet1 子网改回默认的192.168.72.0，让它离开板卡网段；本次方案根本不用 VMnet1，保持默认即可。

坑⑤ netplan yaml 一个 Tab，两块网卡全灭

用 vim 编辑时缩进混进了 Tab，netplan apply后ip -br a里 ens33、ens37 全部变成UNKNOWN 且没有 IP，外网瞬间断掉。yaml 对缩进零容忍。

解决：避免手工缩进翻车，可以直接用 heredoc 整段写入：

sudotee/etc/netplan/01-network-manager-all.yaml>/dev/null<<'EOF' network: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: false addresses: [192.168.0.200/24] ens37: dhcp4: true EOFsudochmod600/etc/netplan/01-network-manager-all.yamlsudonetplan apply

调试时用sudo netplan --debug apply 2>&1 | tail -20看具体报错；桌面版若 NetworkManager 没重新接管，执行sudo systemctl restart NetworkManager。

坑⑥ 网卡名不是教程里的 ens33/ens34

教程写 ens34，机器上却是 ens37——网卡名由 PCI 插槽/添加顺序决定，照搬必错。任何时候先ip -br a确认真实名字，再写进 netplan。以后若增删虚拟硬件导致网卡名变化，同步改 netplan 即可。

坑⑦ 给桥接网卡写了默认网关，外网反被抢走

给 ens33 顺手填了网关后，路由表里可能出现两条默认路由，系统把上网流量也往192.168.0.x发，而那块网卡根本不通外网，于是域名解析失败、网页打不开。

解决：桥接网卡只留addresses，不写 gateway/routes；默认路由只能有一条，指向 NAT（ens37）。用ip route检查，默认路由应从 ens37 走。

坑⑧ 改完设置不关机，热切换不生效

虚拟机运行中改桥接对象、加网卡，旧连接常常不释放、新配置不生效，表现为"明明改了还不行"。

解决：sudo poweroff彻底关机（不是挂起、不是只在系统里 reboot），再冷启动让两块网卡重新初始化。

五、DUP! 到底是怎么回事？会不会影响通信？

这是本次最让人心里发毛的现象。ping 主机有线网卡时，每个请求都收到两个回应：

64 bytes from 192.168.0.100: icmp_seq=1 ttl=128 time=3.06 ms 64 bytes from 192.168.0.100: icmp_seq=1 ttl=128 time=3.23 ms (DUP!) 64 bytes from 192.168.0.100: icmp_seq=2 ttl=128 time=5.96 ms 64 bytes from 192.168.0.100: icmp_seq=2 ttl=128 time=6.81 ms (DUP!) --- 192.168.0.100 statistics --- 3 packets transmitted, 3 received, +2 duplicates, 0% packet loss

DUP!（duplicate）表示同一个 ICMP 序号收到了多个回应。它有两种完全不同的成因，必须区分：

成因 A：真·IP/网段冲突（需要处理）
主机上有两个接口同时处在192.168.0.0/24（坑④：物理网卡.100+ 被错误改网段的 VMnet1 虚拟网卡），两个接口都对 ARP/ICMP 做出回应。这种情况下回应来自两个不同的 MAC 地址，会造成 ARP 表混乱，应当消除——把 VMnet1 子网改回192.168.72.0。

成因 B：VMware 桥接的回包重复 hairpin（无害，可忽略）
桥接模式下，虚拟机 ping 的是宿主机自身那块被桥接物理网卡的 IP。这个帧在 VMware Bridge Protocol 桥接层和主机 TCP/IP 协议栈之间可能被各处理一次，于是主机用同一个 MAC回应了两遍。这是桥接模式的已知现象，只出现在"guest ping 宿主自身物理网卡 IP"这一特定路径上，对 ping 板子、NFS、TFTP、SSH 没有任何影响。

一键判别：用 arping 看回应的 MAC 是否相同

sudoaptinstallarpingsudoarping-Iens33-c3192.168.0.100

• 所有回应都是同一个 MAC（我这里84:ba:59:c0:9f:3b，3 发 6 收、3 extra，但 MAC 全相同）→ 成因 B，无害，忽略即可；
• 回应来自两个不同 MAC→ 成因 A，去 Windows 执行ipconfig /all，找出所有赖在192.168.0.x的接口（重点查残留的 VMnet1 适配器），禁用再启用或还原 VMnet1 默认设置。

作为对照，ping 真正的外部设备板子时是干干净净的，没有任何重复：

$ sudo arping -I ens33 -c 5 192.168.0.133 60 bytes from ea:a1:50:1d:75:fd (192.168.0.133): index=0 ... --- 192.168.0.133 statistics --- 5 packets transmitted, 5 packets received, 0% unanswered (0 extra)

一句话总结：先看 MAC 再决定要不要慌——同 MAC 的 DUP 是桥接自带的"回声"，不同 MAC 才是配置冲突。

六、分层排障流程与命令速查

不要一上来就乱改设置，按"从外到内、一跳一跳"的顺序定位（外网 → 主机有线口 → 开发板），能解决 90% 的问题。

命令速查：

ip-bra# 一眼看全部网卡名与 IP（网卡名以它为准）iproute# 查默认路由，只能从 NAT 网卡走ipneigh# 查 ARP 表：REACHABLE=通，incomplete/FAILED=不通sudoarping-Iens33192.168.0.133# 二层直查板子在不在线（比 ping 更底层）sudodhclient ens37# NAT 网卡手动重新获取 IPsudonetplan--debugapply# 应用配置并打印详细报错（查 yaml 缩进）sudosystemctl restart NetworkManager# 让桌面版 NetworkManager 重新接管

按现象对号入座：

板子侧（串口终端）最后检查清单：

1. 板子上电、系统启动完成，PC 端和板端网口灯都亮/闪；
2. ip a确认网口状态为UP、IP 确实是192.168.0.133/24；没有就配：

   ifconfigeth0192.168.0.133 netmask255.255.255.0 up

3. 板子反向ping 192.168.0.200双向验证；
4. 换一根网线（现代网卡支持自动翻转，普通直通线即可，无需交叉线）。

七、写在最后

整个问题的本质，是把两种职责不同的虚拟网络硬塞进一块网卡造成的：

• NAT 的职责是"借道主机上网"，它看不见物理设备；
• 桥接的职责是"挂进物理网段"，它不负责给你联网。

想明白这点，方案就很自然：两块网卡、两条通路、两套 IP，互不抢路由。配置固化在 netplan 里，以后只要板子上电、网线插好，开机即用，重启不丢。

回顾这次踩坑链：桥接误选 WiFi → 误用仅主机 →169.254地址 → VMnet1 改网段引发 DUP → netplan 缩进全灭 → 网卡名对不上 → 热切换不生效，每一步都很典型。希望这篇记录能帮你少走一晚上的弯路。

环境：VMware Workstation + Ubuntu 22.04 桌面版，主机 WiFi 上网，开发板网线直连有线口。文中 IP/网卡名为本人环境实例，复现时请以ip -br a实际输出为准。