★ FEATURED ARTICLE 搞虚拟化的朋友应该都有过这种经历——Linux宿主机上创建VM倒是顺利结果一配网络就抓瞎了。不是VM上不了网就是外部访问不进来甚至两台VM之间谁也ping不通谁。到最后只能来回翻文档、反复重建虚拟网卡一个晚上的时间全耗在这上面。其实这些问题八成出在没搞懂“VM网络模式”的选型逻辑。VM在Linux上的网络模式就那几种NAT、桥接、主机模式、内部网络但它们各自解决的问题、适用的场景、配置的坑完全不一样。今天我就把这几种模式掰开揉碎了讲一遍配上我在实际环境里的配置过程和踩坑记录帮你在Linux上把VM网络一次性配明白。先说一下这篇内容的定位适合刚接触虚拟化、想在Linux宿主机上部署VM的人参考也适合被VM网络折腾过几次、想系统梳理基础原理的人。点亮几个核心关键词——VM网络模式、Linux桥接、NAT转发、KVM/libvirt场景。这些概念都不复杂但组合起来用就有很多门道了。1. VM网络模式全景拆解与设计初衷1.1 为什么虚拟化平台非要分出“几种模式”很多人在配置VM网络的时候有个疑惑物理机上插根网线就能上网虚拟机为什么不能直接照搬这个逻辑原因在于虚拟机的“网卡”并不是真实网卡而是宿主机内核虚拟出来的设备它必须经过宿主机这一层的转发才能和外网通信。问题是转发的方式有好几种不同的转发方式直接决定了VM能访问谁、谁能访问VM以及VM和VM之间怎么通信。虚拟化平台做这几种网络模式本质上是在回答三个问题VM要怎样才能访问宿主机之外的世界宿主机之外的世界要怎样才能访问到VMVM之间以及VM与宿主机之间应该用什么样的隔离和连通规则NAT模式、桥接模式、主机模式、内部网络这四种恰好对应了四套不同的“回答”。它们不是谁比谁高级而是互相补充分别服务于不同的使用场景。打个比方你就明白了。NAT模式就像小区统一设了一个带门禁的传达室所有住户VM必须通过传达室进出外人想进小区必须提前登记由传达室帮你传话桥接模式则像沿街商铺每家门都直接开在马路边谁都能直接进来访问你主机模式像地下室的独立保险间外面的人进不来你得亲自带钥匙进去操作。这样一想模式之间的区别就非常直观了。1.2 选择网络模式前要想清楚的三个维度动手配置之前先用三个维度把需求捋一遍能帮你少走不少弯路。第一是流量方向。你的VM是需要主动访问外网比如要下载软件包、跑脚本调外部接口还是需要被外部主动访问比如跑Web服务、对外提供数据库端口如果只需要出方向流量NAT模式足够如果需要入方向访问多半得桥接模式。这两个方向涉及完全不同的转发规则不能混为一谈。第二是IP管理方式。用NAT模式时VM的IP段由宿主机虚拟网络统一分配和管理通常是私网段和物理网络完全隔离你不需要关心宿主机所在局域网的网段规划桥接模式则要求VM直接使用物理局域网里的IP段必须和真实网段保持一致还得注意IP冲突问题。第三是隔离等级。如果VM只是临时调试用完全不想让它接触外网就选主机模式或者内部网络。如果是生产环境对外提供服务就得选桥接模式。隔离等级直接关系到后续的安全策略和防火墙配置选高还是选低完全取决于你的用途。1.3 Linux上主流的VM网络实现方式在哪一层实现Linux上的VM网络功能可能运行在用户态也可能运行在内核态取决于你用的虚拟化方案。以最常见的KVM/QEMU加libvirt管理栈为例NAT模式主要由内核网络栈配合iptables规则实现桥接模式则依赖内核的Linux Bridge模块或网桥复用物理网卡。而在一些容器场景或者使用用户态网络协议栈时网络虚拟化又会以用户态进程的方式实现。但无论底层实现怎么变系统给你暴露出来的“虚拟网卡”和“虚拟网络”概念是稳定的。你在配置界面里选择“桥接模式”或“NAT模式”时底层对应的是创建虚拟网桥、挂载TAP设备、配置路由和NAT规则这一整套动作。理解这一层后面操作起来就不会觉得配置是“黑盒”。2. 关键模式逐项拆解与适用场景2.1 NAT模式最省心但只适合“单向出网”的场景NAT模式在libvirt里对应的是默认网络宿主机上体现为一个名为virbr0的虚拟网桥网段通常是192.168.122.0/24。VM通过这个网桥接入一个私有的隔离网络宿主机再通过iptables的MASQUERADE规则把VM出网的流量做源地址转换让它以宿主机的IP和外网通信。这个模式最大的好处是“零配置就能上网”。你创建一个新VM只要选用了默认网络启动之后就能拿到一个内网IP然后就能通过宿主机访问外网。对于需要下载依赖包、更新系统、做基础开发测试的VM来说这是最方便的模式。但它有个明显的边界VM可以被访问吗可以但需要额外配置DNAT端口转发规则而且每次VM重启IP如果有变化转发规则就要跟着改非常麻烦。所以NAT模式适合“VM主动向外访问”的场景不适合“外部需要主动访问VM”的场景。我实际用NAT模式最多的场景是批量创建测试VM。比如某次为了验证一个多节点分布式脚本我在一台Linux服务器上同时起了六台VM全部用NAT模式接入同一个默认网络它们之间通过虚拟网桥互通同时都能访问宿主机外网去拉取组件包。整个过程完全不需要操心物理网络环境的干扰非常干净。2.2 桥接模式让VM变成局域网里的“一台真机”桥接模式做的事情可以用一句话概括把宿主机物理网卡接收到的网络流量直接“复制”一份给VM的虚拟网卡。从局域网其他设备的角度来看这台VM和宿主机一样都是一台独立的、拥有自己IP地址的主机用ARP协议就能找到它。这个模式解决的最大问题是“外部主动访问VM”。比如你在VM里跑了一个Web服务希望局域网里的同事直接通过浏览器访问用NAT模式需要配端口转发而桥接模式直接让VM拿一个和宿主机同一网段的IP对方访问这个IP就行和访问一台物理机毫无区别。桥接模式的关键在于宿主机网卡的处理方式。通常的做法是把物理网卡加入一个Linux网桥然后在这块物理网卡上不配置IPIP地址转移到网桥接口上VM的虚拟网卡也挂到这个网桥下面。这样网桥就充当了二层交换机物理网卡只是作为上行链路口。需要留意的是桥接模式的VM会直接占用物理局域网的IP资源而且IP地址需要和物理网络保持一致通常用DHCP来分配但DHCP地址池如果比较紧张就可能出现抢IP的问题。另外如果宿主机处于一个安全性要求较高的网络环境里桥接模式会直接把VM暴露给整个局域网需要格外注意VM自身的加固和防火墙。2.3 主机模式与内部网络把“隔离”做到极致主机模式在libvirt里通常对应一种isolated网络指的是VM只能和宿主机通信不能访问外网也不能被外网访问。它的实现方式是在宿主机上创建一个没有NAT转发规则的虚拟网桥VM接入这个网桥宿主机也接入这个网桥但网桥没有出向物理网卡的上行链路。于是整个通信范围被限制在“VM 宿主机”这个小圈子内。这个模式的典型场景是安全调试。比如我在分析一个可疑的二进制程序时会把它放进主机模式网络的VM里运行。这样即使程序真的去做恶意外联由于没有出向链路它也无法把数据传出去而我仍然可以通过宿主机和VM之间的通道安全地观察程序的行为。内部网络则更严格一点它只允许VM之间互相通信连宿主机都不参与。这个模式适合搭建完全离线的虚拟集群环境比如模拟一套内部服务网格所有节点互相通信但和宿主机及外网完全隔离。这两种模式的应用面虽然不像NAT和桥接那么广但在特定场景下是不可替代的。尤其当你需要构造一个“干净、可控、无干扰”的网络环境时它们比NAT模式更彻底。2.4 四种模式的核心对比表这里把四种模式的关键差异整理成一张表配置之前对照着选型会非常清晰模式虚拟机访问外网外网访问虚拟机虚拟机访问宿主机虚拟机之间通信典型场景NAT模式通过宿主机的内核对底层网络做源地址转换可以出网需额外配置DNAT端口转发不方便默认可以同一个NAT网络内互通开发测试、下载依赖、沙箱验证桥接模式跟物理机一样直接访问局域网局域网内其他设备可直接访问VM可以同一局域网内为平等关系局域网内IP互通依赖网络环境对外提供服务、需要被外部主动访问主机模式不能访问外网外部无法访问只能访问宿主机宿主机可访问VM同网络内VM互通安全调试、离线环境模拟内部网络不能访问外网外部无法访问宿主机也不能访问同网络内VM互通全隔离集群模拟、内部组网测试这四种模式几乎覆盖了日常使用VM的全部网络需求。实操中我发现很多人配置网络失败不是因为某个模式本身配置多复杂而是没搞清楚自己到底“应该选哪个模式”拿着桥接的思维去搞NAT自然越配越乱。3. Linux宿主机上实操配置全过程3.1 实操环境说明与网络资源规划这次实操我基于KVM/QEMU配合libvirt管理栈来演示这也是Linux上最主流的开源虚拟化方案。宿主机系统为常见Linux发行版已经装好libvirt和相关工具。开始之前先规划一下这次的模拟项目需求我需要一台NAT模式VM用来做日常开发测试一台桥接模式VM用来跑一个对外提供Web服务的应用还有一台主机模式VM用来做隔离调试。整个规划对应到宿主机网络资源上需要三套虚拟网络default网络NAT模式libvirt默认自带网段192.168.122.0/24br0网桥桥接模式桥接物理网卡eth0isolated网络主机模式自定义虚拟网桥不接外部3.2 查看宿主机当前网络状态规划虚拟网络动手之前先把宿主机当前的网络状态摸清楚。使用一组基础命令即可ip link show ip addr show重点确认物理网卡的名称通常是eth0或enp2s0以及宿主机当前使用的IP地址和网段。这些信息直接决定桥接模式里网桥的配置方式。另外确认一下系统防火墙和转发开关的状态sysctl net.ipv4.ip_forward cat /proc/sys/net/ipv4/ip_forwardNAT模式正常工作的前提是net.ipv4.ip_forward1。如果输出结果是0需要开启echo 1 /proc/sys/net/ipv4/ip_forward注意这只是临时生效重启后会丢失。要永久生效在/etc/sysctl.conf中添加net.ipv4.ip_forward1然后执行sysctl -p即可。这个设置很关键很多人NAT模式下VM能ping通网关却上不了外网查来查去就是卡在这里。3.3 创建NAT模式的虚拟网络基于默认网络libvirt安装时会自动生成一个名为default的NAT网络对应的xml定义通常是下面这样network namedefault/name forward modenat nat port start1024 end65535/ /nat /forward bridge namevirbr0 stpon delay0/ ip address192.168.122.1 netmask255.255.255.0 dhcp range start192.168.122.2 end192.168.122.254/ /dhcp /ip /network这个定义里forward modenat就是NAT模式libvirt会自动创建virbr0网桥并在宿主机上生成对应的iptables规则。平时我们用默认设置就行不需要额外手动配置。启动它virsh net-list --all virsh net-start default virsh net-autostart default创建VM时指定网络参数为networkdefault即可。比如用virt-install创建VM时加上--network networkdefault,modelvirtio网卡模型这里我建议直接用virtio而不是默认的e1000。virtio是半虚拟化I/O模型性能比模拟e1000高很多尤其是在大流量场景下差距非常明显。后面讲到性能优化时我会再展开。3.4 配置桥接模式把物理网卡交给Linux网桥桥接模式的配置相对复杂一些核心是把物理网卡加入一个Linux网桥。这里结合我的实际操作记录一下步骤。先创建一个网桥br0ip link add name br0 type bridge ip link set br0 up然后把物理网卡eth0加入网桥ip link set eth0 master br0此时eth0原有的IP地址会失效需要把原来配置在eth0上的IP地址转移到br0上。比如原来eth0的IP是192.168.31.47ip addr add 192.168.31.47/24 dev br0 ip addr del 192.168.31.47/24 dev eth0这样宿主机对外仍然表现为192.168.31.47但由于IP挂在br0上所有到达物理网卡的流量都会经过br0的交换逻辑VM的虚拟网卡也挂进br0后就能直接和物理网络里的其他设备通信了。这里有一个高频坑必须提醒很多Linux发行版默认用NetworkManager管理网络。如果你直接用了ip命令把物理网卡加入网桥NetworkManager很可能会在重启网络服务或者重连网卡的时候把物理网卡直接从网桥里踢出来。我踩过好多次这种坑表现就是宿主机重启后VM桥接网络失效物理网卡恢复成独立状态。解决思路有两种。一是在创建网桥之前先用nmcli把物理网卡的管理方式改成“不被NetworkManager接管”nmcli device set eth0 managed no二是直接用nmcli来创建网桥连接让NetworkManager统一管理网桥和物理网卡。我个人更推荐第二种方式尤其在生产环境中能被系统统一管理的网络配置才是持久可靠的。nmcli创建桥接连接的示例nmcli connection add type bridge ifname br0 con-name br0 ipv4.method manual ipv4.addresses 192.168.31.47/24 ipv4.gateway 192.168.31.1 ipv4.dns 192.168.31.1 nmcli connection add type bridge-slave ifname eth0 master br0 nmcli connection up br0用nmcli初始化后网桥连接就变成了系统网络配置的一部分重启不丢也比手动改配置干净很多。在设置了网桥的网络环境里VM创建时指定--network bridgebr0,modelvirtio3.5 配置主机模式和内部网络的虚拟网络主机模式在libvirt里配置也很直接无非就是创建一个没有forward定义的内部虚拟网络然后只把宿主机接入进去。下面是用virsh创建网络定义的方式先编辑一个isolated.xml文件network nameisolated/name bridge namevirbr1 stpon delay0/ ip address192.168.200.1 netmask255.255.255.0/ /network导入并启动这个网络virsh net-define isolated.xml virsh net-start isolated virsh net-autostart isolated注意这个定义没有forward元素所以它不会做地址转换VM和宿主机都在同一个内部网段但不具备出网能力。如果要让VM之间互通只需要让它们都在同样的网络里VM的网络参数指定为--network networkisolated,modelvirtio如果完全不想让宿主机参与通信那就定义内部网络时不设置ip地址只保留bridge元素这样宿主机虽然创建了网桥但不会给自己分配IPVM之间能互通VM和宿主机之间则完全隔离。3.6 动态修改VM网络接口的实用操作有时候VM已经创建好了才发现网络模式选错了需要动态加网卡或者换网络。这里分享几个常用的virsh操作。给运行中的VM挂载一块新的虚拟网卡指定网络模式和网卡模型virsh attach-interface --domain 测试VM --type network --source 网络名 --model virtio --config --live比如给名为“ubuntu-test”的VM追加一块桥接网卡virsh attach-interface --domain ubuntu-test --type network --source br0 --model virtio --config --live拆掉一块现有网卡需要先查到网卡的mac地址virsh dumpxml ubuntu-test | grep -A 5 interface然后根据mac地址卸载virsh detach-interface --domain ubuntu-test --type network --mac 52:54:00:xx:xx:xx --config --live动态挂载的好处是你可以先按默认方式创建VM启动后确认网络环境再决定是否加第二块网卡。比如我在调试混合网络时常常给同一台VM同时挂NAT网卡和内部网络网卡通过iptables策略控制流量走向非常灵活。4. 连通性验证、性能优化与安全边界4.1 网络配置好之后的验证清单配置完网络第一件事不是急着跑业务而是先验证连通性。我一般按下面这个顺序排查每个环节都有明确的检查目标和命令。第一步在宿主机上确认虚拟网桥已经创建并且网桥状态是UP。重点看接口是否已经挂到预期的网桥下ip link show type bridge ip link show master br0 brctl show第二步在VM内部确认虚拟网卡拿到了预期的IP地址、有默认路由。这步可以在VM里面执行ip addr show ip route show第三步逐层测试连通性。先在VM里ping宿主机上的虚拟网关比如NAT网络的192.168.122.1再ping宿主机物理网卡所在网段的IP最后ping一个公网IP。每一步都能帮你判断问题出在哪一层ping不通虚拟网关说明虚拟网卡或者网桥链路有问题能ping通网关但ping不通宿主机物理IP可能是路由或者同网段转发问题能ping通宿主机但ping不通公网IP大概率是NAT规则、ip_forward开关或系统防火墙的问题4.2 NAT模式转发链路解析一条流量走到外网的全过程为了更清楚地排查问题值得看一下NAT模式下VM的流量到底是怎么出去的。以VM192.168.122.10访问一个公网IP为例完整的链路如下VM内发起网络请求目标IP是公网地址数据包到达VM的虚拟网卡转发到宿主机上的virbr0网桥内核看到目标IP不是本机网段查路由表发现默认路由走物理网卡出口数据包经过iptables的POSTROUTING链时被MASQUERADE规则做源地址转换源IP从192.168.122.10变成宿主机的物理网卡IP数据包从物理网卡发出访问公网响应包回来时内核根据连接跟踪表把目标IP改回192.168.122.10然后交给virbr0最终送达VM这个链路中任何一个环节断裂都会导致VM访问外网失败。常见的断点有三个第1步VM没有配置正确的网关第2步虚拟网桥没有正确创建第4步NAT规则或ip_forward失效。排查时按链路顺序挨个验证很快就能定位。顺手说一下MASQUERADE和SNAT的区别。MASQUERADE是SNAT的一种动态变体它不需要手动指定源IP自动使用出口网卡的当前IP做转换所以很适合DHCP动态获取IP的宿主机环境。如果宿主机IP是静态的直接用SNAT指定源地址也没有问题两者在NAT模式下的效果是一样的。4.3 桥接模式链路解析二层通行为什么三层不通桥接模式的通信路径要简单得多。VM的虚拟网卡和物理网卡都挂在同一个网桥上网桥工作在二层所以VM发出的数据帧会直接从物理网卡转发到局域网。这个模式速度更快延迟也更低但前提是局域网的IP规划允许。实际中最常见的问题是VM通过DHCP拿到了IP但ping网关不通。问题往往出在“混在二层里的三层能力”上。比如局域网里的网关设备配置了DHCP Snooping、端口安全或者动态ARP检测从虚拟机发出的数据帧很可能因为MAC地址和IP地址的绑定关系没被识别而被网关直接丢弃。这种情况不是Linux配置层面的问题而是物理网络策略导致的。排查时可以先看一下VM能不能ping通局域网里另一台普通设备如果能通而只有网关不通基本可以确认是物理网络设备有MAC或ARP层面的安全策略限制。另一个常见问题是有线网卡确实加入了网桥但宿主机上开了firewalld而firewalld对网桥流量的默认处理策略可能导致桥接流量被拦截。可以通过检查net.bridge相关内核参数来确认sysctl net.bridge.nf-call-iptables如果这个值是1桥接流量会经过iptables规则过滤防火墙策略设置不当就会阻断VM流量。常驻虚拟化环境的话建议明确规划防火墙对网桥流量的处理规则避免踩这个隐形坑。4.4 性能优化VM网络卡顿和延迟高的几个调整点VM网络性能问题很大程度上和网卡模型有关。KVM默认的网卡模型通常在兼容性上做得很好但性能会有比较大的损失。生产环境或者跑高流量业务的VM我强烈建议换成virtio网卡模型。virtio的好处在于它让虚拟机直接使用宿主机内核提供的virtio环形缓冲区机制进行通信绕开了硬件的模拟层。简单说网络IO不再需要经过昂贵的上下文切换和设备模拟吞吐量提升非常明显特别是在小包高并发的场景下性能差距能有数倍。创建一个使用virtio网卡的VMvirt-install --name perf-vm --ram 4096 --vcpus 4 --disk path/var/lib/libvirt/images/perf-vm.qcow2 --network networkdefault,modelvirtio ...如果VM已经创建想查看当前使用的是哪种网卡模型virsh dumpxml 你的VM名 | grep -A 2 interface type在model属性中能看到是virtio还是e1000。如果要改成virtio需要编辑VM配置virsh edit 你的VM名在对应的model行改为model typevirtio/改完重启VM生效。另外宿主机CPU支持的话可以考虑给VM网络开启多队列特性把虚拟网卡的队列数分配到多个CPU核心进一步提升并发性能。但这步对普通用户来说不是必需项如果业务流量不大用默认配置完全够用。4.5 安全边界网络模式本身不是安全策略选择网络模式时有一个容易混淆的认知很多人觉得NAT模式天然安全桥接模式一定危险。这个说法太绝对了。网络模式解决的是“连通边界”而安全策略解决的是“允许什么流量”。NAT模式只是让外部发起主动访问的难度提升了但它内部仍然有虚拟网桥VM之间依然可以互通如果VM出网后访问了恶意站点该进来的恶意流量一样能进来。桥接模式确实把VM直接暴露在局域网中但这不意味着不能安全使用。关键在于给VM配好防火墙规则关掉不需要的端口及时更新补丁。反过来主机模式虽然隔离性极强但也要小心“隔离网”里传输的敏感数据因为它仍然有一条共享的虚拟通道。我一般给的统一建议是先用网络模式圈定连通范围再在宿主机和VM两个层面配置防火墙规则两者配合才能形成可用的安全边界。单靠某一个模式解决安全问题往往靠不住。5. 常见问题速查表与独家排错心得5.1 六个高频问题的快速定位方式做虚拟化时间长了遇到的问题来来回回就那几种。这里整理一个速查表覆盖我工作中出现频率最高的VM网络问题问题现象可能原因快速处理方式VM ping不通宿主机网关VM内网卡未启动/网关配置错误在VM内检查ip route确认默认网关指向虚拟网络网关地址NAT模式VM无法访问外网ip_forward未开启在宿主机执行sysctl net.ipv4.ip_forward如果为0则临时设置或写入持久化配置NAT模式VM能出网但外部无法访问VM入方向没有DNAT规则在宿主机配置iptables端口转发规则把物理端口映射到VM内网IP桥接模式VM上不了网物理网卡未正确加入网桥或NetworkManager接管了物理网卡用nmcli重新配置网桥确认物理网卡处于网桥从设备状态宿主机重启后桥接配置丢失手动ip命令配置没有持久化改用NetworkManager或系统网络脚本配置网桥VM之间跨不同虚拟网络无法互通不同虚拟网桥之间没有路由在宿主机上添加路由规则或在有路由能力的设备上做互通上面这些问题的共同特征是你不是真的“不会配”而是配置过程中某个细节被系统的默认行为覆盖了。所以排查时我强烈建议先确认“系统的网络管理工具是不是在和你抢控制权”这条经验关键时刻很省时间。5.2 一条实用排错路线从物理链路一路向上遇到VM网络问题我很少一上来就改配置。常规的思路是先从下往上排查链路每层确认没问题再往上一层看。第一层检查物理链路。在宿主机上ping网关确认宿主机本身网络正常。如果宿主机都上不了网那先别折腾虚拟机。第二层检查虚拟链路。确认虚拟网桥存在并处于UP状态确认VM的虚拟网卡已经挂载到预期网桥上。第三层检查IP和路由。在VM内确认IP地址是否分配正确默认路由是否指向正确的网关。这里有个细节桥接模式的VM网关应该是物理网络的网关NAT模式的VM网关应该是虚拟网络的网关比如192.168.122.1千万别混。第四层检查转发和防火墙。在宿主机上检查NAT规则是否生效netfilter相关参数是否开启防火墙策略是否放行了桥接流量。按这个顺序排查下来绝大多数问题在第三层和第四层就能定位。比你在VM里来回重启网卡、反复重建虚拟网络要高效得多。5.3 排错中有用的几个检查命令平时我最常用的几个命令值得单独列出来都是排查时顺手就能用的# 在宿主机上查看虚拟网络的NAT规则是否生效 iptables -t nat -L POSTROUTING --line-numbers # 查看连接跟踪表里的NAT映射关系 conntrack -L | grep 192.168.122 # 查看虚拟网桥的MAC和端口信息 brctl show # 查看VM的实际网络接口状态和连接情况 virsh domifaddr 你的VM名 --source lease特别是最后一个命令它能直接查看VM通过DHCP获取到的IP地址省去了进入VM里面查IP的步骤批量管理VM时尤其好用。在维护几十台VM的环境里这个命令能极大提升效率。5.4 配置维护中的三个心态最后说点虚的但对实际工作很有帮助的东西。VM网络配置之所以容易让人心浮气躁就是因为虚拟化把“网络问题”变得可以随便重置反而让人失去了排查问题的耐心。我自己的经验是遇到一次网络故障与其快速重建虚拟网络不如顺着链路查一次原因这种排查过程积累下来的经验比任何文档都宝贵。另一点是要有文档意识。我在每次搭建虚拟化环境时都会记录一份网络规划表记录每个虚拟网络的模式、网段、用途、绑定关系。这份表在半年后排查问题时会成为救命稻草。很多人配完就忘等出问题时连哪个网卡是干嘛的都分不清排查起来自然非常耗时。还有一点不要过度设计。很多时候只需要一个NAT网络加一台办公用VM就能解决的事没必要搞三个网桥四种模式堆在一起。网络模式的选择和扩展应该跟着真实需求走。系统能解决的问题越简单后期维护成本就越低。按照我的经验把NAT、桥接、主机模式、内部网络这四种模式的原理和配置吃透日常90%以上的VM网络需求都能覆盖。剩下的那些千奇百怪的问题本质上也逃不开今天说的这些底层概念。以后再遇到网络不通先冷静下来从链路层面一层层捋绝大多数问题都会迎刃而解。
阅读完成 · 觉得有帮助？
