清浅池塘前几天，一个做运维的朋友在群里发来一句话：我在 VMware 里装了台 CentOS 7 虚拟机，怎么调都只能访问内网，一上外网就断；把网关改回来，内网又访问不了。这问题看着基础，实际踩进去全是细节。日常工作中，很多人的 CentOS 7 虚拟机装在 VMware Workstation 里，既想让它连办公内网，访问 NAS、共享打印机、内网数据库和接口；又希望它保留公网访问能力，能正常执行 yum install、拉取镜像、调用外部 API。说白了就是一台虚拟机要同时踩内网和公网两条网络。这篇我围绕双网卡方案，把 VMware 下的内网、公网完整配置流程，以及背后最容易翻车的路由逻辑一次讲清楚。
1. 一台虚拟机为什么要同时连内网和公网：先从实际场景说起
1.1 最常见的三类场景，你多半也碰到过
这类需求不是某一类人群专属，我接触下来最多的是这三类。
第一类是运维或开发在办公网里干活。虚拟机要连公司的办公内部网络，访问内部 Git、数据库、测试环境 API，同时又要到公网下载软件包、更新依赖。如果只开 NAT，虚拟机确实能上网，但内网服务一个都访问不了；如果切成桥接，外网时好时坏，内网访问倒是通了，可虚拟机多了个局域网 IP，容易被同事的电脑扫描出来，也不安全。
第二类是学习实验环境。比如我要模拟一套双线接入架构：一边接物理家庭内网，访问路由器后台、NAS、智能设备；一边走 VMware NAT 出公网做更新、测试。通过这个环境，可以练习路由、双网卡、策略路由这些真实网络里经常用的东西，而且不会把生产环境搞坏。
第三类是软件部署与联调。我在实际工作里搭过一套数据库测试环境，虚拟机里跑 MySQL 和业务后端，需要连办公内网的认证服务拿 token，同时又要到外网下载 MySQL 的 RPM 包。当时我只用单网卡 NAT，内网认证接口怎么也连不上；切成桥接，外网又时断时续，最后才发现问题不是出在应用层，而是出在虚拟机的路由设计上。
1.2 单网卡为什么搞不定？
一句话：Linux 路由表里的默认路由（0.0.0.0/0）只能有一条。
一张网卡只有一个 IP、一个网关，系统把访问未知网段的流量全部交给默认网关处理。你如果让网关指向内网，外网流量自然出不去；指向公网，内网流量又被默认网关截走。就算你在同一块网卡上配置多个 IP 地址，默认路由依然只能有一条，依然做不到"内网走内网网关、公网走公网出口"这种分流。所以想真正"同时"访问两个网络，最朴素也最稳的做法就是加一块网卡。
1.3 整体配置思路：一张网卡管公网，一张网卡管内网
在动手敲配置之前，先把拓扑和思路定下来，后面才不会越改越乱。我给虚拟机添加第二块虚拟网卡后，基本思路是这样的：第一块网卡接 VMware 的 VMnet8（NAT 模式），负责访问公网，默认网关指向 VMware 虚拟网关；第二块网卡接 VMnet1（仅主机模式）或者桥接到物理网卡，负责访问内网，只填 IP 地址和掩码，不填默认网关；随后在系统里添加一条指向内网网段的路由。这样公网流量走默认路由，内网流量走刚加的静态路由，两个方向互不干扰。整篇文章的核心，就是把这个思路落到命令和配置文件上。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手前先摸清 VMware 虚拟网络的底细：VMnet1、VMnet8、桥接的选型逻辑
2.1 三种虚拟网络模式的区别
很多同学配置失败，不是命令敲错，而是没搞懂 VMware 的三种网络模式本质区别。这里我直接列一张对照表，后面所有配置都围绕这张表展开。
| 模式 | 对应虚拟网卡 | 能否访问公网 | 能否访问物理内网 | 适合场景 |
|---|---|---|---|---|
| NAT | VMnet8 | 能，通过宿主机共享 IP 出去 | 默认不能直接访问物理内网，除非额外加路由或端口映射 | 虚拟机只需要联网、不需要被内网设备访问 |
| 桥接 | VMnet0 | 能 | 能，虚拟机相当于物理局域网里的一台独立主机 | 虚拟机需要作为内网成员访问或提供服务 |
| 仅主机 | VMnet1 | 不能 | 只能和宿主机互相通信 | 内网调试、宿主机与虚拟机互访、不希望对外暴露 |
这里面最容易混淆的是 NAT 和仅主机。NAT 模式虚拟机可以主动访问外网，但外网设备访问不到虚拟机；仅主机模式虚拟机连外网都访问不了，只能和宿主机通信。记住一个简单判断方式：想不想让虚拟机出公网？想出公网，选 NAT 或桥接；想隔离，选仅主机。
2.2 内网侧网卡到底接桥接还是仅主机
这个问题没有标准答案，取决于你的"内网"范围。如果虚拟机需要访问物理局域网里的其他设备，比如公司文件服务器、路由器后台、办公电脑上的共享资源，内网侧网卡必须选桥接模式，并且要桥接在你连接该内网的物理网卡上。因为桥接模式下，虚拟机像一个直接插在交换机上的设备，能被物理内网发现，也能主动找别人。
如果只需要和宿主机互通，比如宿主机提供代理、共享目录、远程下载服务，那么仅主机模式就够了。它的好处是干净，外部局域网完全看不到这台虚拟机，也不用担心自己随手起的服务被同事扫到。我在办公场景里偏向桥接，因为要访问办公室那一堆机器；个人实验环境里用仅主机，省心、安全、不容易跟物理网络互相干扰。
2.3 动"虚拟网络编辑器"之前，先检查网段是否冲突
这是最容易埋雷的地方，也是最容易被忽略的地方。VMware 装好后，VMnet8 默认网段通常是 192.168.x.0/24，比如 192.168.88.0/24。如果物理内网也恰好是 192.168.88.0/24，那就麻烦了：虚拟机同时接到两个网段相同的网络上，CentOS 的路由表会陷入混乱，你配什么都像打地鼠，按下葫芦浮起瓢。
打开"编辑"→"虚拟网络编辑器"，会提示需要管理员权限，确认即可。选中 VMnet8 后，点击"NAT 设置"，记下子网 IP 和 NAT 网关地址，后面配置默认网关要用。如果发现这个网段和物理内网重叠，就把子网 IP 改成完全不冲突的一段，比如物理内网是 192.168.50.0/24，我就把 VMnet8 改成 10.0.88.0/24，DHCP 范围会自动跟着变，不用额外处理。VMnet1 的默认网段也要看一眼，避免两台不同需求的虚拟机互相影响。
3. CentOS 7 双网卡双 IP 配置全流程：从添加网卡到重启网络
3.1 在 VMware 里给虚拟机添加第二块网卡
这个动作虽然简单，但顺序有讲究。建议虚拟机在关机状态下操作，虽然 VMware 支持开机热添加网卡，但 CentOS 7 里热添加之后设备名经常不会按预期顺序生成，比如原本的 ens33 变成 ens34，反而把配置搞乱。
具体步骤：选中虚拟机，点击右键 →"设置"→"添加"→"网络适配器"→"完成"。添加完成后，在"网络适配器 2"里选择"自定义：特定虚拟网络"，下拉框里选好模式。我的建议是：原来的网卡 1 保持 VMnet8（NAT），让它管公网；新添加的网卡 2 选 VMnet1 或者桥接，让它管内网。这样从虚拟机启动那一刻开始，网卡顺序就是确定的，后续配置不会乱。
3.2 开机后确认系统识别了几块网卡
启动虚拟机后，先执行 ip addr，不要急着改文件。正常情况下你会看到 ens33 和 ens37 两个接口，ens33 是第一块网卡，ens37 是第二块。如果第二块网卡没出现，可能是 VMware Tools 或内核驱动问题，但 CentOS 7 对 e1000 和 vmnet 驱动支持很好，基本执行 nmcli dev status 或 ip link show 就能看到。注意，CentOS 7 里网卡名不是以前熟悉的 eth0，而是 ens33 这种，这是 systemd 的 Predictable Network Interface Names（可预测网络接口命名）规则，en 表示以太网，后面数字对应 PCI 位置，不是乱码。这个命名规则很稳定，配置时按这个名字写就不会错。
3.3 配置公网网卡 ifcfg-ens33
公网侧的网卡配置文件在 /etc/sysconfig/network-scripts/ifcfg-ens33，直接用 vi 编辑。如果之前用的是 VMware NAT 默认 DHCP，那内容一般是这几行：
code复制TYPE=Ethernet
BOOTPROTO=dhcp
NAME=ens33
DEVICE=ens33
ONBOOT=yes
这样虚拟机开机自动从 VMware NAT 的 DHCP 服务获取 IP 和网关，默认路由也会跟着出来，适合懒人。但我更推荐给它配静态 IP，因为后面要长期维护、做端口映射或调试，IP 老变很痛苦。静态配置如下：
code复制TYPE=Ethernet
BOOTPROTO=static
NAME=ens33
DEVICE=ens33
ONBOOT=yes
IPADDR=10.0.88.100
NETMASK=255.255.255.0
GATEWAY=10.0.88.2
DNS1=223.5.5.5
DNS2=114.114.114.114
注意 GATEWAY 只在这一块网卡上写，内网网卡千万不要写。10.0.88.2 是刚才在虚拟网络编辑器里记下的 NAT 网关，别自己编一个。DNS 我习惯用国内公共 DNS，223.5.5.5 是阿里，114.114.114.114 是 114DNS，方便 yum 解析。如果你所在网络有内网 DNS，建议把内网 DNS 加在 DNS3 或换掉公共 DNS，否则解析内网域名会失败。
3.4 配置内网网卡 ifcfg-ens37 和静态路由文件 route-ens37
内网网卡的文件要新建，路径是 /etc/sysconfig/network-scripts/ifcfg-ens37，内容如下：
code复制TYPE=Ethernet
BOOTPROTO=static
NAME=ens37
DEVICE=ens37
ONBOOT=yes
IPADDR=192.168.50.110
NETMASK=255.255.255.0
关键点：这里不写 GATEWAY，也不写 DNS。只写 IP 和掩码，让这块网卡安静地存在即可。然后还要在同目录下新建一个路由文件 route-ens37，把内网网段指到内网网关上：
code复制192.168.50.0/24 via 192.168.50.1 dev ens37
192.168.50.1 必须是你内网网段的真实网关地址，不是 VMware 虚拟网关，也不是随便填的。这个文件是 CentOS 6/7 都认的标准写法，network 服务启动时会自动把里面的路由加进去，重启不丢。如果你想临时验证，可以先执行这条命令，但别忘了它重启后会消失：
code复制ip route add 192.168.50.0/24 via 192.168.50.1 dev ens37
3.5 重启网络服务并确认效果
配置文件全部准备好后，执行：
code复制systemctl restart network
CentOS 7 如果用的是老式 network 服务，也可以执行 service network restart。重启后马上检查三条信息：ip addr 看两块网卡的 IP 是否都在；ip route 看默认路由是否仍然指向公网网关 10.0.88.2；再确认是否多了一条 192.168.50.0/24 的静态路由。这三条确认完，网络配置基本就完成了 80%。剩下的就是路由细节和验证，这也是后面最容易出问题的地方。
4. 路由才是核心：两个网关打架怎么劝架，静态路由怎么加才稳
4.1 为什么两块网卡都不能乱写 GATEWAY
我见过太多人在这里崩溃：明明两块网卡都配了网关，为什么网络还是时通时断？原因就在默认路由上。Linux 的默认路由只能有一条，如果两块网卡的 ifcfg 文件里都写了 GATEWAY，network 服务启动时会按网卡启动顺序依次往主路由表里写默认路由，后写的覆盖先写的，没有任何优先级。结果就是这次启动默认网关是公网侧，下次重启变成内网侧，表现就是"时而能上网、时而内网通"，毫无规律。
更直观地说，内网网卡写了 GATEWAY 之后，系统可能把默认路由指向 192.168.50.1。这台内网网关收到公网访问请求后，不知道该怎么转发给运营商，只会把包扔掉或返回不可达，于是虚拟机"上不了公网"。反过来，如果默认网关一直在公网侧，内网访问 192.168.50.21 这类地址时，系统发现主路由表里没有对应网段路由，会把它丢给公网网关，公网网关显然不知道 192.168.50.0/24 在哪，内网又不通。这就是"打架"的本质。
排查时可以执行 ip route，如果看到类似下面的输出，说明默认路由被抢了：
code复制default via 192.168.50.1 dev ens37
192.168.50.0/24 dev ens37 proto kernel scope link src 192.168.50.110
这种情况下公网一定是不通的，因为所有外网流量都往内网网关发了。
4.2 用 ip route 和 ip route get 理解现有转发路径
网上很多教程让你用 route -n，但我更推荐 ip route，因为它输出的语义更准确。日常验证就三个命令：
code复制ip route
ip route get 223.5.5.5
ip route get 192.168.50.5
ip route 看整体路由表；ip route get 223.5.5.5 看访问公网时数据包会走哪个网卡、哪个网关；ip route get 192.168.50.5 看访问内网时走哪条路。这两个命令是判断"为什么不通"最快的手段。比如 ip route get 192.168.50.5 显示走了 ens37，但下一跳是 NAT 网关，那一定是你没加静态路由，或者静态路由写错了。
4.3 内网静态路由的持久化方式不止一种
route-ens37 文件是首选，因为它被 network 服务原生支持，不用额外写脚本。但有些场景下你会遇到 network 服务没接管、或者你用的是 NetworkManager，那 route-ens37 可能不会被读取。这时第二个办法是把路由写到 /etc/rc.local 里：
code复制ip route add 192.168.50.0/24 via 192.168.50.1 dev ens37
CentOS 7 的 rc.local 默认没有执行权限，需要 chmod +x /etc/rc.local，否则开机不生效。第三种是策略路由，适用于一台虚拟机要同时承担多个复杂网段、或者不同来源流量要分流的情况，比如内网访问走内网网卡、公网访问走公网网卡还要互相隔离。策略路由需要在 /etc/sysconfig/network-scripts/route-ens37 里写多重路由表，再用 rule-ens37 绑定源 IP，语法比较复杂。但说实话，90% 的双网卡需求用一条静态路由就能解决，别一开始就上策略路由，容易把自己绕晕。
4.4 DNS、防火墙这些边角料，忘了就前功尽弃
网络通了不代表业务通，DNS 和防火墙是最后两道暗坑。
CentOS 7 默认的 /etc/resolv.conf 经常被 NetworkManager 或 DHCP 改写。你手动改了 DNS，重启网络后又变回原样，于是域名解析失败，但 IP 能 ping 通。解决办法有两个：在 ifcfg-ens33 里写好 DNS1、DNS2，让脚本自己生成 resolv.conf；或者干脆禁掉 NetworkManager，只保留 network 服务。我个人习惯禁掉 NetworkManager，因为很多服务器场景用不到它的动态管理功能，它反而会把静态配置搞混。禁用命令：
code复制systemctl stop NetworkManager
systemctl disable NetworkManager
systemctl restart network
防火墙方面，firewalld 默认策略对 ping 不一定拦，但会拦你新加的端口。做实验时如果发现 SSH 连不上、ping 不通，可以先临时关掉试一下：
code复制systemctl stop firewalld
确认是防火墙导致的，再按需放行端口，别图省事直接 disable firewalld，生产环境这么干容易给自己埋雷。
5. 验证与排障：把"内网能通、公网也能通"这句话落到命令上
5.1 双出口的通断验证清单
配置完成不代表万事大吉，我习惯按下面顺序逐层验证，哪一步失败就定位到哪一层：
code复制ip addr
ip route
ping -c 4 10.0.88.2
ping -c 4 223.5.5.5
ping -c 4 192.168.50.1
ping -c 4 192.168.50.21
curl -I http://mirrors.aliyun.com
yum install -y wget
ip addr 看 IP 是否都在；ip route 看路由表是否符合预期；ping 网关验证二层三层；ping 公网 IP 验证 NAT 出口；ping 内网网关验证内网链路；再 ping 一台具体内网设备验证真实业务路径；curl 验证 DNS 和 HTTP 协议栈；最后用 yum 装个包，验证最真实的业务需求。如果每一步都通过，那么这一套双网卡配置就真的稳了。
补充一个经验：CentOS 7 已经停止官方维护，如果你的 yum 源还指向官方仓库，执行 yum install 大概率报 404 或者连接失败。记得把 yum 源换成国内镜像源或者 Vault 归档源，这一步不解决，网络再通 yum 也装不了东西。
5.2 重启后配置丢失的几种经典原因
"重启之前都好好的，重启完又不行了"是我被问得最多的一句话。原因主要有四个。
第一个是 NetworkManager 捣乱。NM 启动后接管网卡，可能把你在 ifcfg 里的静态路由和网关覆盖掉。排查方法：执行 nmcli dev status，看网卡设备是否被 NetworkManager 托管。如果被托管，说明两个网络管理服务在打架，按前面说的禁用 NM 即可。
第二个是 network 服务没有设置开机启动。CentOS 7 有些精简安装镜像默认不给 network 服务开自启，重启后配置全不生效。执行 systemctl enable network 解决。
第三个是 ifcfg 文件名和 DEVICE 名字不匹配。文件名必须严格对应网卡名，比如 ifcfg-ens37 里 DEVICE=ens37，如果写成 ens38 或者复制时漏改，network 服务会跳过这个文件。检查文件内容是最容易被忽略的一步。
第四个是虚拟机快照回滚。有些同学改完配置没打快照，后面实验做坏了，一恢复快照，配置也跟着没了。配置前后各打一个快照是我自己的习惯，一个叫"双网卡配置前"，一个叫"双网卡配置完成"，排查问题时的退路就有了。
5.3 网段冲突是怎么坑人的：一个真实案例
之前我在宿舍搭实验环境，物理网络是 192.168.1.0/24，路由器后台是 192.168.1.1。VMware 装完后，VMnet8 默认网段竟然也是 192.168.1.0/24。我按上面双网卡方案配置完，发现怎么调都时通时断：ping 内网 NAS 没问题，ping 公网偶尔通偶尔断，yum 更是看心情。当时排查了很久，最后用 ip route 才发现默认路由在内网网卡和公网网卡之间反复横跳。
原因是虚拟机同时接了一个网段完全相同的物理网络和虚拟 NAT 网络，系统根本分不清两个 192.168.1.0/24 的区别，路由表直接迷茫。解决办法就是在虚拟网络编辑器里把 VMnet8 子网改成 10.0.88.0/24，重启网络后一切恢复正常。这个坑很多人一辈子遇不上，但只要遇到一次，就能让你记住网段规划的重要性：虚拟网络和物理网络的网段，永远不要重叠。
5.4 双网卡环境下的远程管理小技巧
配置完成后，远程管理时有个细节值得注意。建议在 Xshell 或 FinalShell 里保存两个会话，一个走内网 IP 连接，一个走公网侧 NAT 地址连接。在办公内网时用内网 IP，延迟低、不受外网波动影响；需要在外网环境访问虚拟机时，再走公网侧会话。CentOS 7 的 sshd 默认监听 0.0.0.0:22，也就是所有网卡，不需要额外改配置，但记得在防火墙里放行 22 端口。
还有一个容易被忽略的问题：虚拟机同时拥有两个网卡的 IP，发起访问时源 IP 是哪个？有时候你用内网 IP SSH 连上去，虚拟机访问内网其他机器时却从公网网卡回包，导致连接卡顿或无故断开。排查方法还是 ip route get，确认源 IP 符合预期。复杂场景下可以直接指定源 IP 发起连接：
code复制curl --interface 192.168.50.110 http://192.168.50.21/
最后再分享一个小经验。双网卡配置完成后，别急着卸载 VMnet1 或关掉仅主机模式，先用它做一段时间的"逃生通道"。万一 NAT 侧网络因 VMware 服务异常挂掉，你还能通过仅主机网卡连上去排查。我自己的虚拟机一般都保留三张网卡的配置：公网走 NAT，内网走桥接，仅主机当成管理口留作保底。这套思路帮我省掉了不少"连不上去只能重启宿主机"的尴尬时刻，也算是一台 CentOS 7 虚拟机同时踩内网和公网这条路走下来，最常见的经验总结。