虚拟机跑在 Linux 上,最让人头大的往往不是系统装不起来,而是网络。镜像装好了,命令行能敲了,结果 ping 不通外网,SSH 连不上,或者跟局域网里的其他机器互相找不到,折腾半天发现是网络模式选错了。做运维和做开发的都清楚,虚拟机网络模式说简单是真简单,无非桥接、NAT、仅主机三种来回切;说复杂也真复杂——不同模式的原理、IP 分配方式、端口转发、防火墙、网卡命名,任何一环没对上都会出问题。今天这篇就把“配置 VM(虚拟机)在 Linux 上的网络几种模式”这件事讲透:三种模式分别是什么原理,适合什么场景,Linux 虚拟机内部该怎么写 IP,以及实操中会踩到的坑怎么排查。
1. 虚拟机网络到底是怎么“通”的?先搞懂三种底层逻辑
很多新手喜欢直接跳到“选哪个模式能上网”,但如果你不明白网络数据在虚拟机、宿主机、物理路由器之间怎么流转,后面一旦出问题就只能靠猜。所以我先把三种模式的底层逻辑讲透,这部分看懂了,后面的配置才有根。
1.1 桥接模式:虚拟机直接“冒充”一台真实主机
桥接模式(Bridged)的原理,可以理解成虚拟机的网卡通过一个虚拟交换机,直接和宿主机的物理网卡“桥”在一起。效果就是虚拟机的网卡直接接到了你办公室那台物理交换机上,它在这条局域网上是一个独立节点,拥有自己的 IP 和 MAC 地址。
打个比方:本来办公室里有一台交换机,你的宿主机是插在上面的一台电脑。现在虚拟机选了桥接模式,就等于你在交换机的空口上又插了一台电脑——这台“电脑”就是虚拟机。宿主机是宿主机,虚拟机是虚拟机,两者在二层是完全对等的。
这个模式最典型的特征就是:虚拟机能拿到和你宿主机同一个网段的 IP。比如宿主机是 192.168.1.100,虚拟机就可以配 192.168.1.101,网关都是 192.168.1.1。局域网里的其他电脑、打印机、服务器,直接就可以访问这台虚拟机,不需要任何额外配置。
所以桥接模式适合什么场景?需要让虚拟机“变成”局域网里一台正经主机,自己对外提供服务。比如你在一台 Linux 虚拟机里跑了一个 Web 服务,想让同事直接用浏览器访问;或者你要测试 DHCP、DNS、FTP 这类依赖局域网环境的服务;又或者你想验证虚拟机和其他物理机之间的真实通信链路。总之,需要“被人找得到”的时候,选桥接。
它的缺点也很明显:第一,会占用一个局域网 IP,如果公司网络是按 IP 段分配的,你得有富余地址;第二,如果物理网络是 WiFi 环境,很多无线 AP 默认开了 AP 隔离,虚拟机的桥接网络可能连网关都 ping 不通;第三,你在虚拟机里开的服务,会暴露在整个局域网里,安全上要自己掂量。
1.2 NAT 模式:藏在主机身后的“小号”
NAT 模式(Network Address Translation)是绝大多数人刚装完虚拟机时默认使用的模式。它的原理是:虚拟机网卡连接到一个虚拟交换机上,这个交换机与宿主机之间有一个 NAT 服务做地址转换。虚拟机发出的数据包,会被 NAT 服务转换成宿主机的数据包再发到外网;从外网回来的数据,又会被转换回内网地址交给虚拟机。
用一个家庭路由器的场景来类比就很好懂了:宿主机相当于家里那台路由器的 WAN 口,虚拟机相当于连在 LAN 口下的手机。手机能上网,也能访问路由器的管理页面,但从公网上看,所有流量都来自路由器那个公网 IP,公网上的其他机器没办法主动找到你手机。
在默认配置下,NAT 模式的虚拟机使用网段 192.168.x.0/24 这类私有网段,网关指向虚拟网卡上的一个固定地址,DNS 也是由虚拟化平台的 DHCP 自动分配的。我把虚拟机里的 IP 拿到了,它通常是 192.168.88.128 这样的地址,宿主机也可以通过同一个网段的虚拟网关去访问它。
NAT 模式最适合的场景就是:虚拟机只需要访问外网,但不需要被别人直接访问。比如你想在 Linux 虚拟机里拉源码、装软件包、测试某个客户端功能;或者你同时开十几台虚拟机做集群测试,只想让它们能上网,不想让它们占用真实的局域网 IP;又或者虚拟机里要跑一些不太信任的服务,你希望它处于一个“可出不可进”的隔离状态。
NAT 模式最大的好处是稳。不管你宿主机怎么切换 WiFi、换路由器、搬家改网段,虚拟机的 NAT 网络基本不受影响,因为它在宿主机后面又建了一个独立的小网。这也是为什么我特别喜欢推荐新手先用 NAT——它最容易上手,也最少受物理网络环境干扰。
1.3 仅主机模式:封闭的“实验台”
仅主机模式(Host-Only)字面意思就很好理解:虚拟机只能和宿主机通信。它也是通过一个虚拟交换机连接,但这个交换机上除了宿主机和虚拟机自己,没有任何外部出口,没有 NAT,没有路由器,虚拟机在这个网络里是“与世隔绝”的。
你可以把它想成一个封闭的实验室:房间里只有你和导师,门外是走廊,走廊通向大街,但门是焊死的。你和导师怎么交流都可以,但你们俩都出不去,外面的人也进不来。
仅主机模式的典型网段是另一个私有网段,宿主机在这个网段里有一个虚拟网卡地址,比如 192.168.152.1,虚拟机就拿 192.168.152.x 的地址。从宿主机能 ping 通虚拟机,从虚拟机也能 ping 通宿主机,但虚拟机访问不了外部网络。
什么场景需要这种“封闭实验室”?比如你要在完全离线的环境里测试一个多节点系统,几台 Linux 虚拟机互相之间要通信,但不需要真正的互联网;或者你搞安全测试、模拟内网渗透,不希望虚拟机里的工具去访问外网;又或者你在验证一台“裸机”上部署某些软件时的网络依赖。用仅主机模式,既能保证虚拟机之间互通,又切断了外网,环境更可控。
三种模式的对比,我放在一起看一眼更直观:
| 模式 | 虚拟机能否访问外网 | 局域网内其他设备能否访问虚拟机 | 宿主机能否与虚拟机通信 | 默认网段 |
|---|---|---|---|---|
| 桥接 | 能,走物理网卡 | 能,直接同网段 | 能,同网段直接互通 | 与宿主机一致 |
| NAT | 能,经宿主机转换 | 不能,默认隔离 | 能,经虚拟网关卡 | 独立私有网段 |
| 仅主机 | 不能 | 不能 | 能,经虚拟网关卡 | 独立私有网段 |
搞清楚这张表,选模式基本就不会跑偏。
2. 动手前的网络规划与虚拟网卡体系
很多人配置虚拟机网络翻车,不是不会选模式,而是没有提前看“虚拟网络编辑器”里的默认配置。不同的虚拟网卡编号对应不同的模式,你不先把这张底牌看明白,后面怎么改都是盲改。
2.1 先认识虚拟网络编辑器里的 VMnet 编号
桌面虚拟化软件通常会带一个虚拟网络编辑器,打开之后能看到好几个 VMnet 虚拟网络。虽然界面和命名可能略有差异,但核心逻辑基本统一。
VMnet0 一般对应桥接模式,它把物理网卡和虚拟机的网卡桥接在一起。这里注意,如果你的宿主机有多个物理网卡,比如有线网卡和无线网卡,虚拟网络编辑器里会让你选择桥接到哪一个。选错了,虚拟机就会“插错插座”,可能你怎么配都上不了网。
VMnet8 一般对应 NAT 模式,它自带一个 DHCP 服务和一个 NAT 网关。编辑器里能看到它的网段、子网掩码、DHCP 地址池,以及网关地址。这个网段默认是某个随机私有网段,不同版本、不同机器、不同安装时间都可能不一样,所以不要想当然地以为它是固定的,一定要亲自打开看。
VMnet1 一般对应仅主机模式,它只有一个虚拟网卡和 DHCP 服务,没有 NAT 出口。宿主机在这个网段上的地址通常是一个固定值,比如 192.168.152.1 之类的,这个地址就是虚拟机“看到”的宿主机 IP。
还有一类额外的 VMnet2、VMnet3 到 VMnet19,这些是留给自定义网络模式用的,默认没有对应任何模式。你可以把几台虚拟机都挂到同一个自定义 VMnet 上,让它们组成一个独立的小局域网,不受 NAT 和仅主机模式那些默认设置的影响。
我的建议是,第一次配网络前,先把虚拟网络编辑器里的每个网段都截图记下来。别嫌麻烦,后面排查问题全靠它。你要是连自己虚拟网络的 IP 段都不知道,那就连排查的起点都没有。
2.2 网段规划:什么情况会踩坑
网段规划是最容易被忽略、又最能搞出“玄学问题”的一环。
最常见的坑就是网段重叠。很多桌面虚拟化软件安装的时候会在 192.168.x.0 这个范围内随机挑一个段给 NAT 用,比如 192.168.88.0/24。但如果你宿主机所在的真实局域网恰好也是 192.168.88.0/24,那 NAT 模式下的虚拟机就有可能与真实局域网里的设备产生路由混乱,表现出来可能就是:虚拟机时通时不通,或者网关能 ping 通但外网不稳定,甚至访问某些内网资源时跳到奇怪的地方。
正确做法是:把虚拟网络的网段和真实局域网的网段刻意错开。宿主机真实局域网是 192.168.1.0/24,我就把 NAT 改成 192.168.88.0/24,把仅主机改成 192.168.99.0/24,让它们各玩各的。这不算什么高级技巧,但能帮你省掉非常多排查时间。
另外还要注意 DHCP 地址池和静态地址的关系。比如你在编辑器里看到 NAT 网段是 192.168.88.0/24,DHCP 地址池是 192.168.88.128 到 192.168.88.254,那你在虚拟机里手动配置静态 IP 时,最好选择 192.168.88.2 到 192.168.88.127 中间的空闲地址,避开 DHCP 池,以免以后有其他虚拟机通过 DHCP 拿到同一个 IP 造成冲突。
DNS 也要规划好。NAT 模式下一般由 DHCP 自动分配 DNS,通常是虚拟网络网关地址,这个地址本身带有 DNS 转发功能,虚拟机用它就能解析外网域名。如果你手动配置静态 IP,DNS 就不要乱留空,至少写一个虚拟网络网关地址,再加一个公共 DNS 兜底。否则你很可能遇到 IP 能 ping 通网关、ping 通外网 IP,但域名解析不了的情况。
2.3 Linux 宿主机上的防火墙与路由检查
既然虚拟机是跑在 Linux 宿主机上的,那宿主机自身的网络状态就会直接影响虚拟机的网络体验。配置虚拟机网络之前,先把宿主机的这几个点查一遍。
第一个是 IP 转发。虽然桌面虚拟化软件的 NAT 服务通常由平台自己实现,宿主机内核转发并不总是刚需,但如果你是用 KVM/libvirt 这类的虚拟化方案,或者你在宿主机上自己做了 NAT 规则,那 IP 转发必须开启。检查命令是:
sysctl net.ipv4.ip_forward如果返回 1 说明已开启,返回 0 就临时打开:
echo 1 > /proc/sys/net/ipv4/ip_forward永久开启就编辑 /etc/sysctl.conf,设置net.ipv4.ip_forward = 1,然后sysctl -p生效。
第二个是防火墙。Linux 宿主机上如果跑着 firewalld 或 iptables,它可能会拦截虚拟网卡上的流量。我遇到过的情况是:虚拟机 N 模式 ping 外网正常,但宿主机想通过 SSH 连虚拟机却连不上,最后发现是宿主机防火墙没有放行对应虚拟网卡接口的访问。排查的时候可以先临时把防火墙对虚拟网卡区域的策略放开,或者查看 firewalld 的 zone 里是否包含了虚拟网卡接口。
firewall-cmd --list-all nmcli connection show第三个是查一下宿主机上有哪些虚拟网卡接口。桌面虚拟化平台创建网络时会自动添加 vnet 或 vmnet 开头的接口,你用ip addr看一眼,确认 VMnet1、VMnet8 对应的接口状态是否 up。如果虚拟网卡接口被系统 NetworkManager 拉到别的 zone,或者接口没有被正确激活,虚拟机网络也会表现异常。
这些检查看起来零碎,但只要宿主机网络环境比较干净,虚拟机网络问题少一半。
3. 三种模式下,Linux 虚拟机内的配置实操
原理和规划讲完,进入动手环节。我按桥接、NAT、仅主机三种模式分别给出完整的配置实例。Linux 发行版很多,配置方式分两套主流:一套是 RHEL/CentOS/Fedora 系的 nmcli 或 NetworkManager,另一套是 Ubuntu/Debian 系的 netplan 或 /etc/network/interfaces。下面的例子两者都会给,方便对照。
3.1 桥接模式实例:给 Linux 配一个局域网同网段静态 IP
第一步,在虚拟网络编辑器里确认桥接设置。把桥接模式关联到实际联网的物理网卡上。如果宿主机是用网线上网的,就选有线网卡;如果用 WiFi 上网,就选无线网卡。选错的话,虚拟机接入了错误的物理链路,后面配置逻辑完全没意义。
第二步,在虚拟机的网络设置里,把网络适配器改成桥接模式。
第三步,在宿主机上查看真实网络的 IP、网段和网关:
ip addr ip route假设宿主机 IP 是 192.168.1.100/24,网关是 192.168.1.1。
第四步,进入 Linux 虚拟机内部,用 nmcli 配置静态 IP。先看当前的网卡名和连接名:
ip addr nmcli device status nmcli connection show假设网卡设备名是 ens33,连接名是 ens33,那配置命令是:
nmcli con mod ens33 ipv4.method manual \ ipv4.addresses 192.168.1.101/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns "192.168.1.1 223.5.5.5" nmcli con up ens33如果是 Ubuntu 用 netplan,则编辑 /etc/netplan/ 下对应的 yaml 文件:
network: version: 2 ethernets: ens33: dhcp4: false addresses: - 192.168.1.101/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 192.168.1.1 - 223.5.5.5然后执行sudo netplan apply。
配置完成后,验证顺序很重要:先 ping 网关ping 192.168.1.1,再 ping 外网 IPping 223.5.5.5,最后 ping 域名ping linux.org。哪一步不通,问题就锁定在哪一段。如果网关能通但外网 IP 不能通,多半是物理网络限制;如果外网 IP 能通但域名不能通,就是 DNS 的问题。
这里我多说一句:桥接模式下,静态 IP 一定要避开局域网里已经存在的地址。我遇到过有人把虚拟机 IP 配成和宿主机一模一样,结果两台机器 MAC 和 IP 都冲突,局域网里瞬间一片混乱。选 IP 前先 ping 一下这个地址,如果没人回应再使用。
3.2 NAT 模式实例:使用默认网段与端口转发
NAT 模式我不建议一上来就配静态 IP,更不要改来改去。先把 DHCP 跑通,再考虑固定地址。
第一步,在虚拟网络编辑器里查看 VMnet8 的网段、网关和 DHCP 地址池。假设网段是 192.168.88.0/24,网关是 192.168.88.2,DHCP 池是 192.168.88.128 到 192.168.88.254。
第二步,在虚拟机设置里选择 NAT 模式。
第三步,在 Linux 虚拟机里把网卡改成 DHCP 获取。nmcli 环境:
nmcli con mod ens33 ipv4.method auto nmcli con up ens33Ubuntu netplan 环境就把 dhcp4 设为 true:
network: version: 2 ethernets: ens33: dhcp4: true然后sudo netplan apply。查看获取到的 IP:
ip addr ip route正常情况下虚拟机应该拿到 192.168.88.128 之类的地址,网关是 192.168.88.2。此时虚拟机已经能上网了,你可以在里面ping 223.5.5.5验证。
如果你希望 IP 固定下来,可以在 NAT 网段里挑一个 DHCP 池外的地址,比如 192.168.88.100,再按桥接模式里讲到的静态 IP 方式配置,网关写 192.168.88.2。
NAT 模式还有一个很实用的功能:端口转发。默认情况下,外部设备无法直接访问 NAT 模式下的虚拟机,但通过端口转发,你可以把宿主机上的某个端口映射到虚拟机的某个端口。比如把宿主机的 2222 端口映射到虚拟机的 22 端口,这样别人只要 SSH 到宿主机的 2222 端口,就能连到虚拟机的 SSH 服务。
具体做法是在虚拟网络编辑器里找到 NAT 设置,添加一条端口转发规则:宿主机端口 2222,协议 TCP,目标地址 192.168.88.100,目标端口 22。然后从宿主机验证:
ssh -p 2222 user@127.0.0.1如果宿主机开启了防火墙,记得放行 2222 端口的入站访问。这个能力在做实验的时候特别有用:既能保持 NAT 的隔离性,又能按需暴露指定的服务。
3.3 仅主机模式实例:搭建一个多虚拟机内部网络
仅主机模式最适合搭多虚拟机内部网络。我举个例子:假设你要做一个 3 节点的内部测试集群,节点之间要互相通信,但不需要访问外网。
第一步,在虚拟网络编辑器里确认 VMnet1 的网段,假设是 192.168.99.0/24,宿主机在这个网段里的地址是 192.168.99.1。
第二步,把几台虚拟机的网络适配器都设为仅主机模式。
第三步,在每台 Linux 虚拟机里配置同一网段的静态 IP。比如 node1 配 192.168.99.11,node2 配 192.168.99.12,node3 配 192.168.99.13。网关可以不写,因为内网互通不需要默认路由;DNS 也不写,因为没有外网。
nmcli 配置示例:
nmcli con mod ens33 ipv4.method manual \ ipv4.addresses 192.168.99.11/24 nmcli con up ens33netplan 配置示例:
network: version: 2 ethernets: ens33: dhcp4: false addresses: - 192.168.99.11/24配置完成后,在宿主机上 ping 虚拟机:
ping 192.168.99.11在 node1 里 ping node2:
ping 192.168.99.12如果互通正常,说明这个封闭内网已经成立。你可以把这几台虚拟机当成一个小型试验场,模拟各种需要内网通信的服务,而它们对外完全没有暴露面。
这里有一个细节:仅主机模式下,如果虚拟机里跑了 DHCP 客户端,它可能拿到 VMnet1 的 DHCP 池地址,也可能因为 DHCP 租约问题导致 IP 反复变动。所以凡是需要稳定的内网节点,我建议直接配静态 IP,不用 DHCP。
4. 遇到过的常见问题与排查实录
实战中最有价值的不是怎么配置,而是出了问题怎么定位。下面这几个问题,我基本每次带人搞虚拟机网络都会碰到,整理成排查速查表供参考。
4.1 桥接模式连不上外网
现象:虚拟机选了桥接模式,能拿到或能配上和宿主机同网段的 IP,但 ping 网关不通。
排查思路:先用ip addr确认虚拟机的 IP、掩码、网卡状态都是正常的。如果 IP 没问题,ping 网关都不通,说明二层链路有问题。这时候去虚拟网络编辑器里看桥接选择的是不是宿主机实际联网的物理网卡。宿主机如果用的 WiFi,无线 AP 的 AP 隔离很致命,它会把同一无线网络下的不同设备隔离开,导致虚拟机虽然和宿主机在同一网段,但互相不通信。解决方式是改用有线网络,或者关掉路由器的 AP 隔离,或者干脆换 NAT 模式绕过这个问题。
还有一个很隐蔽的坑:宿主机上有多个网络接口时,虚拟机的桥接网络会默认桥接到一个不在用的网卡上。你在虚拟网络编辑器里必须手动把桥接指向当前有网络的接口,别相信默认值。
4.2 NAT 模式拿不到 IP 或 DNS 解析失败
现象:虚拟机选 NAT 模式,DHCP 获取不到地址,或者能拿到地址但域名解析不了。
拿不到 IP,先检查虚拟化平台的 DHCP 服务有没有正常工作,VMnet8 接口在宿主机上是不是 up 状态。虚拟机内部可以手动dhclient ens33再触发一次获取。如果还是不行,就检查 NetworkManager 和 systemd-networkd 是不是在抢网络接口的控制权,两个网络管理服务同时管同一个接口,必然会出现各种怪问题。我建议统一用 NetworkManager,systemctl status NetworkManager看一眼。
域名解析失败的情况:IP 能 ping 通外网 IP,但ping baidu.com解析不出来。这种问题基本就是 DNS 没配置对。用cat /etc/resolv.conf看 DNS 指向哪里,NAT 模式下通常应该设置为虚拟网络网关地址。如果 resolv.conf 被 NetworkManager 托管,就直接用 nmcli 设置:
nmcli con mod ens33 ipv4.dns "192.168.88.2 223.5.5.5" nmcli con up ens334.3 仅主机模式互 ping 不通
现象:宿主机和虚拟机、虚拟机之间,明明都配了同一个网段的 IP,但互相 ping 不通。
最常见的原因是网段不一致。仅主机模式的默认网段和自定义 VMnet 的网段可能不一样,如果你把 A 虚拟机挂到了 VMnet1,把 B 虚拟机挂到了自定义 VMnet2,那它们虽然 IP 看起来都是 192.168.x.x,但根本不在同一个二层网络里,当然不通。解决办法是把所有需要互通的虚拟机都选择同一个虚拟网络,再逐个确认 IP 在同一个网段。
其次是宿主机的虚拟网卡接口没有激活。用ip addr看宿主机上的 VMnet1 接口是不是 down 状态,如果是,就把它 up 起来。
再就是防火墙。Linux 虚拟机里的 firewalld 或者 ufw 默认可能拦截 ICMP,你 ping 不通但不一定代表网络不通。可以先临时关防火墙验证:sudo systemctl stop firewalld或者sudo ufw disable,如果通了,那就是防火墙规则的问题,然后再按需放行。
4.4 重启后 IP “消失”
现象:配置好的静态 IP,虚拟机重启之后不见了,又变成 DHCP 自动获取的地址,或者干脆没有 IP。
这种问题十有八九是网络管理工具的问题。比如你用 nmcli 配置静态 IP,但接口实际并不是由 NetworkManager 管理;或者你用 netplan 配置后 apply 成功了,但文件写错了名字,系统启动时没有读取到。排查时先运行nmcli connection show,看设备的连接是否活跃,再检查连接配置里 ipv4.method 是否真的变成了 manual。
还有一个细节:RHEL 系虚拟机里,网卡设备名可能叫 ens33、ens160、eth0,不同模板还不一样,配置时一定要以ip addr显示的实际设备名为准。我见过有人复制了一个配置文件,里面仍然写着 ens33,但实际设备是 ens160,结果系统启动时接口起不来。
常见问题速查表:
| 问题现象 | 可能原因 | 排查命令与解决思路 |
|---|---|---|
| 桥接 ping 不通网关 | 物理网卡选错、AP 隔离、MAC 绑定 | ip addr检查 IP;打开虚拟网络编辑器重选桥接网卡 |
| NAT 拿不到 IP | DHCP 未启动、两个网络管理服务冲突 | systemctl status NetworkManager;dhclient ens33重试 |
| NAT 能上网但域名不通 | DNS 配置错误 | 查看 /etc/resolv.conf,用 nmcli 重设 DNS |
| 仅主机互 ping 不通 | 网段不一致、防火墙拦截 | 检查各虚拟机网卡挂在哪个 VMnet;临时关防火墙测试 |
| 重启后 IP 变了 | IP 配置没生效、设备名不对 | nmcli connection show确认连接;用实际网卡设备名配 |
5. 选型思路与避坑心得
最后这部分,我把自己的选型习惯和一些容易忽略的细节汇总一下。没有说教的成分,纯粹是实操久了之后的经验沉淀。
5.1 如何为不同实际需求选择合适的网络模式
很多时候不是单一模式能解决所有问题,而是要混合用。我自己做环境规划时,一般按这个逻辑判断:
如果虚拟机要作为一个对外服务的节点,比如搭测试用的 Web 服务、SSH 跳板、代码仓库,就选桥接。它被局域网直接访问,链路最干净,没有 NAT 转发的性能损耗和端口转发限制。
如果只是需要上网拉包、跑脚本、做临时测试,选 NAT 最省事。它不占用真实局域网 IP,不受外部网络切换影响,虚拟机内部的服务默认不暴露,安全边界比较清晰。
如果要做内部集群、离线环境、多节点通信实验,选仅主机。它把虚拟机圈在一个封闭网络里,互相能通信,外网进不来,也出不去,环境可重复性强。
复杂一点的场景,可以给虚拟机加两块虚拟网卡,一块 NAT 用来访问外网下载软件包,一块仅主机用来和集群内部通信。这种组合很常见,比如你要做一个“某内部集群系统”,每个节点既要能访问外网安装依赖,又要保证节点之间的内网通信,那就这么配。两块网卡的 IP 别混在一起,外网走 NAT 的默认路由,内网走仅主机网段,路由表会自动处理。
5.2 一些容易忽略的细节
细节一:虚拟机的网卡类型。同一台 Linux 虚拟机,网卡类型选择不同,识别出来的设备名和驱动可能有差异。比如在物理机上常用 e1000e 或 virtio,如果遇到设备名不叫 eth0 而是 ensX,配置时一定要看系统实际识别的结果,别照抄文档里的接口名。
细节二:MAC 地址。克隆虚拟机或者复制模板后,如果多个虚拟机的 MAC 地址一样,它们在同一虚拟网络里会冲突,表现就是网络时通时断。新建虚拟机时重新生成 MAC,或者在克隆后顺手改掉。这个坑我在批量创建测试节点时踩过,当时几台机器随机轮流断网,查了很久才发现是 MAC 重复。
细节三:DNS 优先级。虚拟机里如果配置了多个 DNS,系统会按顺序尝试解析。如果你把内网 DNS 写在前面,公共 DNS 写在后面,而内网 DNS 又对某些外网域名解析不稳定,就会出现“时好时坏”的现象。可以先用nslookup测试具体域名,再调整 DNS 顺序。
细节四:宿主机休眠和网络恢复。Linux 宿主机休眠后再唤醒,虚拟网络有时会变得不正常,尤其是桥接模式下的虚拟网卡会丢链路。这种情况最简单的办法是把网络适配器在虚拟机设置里禁用再启用一次,或者直接重启虚拟机,通常就能恢复。
细节五:NAT 网关能 ping 通但外网还是不通,很可能是虚拟化平台的 NAT 服务进程没有起来。在 Linux 宿主机上可以用ps aux | grep nat看相关进程是否存在,如果没起来,重启虚拟化平台的网络服务,或者重启软件界面,一般能恢复。
我的个人习惯是:新建虚拟机后,不管最终要用什么模式,先开机用 NAT + DHCP 把系统装好、软件源配好、网络验证通。再根据实际用途切换模式、配静态 IP。这样一来,即使后期配错,也能快速切回 NAT 恢复环境,不会把自己锁死。另外,虚拟网络编辑器里的网段我总会手动改成不和真实局域网重复的段,这可能是让我少排查最多问题的一个小习惯。