说个特别常见的场景某天你打开虚拟机准备继续捣鼓Ubuntu结果发现浏览器打不开ping外网IP也通不了apt update更是一堆报错。重启网络服务没用重置虚拟机设置没用最后干脆重装了一遍Ubuntu问题还是原样。如果你也在这种反复折腾的路上卡过那这篇博客基本就是给你写的。我需要提前说明虚拟机里的Ubuntu上不了网绝大多数情况下都不是系统坏了而是网络模式选错、宿主机服务没跑、或者DNS解析链条出了问题。本文会从最基础的三种虚拟网络模式开始一路讲到宿主机侧的隐形开关再到系统内的网卡配置和DNS排查最后用三个真实排障案例把完整链路走一遍。不管是刚装好虚拟机的新手还是在机房救过火的老运维这套思路都能直接用。1. 先分清三种网络模式故障多半在选型这一步就埋下了VMware和VirtualBox这类虚拟机软件给虚拟机提供了三种典型的网络接入方式桥接模式、NAT模式、仅主机模式。不懂它们区别的时候我只能说靠运气调网络。踩了几年坑之后我发现绝大多数虚拟机无法上网的问题从一开始选模式的时候就埋下了。1.1 桥接模式虚拟机伪装成一台独立电脑桥接模式Bridged会让虚拟机直接连接到宿主机所在的物理局域网虚拟机自己的虚拟网卡和宿主机的物理网卡之间搭了一座桥。效果就是局域网里的路由器会把虚拟机当作一台普通PC给它分配一个和宿主机同一网段的IP。这种模式的优点是虚拟机在网络里完全可见能提供对外服务也能被局域网里的其他设备访问。缺点是很容易和局域网现有IP冲突而且虚拟机能不能上网完全取决于局域网本身。比如你所在的公司网络限制MAC地址准入那你查遍系统配置也没有用因为问题根本不在虚拟机里。我见过不少同学在办公室网络里把虚拟机设成桥接模式结果一到家用网络就断网。这是因为家庭路由器的网段、DHCP策略和公司里完全不一样。虚拟机里的旧IP、旧网关信息全都不匹配自然上不了网。1.2 NAT模式最省心的共享上网方案NAT模式Network Address Translation是绝大多数场景下的默认选项也是我最推荐新手使用的模式。它会创建一个内部虚拟网络虚拟机的数据包通过宿主机转发出去再由宿主机代替虚拟机访问外部网络。从外部看来虚拟机用的就是宿主机自己的网络路径不需要在局域网里额外占用IP。NAT模式最大的好处是几乎不用配置。虚拟机开机后通过DHCP拿到一个类似192.168.x.x的IP网关指向虚拟网卡DNS通常也能自动获取只要宿主机能上网虚拟机基本就能上网。它的缺点是从局域网其他设备直接访问这台虚拟机比较麻烦因为需要端口转发。如果你的需求只是让虚拟机里的Ubuntu能上网、能装软件包、能拉代码NAT模式基本就是最优解。遇到问题先去检查NAT模式相关的服务比乱改系统配置有效得多。1.3 仅主机模式本就不该期待它上网仅主机模式Host-Only意味着虚拟机只能和宿主机通信物理局域网以及外网对它来说是不可见的。它相当于一个只连接宿主机和虚拟机的私人网段适合做实验环境、测试通信协议、模拟隔网段场景。很多人把仅主机模式当成NAT的替代品结果发现虚拟机里死活上不了网这时候不是配置坏了而是这个模式从原理上就不提供外网连接。仅主机模式要是想上网也不是完全没有办法——可以给虚拟机再加一块NAT模式的网卡或者让宿主机开启IP转发和NAT规则但这涉及更复杂的路由配置普通场景不推荐。1.4 三种模式怎么选一张对照表遇到虚拟机无法上网问题第一步永远不是改系统配置而是先确认当前虚拟机用的是哪种模式。我整理了一张对照表方便你快速判断是不是模式选错了模式虚拟机IP来源能否上网局域网内可见适用场景桥接模式物理局域网DHCP取决于局域网可见需要对外提供服务、模拟独立主机NAT模式虚拟网卡DHCP宿主机可上即能上不可见一般上网、装软件、日常开发仅主机模式虚拟网段固定默认不可上网不可见隔离实验、宿主机与虚拟机通信我自己的习惯是日常开发全用NAT要演示局域网服务才临时切桥接。这个选择能帮你过滤掉一半的上不了网问题。2. 系统内网卡排查链路从看不见网卡到配错地址确认网络模式没问题之后下一步要把注意力转移到Ubuntu系统内部。很多人一上来就改IP、改DNS方向完全错了。正确的顺序应该是先确认网卡是否被系统识别再确认网卡是否已经启用最后才谈得上IP和DNS的配置。2.1 第一步永远是查网卡是否被系统识别打开终端输入以下命令ip addr或者用传统的ifconfig正常情况下你能看到类似eth0、ens33、enp0s3这样的网络接口旁边会标注UP和分配的IP地址。如果这个命令的输出里只有一个lo回环接口说明虚拟机根本没有可用的虚拟网卡或者网卡没有被系统识别。这时候先别急着折腾系统内部回到虚拟机软件的虚拟机设置页面检查网卡是否勾选了已连接和启动时连接。有些情况下迁移虚拟机或者修改硬件配置会在保存时把网卡连接选项取消了。另外VMware里的设备状态里还有个网络连接选项需要确保选中的是正确模式而不是断开。如果网卡在设置里也正常系统里还是只有lo那就要考虑是不是虚拟机平台对某个系统版本的兼容性出了问题。可以试着在Ubuntu里执行下面这句话看内核是否识别到了虚拟PCI设备lspci | grep -i ethernet如果这里能看到Ethernet Controller说明硬件层面已经识别问题多半出在驱动或系统服务上如果连这里都看不到大概率要检查虚拟机模板或者重新添加一块网卡设备。2.2 网卡命名为什么不是以前的eth0很多用惯CentOS 6甚至老Ubuntu的同学一到新系统里发现网卡不叫eth0而叫ens33或enp0s3当场就开始怀疑是不是驱动坏了。其实这只是因为systemd引入了一套新的网卡命名规则基于硬件位置、PCI槽位等信息来命名。传统eth0这种命名方式在新的systemd规则下已经不生效了。不同虚拟机平台、不同主板结构显示的名称都可能不一样。比如VMware下常见ens33VirtualBox下常见enp0s3还有按板载接口来的eno1。这些都是正常现象不影响使用关键是你在配置网络时要用ip addr里看到的那个真实名称。如果你实在不习惯新命名也可以在内核引导参数里加net.ifnames0来恢复eth0命名方式但这样做没有太大的必要。按照ip addr里的实际名称去操作比强行改名稳妥得多。2.3 网卡UP但拿不到IP检查DHCP客户端很多时候ip addr显示网卡处于UP状态但一行IPv4地址都看不到或者只有一个169.254开头的地址。169.254开头的地址是系统在DHCP失败时自动生成的链路本地地址看到它基本可以断定DHCP没有成功。这种情况需要分两边看。宿主机侧检查DHCP服务是否正常NAT模式下还有一张虚拟网卡充当网关它本身要能被ping通。在Ubuntu里可以先试着手动请求IPsudo dhclient -v eth0这里的eth0换成你实际看到的接口名。如果手动执行后拿到了IP说明DHCP服务本身没问题那就要去看系统里的网络管理服务是不是有问题。Ubuntu默认的网络管理工具很关键如果用的是NetworkManager可以重启网络管理服务sudo systemctl restart NetworkManager对于用netplan配置网络的系统则执行sudo netplan apply这条命令会重新读取配置文件并应用网络设置。很多网卡应该起来但没起来的情况一条netplan apply就能解决。2.4 Netplan配置Ubuntu的现代网络配置方式Ubuntu从17.10开始用netplan管理网络配置文件统一放在/etc/netplan/*.yaml。常见文件名有00-installer-config.yaml或50-cloud-init.yaml取决于装机方式。一个常见的NAT模式DHCP配置长这样network: version: 2 ethernets: ens33: dhcp4: true如果是VirtualBox或VMware的虚拟机绝大多数情况下保持这个配置就够了。需要改静态地址时可以改成network: version: 2 ethernets: ens33: dhcp4: false addresses: - 192.168.80.100/24 routes: - to: default via: 192.168.80.2 nameservers: addresses: - 223.5.5.5 - 8.8.8.8这里面有两个关键点容易被忽略第一修改yaml文件之后一定要执行sudo netplan apply配置文件本身不会自动生效。第二yaml文件对缩进极其敏感写错一个空格就可能导致配置加载失败而且报错信息很模糊。我的习惯是先备份原件再复制一份去做修改避免改乱了还能还原。3. 宿主机上的隐形开关服务、网段与拦截这一章我觉得是全网教程里讲得最少、但又最容易踩雷的部分。很多人把虚拟机内部翻了个底朝天问题其实出在宿主机上——VMware的NAT服务没启动VirtualBox的Host-Only网卡没绑定Windows的防火墙悄悄拦截了虚拟网卡流量这些都是隐形故障。3.1 VMware宿主机的三大检查点如果你用的是VMware打开编辑菜单里的虚拟网络编辑器通常能看到VMnet0桥接、VMnet1仅主机、VMnet8NAT这几张虚拟网络。这里要检查三件事第一NAT模式对应的VMnet8是否使用了正确的子网。如果这台电脑几年内装过两三个版本的VMware很可能留下一个和局域网冲突的网段。比如你们公司物理局域网正好是192.168.137.x而VMnet8默认也是192.168.137.x那路由表就会乱掉。第二VMware的NAT服务有没有在运行。在Windows宿主机上按Win R输入services.msc找到VMware NAT Service和VMware DHCP Service确认这两个服务状态是正在运行。这两兄弟停止运行的话虚拟机里配得再完美也白搭。第三如果改过VMnet8的网段一定要点击应用之后再回到虚拟机里重启网络服务。因为NAT内部网关地址变了虚拟机里旧的IP、旧网关信息必须跟着刷新。3.2 VirtualBox的NAT与Host-Only设置VirtualBox的逻辑略有不同。它在全局设置里有一项网络可以预置NAT网络和Host-Only网络。新建一个NAT网络之后虚拟机网卡设置为网络地址转换(NAT)或者NAT网络就能直接上网。如果你发现NAT模式下不通我建议把网卡先切到桥接网卡再切回NAT来触发一次重新初始化。这个操作看起来有点笨但经常能解决VirtualBox网络配置僵死的问题。Host-Only模式下VirtualBox通常自带一个类似VirtualBox Host-Only Ethernet Adapter的虚拟网卡在Windows设备管理器或ipconfig里能看到。如果这张网卡被禁用了或者IP地址已经被改成静态且和虚拟机不在一个网段VBox里的虚拟机自然上不了网。处理方式很简单打开VirtualBox全局设置里的网络——仅主机网络检查DHCP服务器是否勾选了启用服务器然后重新应用一次。如果不行就删除这张Host-Only网卡重新创建一张再回到虚拟机设置里重新绑定。3.3 换了个网络环境之后虚拟机断网租约与网段的锅这个场景我在运维群里见过太多回在公司里虚拟机还好好的把笔记本带回家虚拟机立刻上不了网。这种情况几乎都和虚拟机自身的配置无关而是和物理网络环境变化有关。NAT模式下虚拟机用的是VMnet8虚拟内网理论上换物理网络环境不影响虚拟机上网。但如果你用的是桥接模式虚拟机相当于直接挂在物理局域网里。公司网段192.168.1.x家庭网段192.168.31.x虚拟机还留着公司网络分配的IP和网关那它当然找不到回家的路。解决方案就是切回NAT模式或者在桥接模式下让虚拟机重新通过DHCP获取IPsudo dhclient -v eth0再补充一个容易忽略的点某些路由器会有5GHz和2.4GHz两个频段下不同的防蹭网策略而虚拟机的桥接网卡没有独立的无线网卡硬件它借用的是宿主机无线网卡导致认证时无法通过。在这个前提下桥接模式在无线环境下还可能直接失效。我自己宁可多配一层NAT也不跟无线桥接较劲。3.4 关于Windows宿主机防火墙和网卡禁用的补充无论你用的是VMware还是VirtualBoxWindows宿主机上的第三方防火墙尤其是一些全家桶安全软件都可能拦截虚拟机的虚拟网卡流量。这类拦截通常不弹窗日志也不会显示在Ubuntu里排查难度极高。我的判断方法是在宿主机上暂时关闭相关防火墙或安全软件的拦截功能然后在虚拟机里再ping一次。如果通了说明就是这个拦截。之后不要为了省事长期关闭防火墙而是尽量把VMware、VirtualBox相关的进程加入白名单。Windows宿主机上的禁用网卡也是个隐形坑。笔记本上如果安装了VMware的VMnet8虚拟网卡但你在网络连接面板里手动把它禁用了NAT服务再正常虚拟机也无法通过它转发数据。同样Hyper-V虚拟网卡如果处于禁用状态也会影响其他虚拟机的网络适配。看到虚拟机网络异常先花半分钟检查一下Windows的网络连接面板看看有没有本该启用却处于禁用状态的虚拟网卡。4. 能ping通IP却上不了网DNS和路由才是最坑的环节到了这一节我们把范围收敛到一种特别典型的场景虚拟机的IP地址已经有了网关也能ping通甚至直接ping一个公网IP都通但就是访问不了域名apt update报错浏览器打不开网页。这是最容易让人一头雾水的故障形态因为它意味着物理链路和路由都正常问题出在DNS或者更高层。4.1 分层测试法用四五条命令定位故障层面对这种半通不通的状态我强烈建议做分层测试而不是盲目去猜。具体来说按下面这个顺序执行# 1. 测试回环和自身协议栈 ping 127.0.0.1 # 2. 测试网关连通性网关IP以实际为准 ping 192.168.80.2 # 3. 测试公网IP连通性不依赖DNS ping 223.5.5.5 # 4. 测试域名解析 nslookup www.ubuntu.com # 5. 测试应用层访问 curl -I https://archive.ubuntu.com如果第1、2步没问题说明网卡、IP、网络模式都正常。如果第3步也连通说明NAT模式和宿主机出口都没问题。再从第4步出发基本就能定位是不是DNS解析的问题。这套分层测试法能把故障范围从全网不通快速缩小到某一层有问题是我所有排障中最优先使用的方法。4.2 Ubuntu的DNS解析链条systemd-resolved的坑这里重点聊一下Ubuntu系统自带的DNS解析服务。从18.04版本开始Ubuntu默认使用systemd-resolved来管理DNS解析。它的表现是/etc/resolv.conf变成了指向/run/systemd/resolve/stub-resolv.conf的符号链接而这个stub文件里的DNS地址固定是127.0.0.53。很多新人按老教程去改/etc/resolv.conf改了之后发现根本没效果就是因为这个文件本身只是systemd-resolved的一个转发出口。真正要改的地方在/etc/systemd/resolved.conf或者干脆不依赖systemd-resolved直接把DNS配置写到netplan里。如果遇到域名解析失败可以先重启一下这个解析服务sudo systemctl restart systemd-resolved很多时候重启一次就能解决缓存导致的解析异常。如果重启后还是不行就用下面的命令查看当前系统实际使用的DNS配置resolvectl status请记住如果看到当前DNS服务器指向一个不可达的地址比如残留的公司内网DNS那就算物理网络全通域名解析也照样失败。4.3 直接修改Netplan指定DNS如果想彻底摆脱systemd-resolved的困扰最直接的办法是用netplan自定义DNS。打开你的网络配置文件在对应网卡段下加上nameservers配置network: version: 2 ethernets: ens33: dhcp4: true nameservers: addresses: - 223.5.5.5 - 114.114.114.114保存之后执行sudo netplan apply然后把/etc/resolv.conf重新指向实际生效的配置sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf这次再执行cat /etc/resolv.conf你会直接看到你指定的DNS地址。注意如果你更习惯用NetworkManager可以在netplan配置里加上renderer: NetworkManager让NetworkManager统一接管网络然后用nmcli来配DNS。两个工具千万别同时抢控制权否则会出现配置被互相覆盖的情况。4.4 路由表的异常默认路由漂移DNS问题之外还有一个特别隐蔽的情况默认路由漂移。当虚拟机有多块网卡比如一块NAT、一块仅主机时系统可能会把默认路由走到不应走的网卡上导致所有外网流量进死胡同。排查方法是用ip route正常情况下你应该看到一行default via 网关IP dev 网卡名。如果这一行的dev不是你的NAT网卡而是另一块仅主机网卡那外网不通就非常正常了。解决方法是手动调整路由优先级让默认路由走NAT网卡。最简单的是删除错误的默认路由再手动添加sudo ip route del default sudo ip route add default via 192.168.80.2 dev ens33如果重启之后会失效就回到netplan配置里在指定的网卡段下通过routes字段指定to: default指向正确的网关。多网卡环境下还要让网卡在netplan里配置正确的metric值数值小的优先级更高。5. 三个真实排障案例完整链路复现前面几章节都在讲静态知识和排查方法这一章我用三个遇到过的实际案例把故障现象、排查过程和修复方案完整串一遍。你可以把它当成一套可以直接对照执行的排障脚本。5.1 案例一NAT模式下域名解析失败现象某台虚拟机里ping网关通ping公网IP也通但apt update报错Temporary failure resolving archive.ubuntu.com。排查链路第一步执行resolvectl status发现当前DNS指向一个内网地址——这个地址在宿主机当前所处环境里根本不存在。第二步执行nslookup archive.ubuntu.com发现解析请求超时确认问题出在DNS。第三步查看/etc/systemd/resolved.conf发现里面残留了原先环境的DNS配置。修复方式把resolved.conf里的DNS改成223.5.5.5和114.114.114.114重启systemd-resolved服务然后重新执行apt update问题直接消失。这个案例想说明的是NAT模式和网络链路都完好但DNS配置残留就能让一切看起来像断网。5.2 案例二重启虚拟机之后网卡消失现象一台VirtualBox里的Ubuntu每次重启完系统ip addr里只有lo网卡就跟没插一样。手动执行netplan apply又能恢复重启后又失效。排查链路先在虚拟机设置里查看网卡连接状态发现连接到下面选中了NAT模式看起来正常。然后手动ip link set eth0 up再应用netplan网络能通说明驱动和虚拟网卡都没坏。继续往下查执行systemctl status systemd-networkd结果发现这个服务处于不活跃状态而网络管理工具是NetworkManager两者冲突导致重启时状态异常。最终修复方式是删除已有的netplan配置改为统一用NetworkManager管理network: version: 2 renderer: NetworkManager再之后重启虚拟机网卡能自动获得IP不再需要手动插拔。这个案例提醒我网络管理工具别混用要么NetworkManager要么systemd-networkd加netplan二选一才不容易出幺蛾子。5.3 案例三内核升级后无法上网现象某台长期运行的Ubuntu VM某天执行完系统更新并重启后彻底无法上网。SSH连不上ping网关都不通。排查链路因为远程无法操作只能回到宿主机控制台在虚拟机终端里执行lspci | grep -i ethernet发现虚拟网卡设备是能被识别的。继续查看驱动加载情况lsmod | grep -i e1000结果发现e1000相关驱动模块没有加载成功。这往往是升级内核后旧模块和新内核不匹配造成的。系统里可能还保留着旧内核重启时手动在GRUB菜单里选择旧内核网络立即恢复正常。后续修复方式重新安装对应内核的驱动依赖包或直接安装open-vm-toolsVMware场景让虚拟网卡驱动更可靠。如果不想折腾驱动可以临时固定使用旧内核并屏蔽新内核包更新sudo apt-mark hold linux-generic这样能避免系统在不知情的情况下再次升级内核导致网络再次中断。内核升级引入的网络故障在实体机上也不少见但在虚拟机上更常见因为虚拟机网卡对内核模块的依赖其实更直接。5.4 一套可以直接抄的排障命令清单最后我把排障过程中最高频使用的命令整理成一份速查清单虚拟机上不了网的时候按顺序执行就行# 1. 查看网卡状态 ip addr # 2. 查看路由表 ip route # 3. 查看DNS配置 cat /etc/resolv.conf resolvectl status # 4. 测试网关 ping -c 4 网关IP # 5. 测试公网IP ping -c 4 223.5.5.5 # 6. 测试域名解析 nslookup www.ubuntu.com # 7. 测试应用层 curl -I https://archive.ubuntu.com # 8. 重启网络管理服务 sudo systemctl restart NetworkManager sudo netplan apply # 9. 查看系统日志 journalctl -xe | grep -i network这套命令执行完90%的故障都能定位到具体层面。剩下10%属于硬件兼容性或特殊网络环境问题需要结合虚拟化平台的日志进一步分析。我自己在实际操作中的最大体会是虚拟机的网络排障很大程度上就是一个控制变量的过程。先确认模式再确认宿主机再看虚拟机内配置最后才考虑驱动和兼容性。层层递进不要跳层去瞎猜。还有一个小技巧想分享给大家在改动任何配置文件之前先做一次快照或备份。别觉得麻烦很多时候你改了netplan配置后apply失败连网络带SSH一起断了那时候再想还原有备份和没备份完全是两种处境。稳妥永远是虚拟化环境中最重要的操作原则。
说个特别常见的场景某天你打开虚拟机准备继续捣鼓Ubuntu结果发现浏览器打不开ping外网IP也通不了apt update更是一堆报错。重启网络服务没用重置虚拟机设置没用最后干脆重装了一遍Ubuntu问题还是原样。如果你也在这种反复折腾的路上卡过那这篇博客基本就是给你写的。我需要提前说明虚拟机里的Ubuntu上不了网绝大多数情况下都不是系统坏了而是网络模式选错、宿主机服务没跑、或者DNS解析链条出了问题。本文会从最基础的三种虚拟网络模式开始一路讲到宿主机侧的隐形开关再到系统内的网卡配置和DNS排查最后用三个真实排障案例把完整链路走一遍。不管是刚装好虚拟机的新手还是在机房救过火的老运维这套思路都能直接用。1. 先分清三种网络模式故障多半在选型这一步就埋下了VMware和VirtualBox这类虚拟机软件给虚拟机提供了三种典型的网络接入方式桥接模式、NAT模式、仅主机模式。不懂它们区别的时候我只能说靠运气调网络。踩了几年坑之后我发现绝大多数虚拟机无法上网的问题从一开始选模式的时候就埋下了。1.1 桥接模式虚拟机伪装成一台独立电脑桥接模式Bridged会让虚拟机直接连接到宿主机所在的物理局域网虚拟机自己的虚拟网卡和宿主机的物理网卡之间搭了一座桥。效果就是局域网里的路由器会把虚拟机当作一台普通PC给它分配一个和宿主机同一网段的IP。这种模式的优点是虚拟机在网络里完全可见能提供对外服务也能被局域网里的其他设备访问。缺点是很容易和局域网现有IP冲突而且虚拟机能不能上网完全取决于局域网本身。比如你所在的公司网络限制MAC地址准入那你查遍系统配置也没有用因为问题根本不在虚拟机里。我见过不少同学在办公室网络里把虚拟机设成桥接模式结果一到家用网络就断网。这是因为家庭路由器的网段、DHCP策略和公司里完全不一样。虚拟机里的旧IP、旧网关信息全都不匹配自然上不了网。1.2 NAT模式最省心的共享上网方案NAT模式Network Address Translation是绝大多数场景下的默认选项也是我最推荐新手使用的模式。它会创建一个内部虚拟网络虚拟机的数据包通过宿主机转发出去再由宿主机代替虚拟机访问外部网络。从外部看来虚拟机用的就是宿主机自己的网络路径不需要在局域网里额外占用IP。NAT模式最大的好处是几乎不用配置。虚拟机开机后通过DHCP拿到一个类似192.168.x.x的IP网关指向虚拟网卡DNS通常也能自动获取只要宿主机能上网虚拟机基本就能上网。它的缺点是从局域网其他设备直接访问这台虚拟机比较麻烦因为需要端口转发。如果你的需求只是让虚拟机里的Ubuntu能上网、能装软件包、能拉代码NAT模式基本就是最优解。遇到问题先去检查NAT模式相关的服务比乱改系统配置有效得多。1.3 仅主机模式本就不该期待它上网仅主机模式Host-Only意味着虚拟机只能和宿主机通信物理局域网以及外网对它来说是不可见的。它相当于一个只连接宿主机和虚拟机的私人网段适合做实验环境、测试通信协议、模拟隔网段场景。很多人把仅主机模式当成NAT的替代品结果发现虚拟机里死活上不了网这时候不是配置坏了而是这个模式从原理上就不提供外网连接。仅主机模式要是想上网也不是完全没有办法——可以给虚拟机再加一块NAT模式的网卡或者让宿主机开启IP转发和NAT规则但这涉及更复杂的路由配置普通场景不推荐。1.4 三种模式怎么选一张对照表遇到虚拟机无法上网问题第一步永远不是改系统配置而是先确认当前虚拟机用的是哪种模式。我整理了一张对照表方便你快速判断是不是模式选错了模式虚拟机IP来源能否上网局域网内可见适用场景桥接模式物理局域网DHCP取决于局域网可见需要对外提供服务、模拟独立主机NAT模式虚拟网卡DHCP宿主机可上即能上不可见一般上网、装软件、日常开发仅主机模式虚拟网段固定默认不可上网不可见隔离实验、宿主机与虚拟机通信我自己的习惯是日常开发全用NAT要演示局域网服务才临时切桥接。这个选择能帮你过滤掉一半的上不了网问题。2. 系统内网卡排查链路从看不见网卡到配错地址确认网络模式没问题之后下一步要把注意力转移到Ubuntu系统内部。很多人一上来就改IP、改DNS方向完全错了。正确的顺序应该是先确认网卡是否被系统识别再确认网卡是否已经启用最后才谈得上IP和DNS的配置。2.1 第一步永远是查网卡是否被系统识别打开终端输入以下命令ip addr或者用传统的ifconfig正常情况下你能看到类似eth0、ens33、enp0s3这样的网络接口旁边会标注UP和分配的IP地址。如果这个命令的输出里只有一个lo回环接口说明虚拟机根本没有可用的虚拟网卡或者网卡没有被系统识别。这时候先别急着折腾系统内部回到虚拟机软件的虚拟机设置页面检查网卡是否勾选了已连接和启动时连接。有些情况下迁移虚拟机或者修改硬件配置会在保存时把网卡连接选项取消了。另外VMware里的设备状态里还有个网络连接选项需要确保选中的是正确模式而不是断开。如果网卡在设置里也正常系统里还是只有lo那就要考虑是不是虚拟机平台对某个系统版本的兼容性出了问题。可以试着在Ubuntu里执行下面这句话看内核是否识别到了虚拟PCI设备lspci | grep -i ethernet如果这里能看到Ethernet Controller说明硬件层面已经识别问题多半出在驱动或系统服务上如果连这里都看不到大概率要检查虚拟机模板或者重新添加一块网卡设备。2.2 网卡命名为什么不是以前的eth0很多用惯CentOS 6甚至老Ubuntu的同学一到新系统里发现网卡不叫eth0而叫ens33或enp0s3当场就开始怀疑是不是驱动坏了。其实这只是因为systemd引入了一套新的网卡命名规则基于硬件位置、PCI槽位等信息来命名。传统eth0这种命名方式在新的systemd规则下已经不生效了。不同虚拟机平台、不同主板结构显示的名称都可能不一样。比如VMware下常见ens33VirtualBox下常见enp0s3还有按板载接口来的eno1。这些都是正常现象不影响使用关键是你在配置网络时要用ip addr里看到的那个真实名称。如果你实在不习惯新命名也可以在内核引导参数里加net.ifnames0来恢复eth0命名方式但这样做没有太大的必要。按照ip addr里的实际名称去操作比强行改名稳妥得多。2.3 网卡UP但拿不到IP检查DHCP客户端很多时候ip addr显示网卡处于UP状态但一行IPv4地址都看不到或者只有一个169.254开头的地址。169.254开头的地址是系统在DHCP失败时自动生成的链路本地地址看到它基本可以断定DHCP没有成功。这种情况需要分两边看。宿主机侧检查DHCP服务是否正常NAT模式下还有一张虚拟网卡充当网关它本身要能被ping通。在Ubuntu里可以先试着手动请求IPsudo dhclient -v eth0这里的eth0换成你实际看到的接口名。如果手动执行后拿到了IP说明DHCP服务本身没问题那就要去看系统里的网络管理服务是不是有问题。Ubuntu默认的网络管理工具很关键如果用的是NetworkManager可以重启网络管理服务sudo systemctl restart NetworkManager对于用netplan配置网络的系统则执行sudo netplan apply这条命令会重新读取配置文件并应用网络设置。很多网卡应该起来但没起来的情况一条netplan apply就能解决。2.4 Netplan配置Ubuntu的现代网络配置方式Ubuntu从17.10开始用netplan管理网络配置文件统一放在/etc/netplan/*.yaml。常见文件名有00-installer-config.yaml或50-cloud-init.yaml取决于装机方式。一个常见的NAT模式DHCP配置长这样network: version: 2 ethernets: ens33: dhcp4: true如果是VirtualBox或VMware的虚拟机绝大多数情况下保持这个配置就够了。需要改静态地址时可以改成network: version: 2 ethernets: ens33: dhcp4: false addresses: - 192.168.80.100/24 routes: - to: default via: 192.168.80.2 nameservers: addresses: - 223.5.5.5 - 8.8.8.8这里面有两个关键点容易被忽略第一修改yaml文件之后一定要执行sudo netplan apply配置文件本身不会自动生效。第二yaml文件对缩进极其敏感写错一个空格就可能导致配置加载失败而且报错信息很模糊。我的习惯是先备份原件再复制一份去做修改避免改乱了还能还原。3. 宿主机上的隐形开关服务、网段与拦截这一章我觉得是全网教程里讲得最少、但又最容易踩雷的部分。很多人把虚拟机内部翻了个底朝天问题其实出在宿主机上——VMware的NAT服务没启动VirtualBox的Host-Only网卡没绑定Windows的防火墙悄悄拦截了虚拟网卡流量这些都是隐形故障。3.1 VMware宿主机的三大检查点如果你用的是VMware打开编辑菜单里的虚拟网络编辑器通常能看到VMnet0桥接、VMnet1仅主机、VMnet8NAT这几张虚拟网络。这里要检查三件事第一NAT模式对应的VMnet8是否使用了正确的子网。如果这台电脑几年内装过两三个版本的VMware很可能留下一个和局域网冲突的网段。比如你们公司物理局域网正好是192.168.137.x而VMnet8默认也是192.168.137.x那路由表就会乱掉。第二VMware的NAT服务有没有在运行。在Windows宿主机上按Win R输入services.msc找到VMware NAT Service和VMware DHCP Service确认这两个服务状态是正在运行。这两兄弟停止运行的话虚拟机里配得再完美也白搭。第三如果改过VMnet8的网段一定要点击应用之后再回到虚拟机里重启网络服务。因为NAT内部网关地址变了虚拟机里旧的IP、旧网关信息必须跟着刷新。3.2 VirtualBox的NAT与Host-Only设置VirtualBox的逻辑略有不同。它在全局设置里有一项网络可以预置NAT网络和Host-Only网络。新建一个NAT网络之后虚拟机网卡设置为网络地址转换(NAT)或者NAT网络就能直接上网。如果你发现NAT模式下不通我建议把网卡先切到桥接网卡再切回NAT来触发一次重新初始化。这个操作看起来有点笨但经常能解决VirtualBox网络配置僵死的问题。Host-Only模式下VirtualBox通常自带一个类似VirtualBox Host-Only Ethernet Adapter的虚拟网卡在Windows设备管理器或ipconfig里能看到。如果这张网卡被禁用了或者IP地址已经被改成静态且和虚拟机不在一个网段VBox里的虚拟机自然上不了网。处理方式很简单打开VirtualBox全局设置里的网络——仅主机网络检查DHCP服务器是否勾选了启用服务器然后重新应用一次。如果不行就删除这张Host-Only网卡重新创建一张再回到虚拟机设置里重新绑定。3.3 换了个网络环境之后虚拟机断网租约与网段的锅这个场景我在运维群里见过太多回在公司里虚拟机还好好的把笔记本带回家虚拟机立刻上不了网。这种情况几乎都和虚拟机自身的配置无关而是和物理网络环境变化有关。NAT模式下虚拟机用的是VMnet8虚拟内网理论上换物理网络环境不影响虚拟机上网。但如果你用的是桥接模式虚拟机相当于直接挂在物理局域网里。公司网段192.168.1.x家庭网段192.168.31.x虚拟机还留着公司网络分配的IP和网关那它当然找不到回家的路。解决方案就是切回NAT模式或者在桥接模式下让虚拟机重新通过DHCP获取IPsudo dhclient -v eth0再补充一个容易忽略的点某些路由器会有5GHz和2.4GHz两个频段下不同的防蹭网策略而虚拟机的桥接网卡没有独立的无线网卡硬件它借用的是宿主机无线网卡导致认证时无法通过。在这个前提下桥接模式在无线环境下还可能直接失效。我自己宁可多配一层NAT也不跟无线桥接较劲。3.4 关于Windows宿主机防火墙和网卡禁用的补充无论你用的是VMware还是VirtualBoxWindows宿主机上的第三方防火墙尤其是一些全家桶安全软件都可能拦截虚拟机的虚拟网卡流量。这类拦截通常不弹窗日志也不会显示在Ubuntu里排查难度极高。我的判断方法是在宿主机上暂时关闭相关防火墙或安全软件的拦截功能然后在虚拟机里再ping一次。如果通了说明就是这个拦截。之后不要为了省事长期关闭防火墙而是尽量把VMware、VirtualBox相关的进程加入白名单。Windows宿主机上的禁用网卡也是个隐形坑。笔记本上如果安装了VMware的VMnet8虚拟网卡但你在网络连接面板里手动把它禁用了NAT服务再正常虚拟机也无法通过它转发数据。同样Hyper-V虚拟网卡如果处于禁用状态也会影响其他虚拟机的网络适配。看到虚拟机网络异常先花半分钟检查一下Windows的网络连接面板看看有没有本该启用却处于禁用状态的虚拟网卡。4. 能ping通IP却上不了网DNS和路由才是最坑的环节到了这一节我们把范围收敛到一种特别典型的场景虚拟机的IP地址已经有了网关也能ping通甚至直接ping一个公网IP都通但就是访问不了域名apt update报错浏览器打不开网页。这是最容易让人一头雾水的故障形态因为它意味着物理链路和路由都正常问题出在DNS或者更高层。4.1 分层测试法用四五条命令定位故障层面对这种半通不通的状态我强烈建议做分层测试而不是盲目去猜。具体来说按下面这个顺序执行# 1. 测试回环和自身协议栈 ping 127.0.0.1 # 2. 测试网关连通性网关IP以实际为准 ping 192.168.80.2 # 3. 测试公网IP连通性不依赖DNS ping 223.5.5.5 # 4. 测试域名解析 nslookup www.ubuntu.com # 5. 测试应用层访问 curl -I https://archive.ubuntu.com如果第1、2步没问题说明网卡、IP、网络模式都正常。如果第3步也连通说明NAT模式和宿主机出口都没问题。再从第4步出发基本就能定位是不是DNS解析的问题。这套分层测试法能把故障范围从全网不通快速缩小到某一层有问题是我所有排障中最优先使用的方法。4.2 Ubuntu的DNS解析链条systemd-resolved的坑这里重点聊一下Ubuntu系统自带的DNS解析服务。从18.04版本开始Ubuntu默认使用systemd-resolved来管理DNS解析。它的表现是/etc/resolv.conf变成了指向/run/systemd/resolve/stub-resolv.conf的符号链接而这个stub文件里的DNS地址固定是127.0.0.53。很多新人按老教程去改/etc/resolv.conf改了之后发现根本没效果就是因为这个文件本身只是systemd-resolved的一个转发出口。真正要改的地方在/etc/systemd/resolved.conf或者干脆不依赖systemd-resolved直接把DNS配置写到netplan里。如果遇到域名解析失败可以先重启一下这个解析服务sudo systemctl restart systemd-resolved很多时候重启一次就能解决缓存导致的解析异常。如果重启后还是不行就用下面的命令查看当前系统实际使用的DNS配置resolvectl status请记住如果看到当前DNS服务器指向一个不可达的地址比如残留的公司内网DNS那就算物理网络全通域名解析也照样失败。4.3 直接修改Netplan指定DNS如果想彻底摆脱systemd-resolved的困扰最直接的办法是用netplan自定义DNS。打开你的网络配置文件在对应网卡段下加上nameservers配置network: version: 2 ethernets: ens33: dhcp4: true nameservers: addresses: - 223.5.5.5 - 114.114.114.114保存之后执行sudo netplan apply然后把/etc/resolv.conf重新指向实际生效的配置sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf这次再执行cat /etc/resolv.conf你会直接看到你指定的DNS地址。注意如果你更习惯用NetworkManager可以在netplan配置里加上renderer: NetworkManager让NetworkManager统一接管网络然后用nmcli来配DNS。两个工具千万别同时抢控制权否则会出现配置被互相覆盖的情况。4.4 路由表的异常默认路由漂移DNS问题之外还有一个特别隐蔽的情况默认路由漂移。当虚拟机有多块网卡比如一块NAT、一块仅主机时系统可能会把默认路由走到不应走的网卡上导致所有外网流量进死胡同。排查方法是用ip route正常情况下你应该看到一行default via 网关IP dev 网卡名。如果这一行的dev不是你的NAT网卡而是另一块仅主机网卡那外网不通就非常正常了。解决方法是手动调整路由优先级让默认路由走NAT网卡。最简单的是删除错误的默认路由再手动添加sudo ip route del default sudo ip route add default via 192.168.80.2 dev ens33如果重启之后会失效就回到netplan配置里在指定的网卡段下通过routes字段指定to: default指向正确的网关。多网卡环境下还要让网卡在netplan里配置正确的metric值数值小的优先级更高。5. 三个真实排障案例完整链路复现前面几章节都在讲静态知识和排查方法这一章我用三个遇到过的实际案例把故障现象、排查过程和修复方案完整串一遍。你可以把它当成一套可以直接对照执行的排障脚本。5.1 案例一NAT模式下域名解析失败现象某台虚拟机里ping网关通ping公网IP也通但apt update报错Temporary failure resolving archive.ubuntu.com。排查链路第一步执行resolvectl status发现当前DNS指向一个内网地址——这个地址在宿主机当前所处环境里根本不存在。第二步执行nslookup archive.ubuntu.com发现解析请求超时确认问题出在DNS。第三步查看/etc/systemd/resolved.conf发现里面残留了原先环境的DNS配置。修复方式把resolved.conf里的DNS改成223.5.5.5和114.114.114.114重启systemd-resolved服务然后重新执行apt update问题直接消失。这个案例想说明的是NAT模式和网络链路都完好但DNS配置残留就能让一切看起来像断网。5.2 案例二重启虚拟机之后网卡消失现象一台VirtualBox里的Ubuntu每次重启完系统ip addr里只有lo网卡就跟没插一样。手动执行netplan apply又能恢复重启后又失效。排查链路先在虚拟机设置里查看网卡连接状态发现连接到下面选中了NAT模式看起来正常。然后手动ip link set eth0 up再应用netplan网络能通说明驱动和虚拟网卡都没坏。继续往下查执行systemctl status systemd-networkd结果发现这个服务处于不活跃状态而网络管理工具是NetworkManager两者冲突导致重启时状态异常。最终修复方式是删除已有的netplan配置改为统一用NetworkManager管理network: version: 2 renderer: NetworkManager再之后重启虚拟机网卡能自动获得IP不再需要手动插拔。这个案例提醒我网络管理工具别混用要么NetworkManager要么systemd-networkd加netplan二选一才不容易出幺蛾子。5.3 案例三内核升级后无法上网现象某台长期运行的Ubuntu VM某天执行完系统更新并重启后彻底无法上网。SSH连不上ping网关都不通。排查链路因为远程无法操作只能回到宿主机控制台在虚拟机终端里执行lspci | grep -i ethernet发现虚拟网卡设备是能被识别的。继续查看驱动加载情况lsmod | grep -i e1000结果发现e1000相关驱动模块没有加载成功。这往往是升级内核后旧模块和新内核不匹配造成的。系统里可能还保留着旧内核重启时手动在GRUB菜单里选择旧内核网络立即恢复正常。后续修复方式重新安装对应内核的驱动依赖包或直接安装open-vm-toolsVMware场景让虚拟网卡驱动更可靠。如果不想折腾驱动可以临时固定使用旧内核并屏蔽新内核包更新sudo apt-mark hold linux-generic这样能避免系统在不知情的情况下再次升级内核导致网络再次中断。内核升级引入的网络故障在实体机上也不少见但在虚拟机上更常见因为虚拟机网卡对内核模块的依赖其实更直接。5.4 一套可以直接抄的排障命令清单最后我把排障过程中最高频使用的命令整理成一份速查清单虚拟机上不了网的时候按顺序执行就行# 1. 查看网卡状态 ip addr # 2. 查看路由表 ip route # 3. 查看DNS配置 cat /etc/resolv.conf resolvectl status # 4. 测试网关 ping -c 4 网关IP # 5. 测试公网IP ping -c 4 223.5.5.5 # 6. 测试域名解析 nslookup www.ubuntu.com # 7. 测试应用层 curl -I https://archive.ubuntu.com # 8. 重启网络管理服务 sudo systemctl restart NetworkManager sudo netplan apply # 9. 查看系统日志 journalctl -xe | grep -i network这套命令执行完90%的故障都能定位到具体层面。剩下10%属于硬件兼容性或特殊网络环境问题需要结合虚拟化平台的日志进一步分析。我自己在实际操作中的最大体会是虚拟机的网络排障很大程度上就是一个控制变量的过程。先确认模式再确认宿主机再看虚拟机内配置最后才考虑驱动和兼容性。层层递进不要跳层去瞎猜。还有一个小技巧想分享给大家在改动任何配置文件之前先做一次快照或备份。别觉得麻烦很多时候你改了netplan配置后apply失败连网络带SSH一起断了那时候再想还原有备份和没备份完全是两种处境。稳妥永远是虚拟化环境中最重要的操作原则。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
