1. 先搞清楚Ubuntu下的网络管理架构1.1 从ifconfig到Netplan为什么现在配置方式和以前不一样很多人刚接触Ubuntu时第一反应还是敲ifconfig发现报错找不到命令然后就开始慌。其实这很正常Ubuntu从17.10版本开始就不再预装net-tools了取而代之的是ip命令以及更上层的网络配置工具Netplan。这个变化不是Ubuntu故意折腾人而是因为老一套的/etc/network/interfaces写法虽然简单直接但遇到NetworkManager、桌面环境、云服务器这些场景时就显得力不从心。简单理解就是老的配置文件只管一块网卡新环境往往要同时管DHCP、多个网卡、虚拟交换机甚至容器网络继续用老办法就会出现“改了不生效”“重启就丢配置”这些经典问题。Netplan本质上是一个“配置翻译层”你写的YAML文件会被它转换成后端使用的配置格式。默认情况下桌面版Ubuntu的后端是NetworkManager服务器版的后端是systemd-networkd。你只需要写一套Netplan配置它会自动处理后端差异。这一点对新手特别友好你不用关心底层到底是谁在执行只要YAML格式没写错netplan apply一下就能生效。我见过不少教程让你直接改/etc/network/interfaces然后service networking restart这在老版本Ubuntu上确实有效但放现在容易遇到两个问题一是文件本身可能根本不会生效因为新版本系统默认不读取它二是即便你把它改好了NetworkManager可能会在你重启后覆盖网卡设置。所以如果你用的是20.04、22.04、24.04这类新版本老老实实用Netplan才是正路。1.2 网卡命名规则eno1、ens33、eth0这些名字到底怎么来的配置网络之前第一步永远是找到网卡的真实名字。现在Ubuntu的网卡命名方式继承了systemd的规则不再沿用以前的eth0这种顺序命名。命名前缀含义大致是这样en代表以太网Ethernetwl代表无线网卡WLANww代表WWAN无线广域网。后面跟的字母和数字取决于网卡的物理位置和固件信息比如eno1中的o表示板载onboardens33中的s表示PCIe插槽位置enp3s0则代表PCI总线3号插槽0号端口。虚拟机里常见到ens33、ens160、enp0s3这类名字这跟虚拟网卡的PCI设备分配位置直接相关所以不同虚拟化平台下名字不一样很正常。比如VMware虚拟机常见ens33VirtualBox常见enp0s3某些云服务器上则干脆看不到物理网卡名而是eth0加一堆虚拟网卡别名。查看当前系统网卡的方法很简单执行ip addr或ip link show就能看到所有网络接口以及MAC地址、IP地址、状态。如果你在虚拟机里装了Ubuntu却查不到网卡或者只有lo回环接口多半是虚拟机没启用网卡设备或者网卡类型选得不对这个后面会重点说。1.3 分清两个常见工具ip命令 vs ifconfig以及NetworkManager的作用ifconfig之所以让很多人念念不忘是因为它输出格式一看就懂ip addr刚接触时密密麻麻一堆前缀。但ifconfig已经处于维护状态很多新功能不支持比如查看路由表要用route -n而不是ip route操作VLAN、bridge这些高级网络对象时更是力不从心。我的建议很简单不要纠结直接转ip命令花十分钟熟悉ip addr、ip link、ip route三个子命令以后所有Linux系统都通用。至于NetworkManager它在桌面版Ubuntu上负责网络连接的自动管理图标、设置界面、命令行里的nmcli都是它的前端。桌面版装完系统就能上网就是它在背后自动用DHCP获取了地址。问题在于如果你手动改了Netplan配置NetworkManager可能会“抢回”网卡权限导致你的静态IP不生效或者时好时坏。出现这种情况可以检查/etc/Netplan下的YAML文件看有没有把网卡交给NetworkManager管理或者直接用nmcli查看连接状态来判断哪个模块在控制网卡。注意服务器版Ubuntu默认不启动NetworkManager安装桌面版后才会启用。如果服务器上装了桌面环境而你又想用Netplan管网络最好在Netplan配置里明确禁用NetworkManager对网卡的管理否则会出现各种诡异问题。2. 用Netplan配置静态IP最稳妥的官方方式2.1 Netplan配置文件长什么样核心字段逐个拆解Netplan的配置文件统一放在/etc/netplan/目录下文件名一般是01-network-manager-all.yaml或00-installer-config.yaml。不同版本文件名会有差异这没关系关键是目录里那个.yaml文件的内容。配置格式是YAML对缩进非常敏感多一个空格或少一个空格都可能导致netplan apply报错。下面展示一个最典型的静态IP配置适用于Ubuntu 20.04、22.04、24.04这些主流版本network: version: 2 renderer: networkd ethernets: ens33: dhcp4: false addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 8.8.8.8字段含义逐个说renderer指定后端networkd对应systemd-networkdNetworkManager对应桌面环境。服务器一般用networkd桌面版如果不想被NetworkManager干扰也可以用networkd。dhcp4是否启用IPv4的DHCP配置静态IP时设为false。addressesIP地址列表注意必须带子网掩码前缀写成192.168.1.100/24而不是192.168.1.100加netmask 255.255.255.0。routes定义路由默认网关写成default加viaIPv6下也有对应to: default的写法。nameserversDNS服务器地址可以配置多个用空格或数组形式都行。配置完执行sudo netplan apply再ip addr确认地址是否生效。如果一切正常ping一下网关或外部IP能通就说明配置OK了。2.2 配完后不生效三条命令和常见检查顺序很多新手配置完Netplan满怀信心执行netplan apply结果发现IP根本没变或者直接连不上网络了。我遇到过的情况大概有这么几类YAML格式写错了但apply没报错、网卡名字写错、DHCP和静态配置冲突、NetworkManager抢走了网卡控制权。排查顺序建议固定一下能省不少时间执行sudo netplan generate检查配置能否被正确解析如果这里有报错后面全是白搭。执行sudo netplan apply看有没有输出异常信息成功时通常是静默的。执行ip addr show查看目标网卡地址有没有变成新配置的IP。执行ip route show看默认路由是否指向预期网关。最后cat /etc/resolv.conf确认DNS有没有写入这个文件通常是指向systemd-resolved的链接文件内容会显示当前系统的DNS配置。如果以上步骤都正常但网络还是不通那就去排查物理链路了比如网线有没有插好、虚拟机有没有开网卡、交换机端口是否正常。这个顺序我逐渐养成习惯后配置网络再也没慌过。2.3 多网卡场景怎么配内网外网分开走的思路和踩坑生产环境里多网卡很常见比如一台服务器一块网卡连内网另一块连外网。这种场景下Netplan配置要比单网卡复杂一些因为你要要明确路由策略否则数据包会走错网卡。拿一个典型例子来说ens33连内网IP是192.168.10.10/24网关192.168.10.1ens35连外网IP是10.0.0.10/24网关10.0.0.1。如果只是简单地把两个网卡都配上系统可能会因为学到两条默认路由而出现“只能通一个网段”的现象。这时就要用routes里的table参数做策略路由或者把默认路由只分配给其中一张网卡另一张网卡只走内网段路由。一个比较实用的写法是这样的network: version: 2 ethernets: ens33: dhcp4: false addresses: - 192.168.10.10/24 routes: - to: 192.168.10.0/24 via: 192.168.10.1 nameservers: addresses: - 223.5.5.5 ens35: dhcp4: false addresses: - 10.0.0.10/24 routes: - to: default via: 10.0.0.1 nameservers: addresses: - 223.5.5.5这段配置里ens33只添加了去往内网网段的路由没有写入默认路由ens35则承担默认路由所有外部流量都从它走。这么做的好处是内网访问不会绕道外网访问也不会因为默认路由冲突而随机选网关。实际踩坑提示如果两张网卡都配置了默认网关且使用了相同的metric值Linux可能会在两者间负载均衡或随机选择导致外网连接时断时续。排查时用ip route show table main看当前生效的默认路由如果有多条就要么删掉多余的一条要么给不同路由设置不同的metric值。3. 虚拟机里跑Ubuntu网络模式选错了等于白配3.1 VMware三种网络模式的本质区别在VMware Workstation里创建虚拟机时网络适配器默认会选NAT模式安装Ubuntu后通常能直接上网。但如果你后来想改成静态IP、想让宿主机的其他电脑访问虚拟机就必须要理解VMware那三种网络模式到底是干嘛的。桥接模式Bridged虚拟机直接接入宿主机所在的物理局域网效果就像局域网里多出了一台独立电脑IP需要和宿主机在同一网段并且由路由器分配或手动指定。NAT模式虚拟机通过宿主机“借用”IP地址访问外部网络外部网络看到的访问来源是宿主机的IP。虚拟机之间和宿主机之间可以互通但局域网其他设备无法直接访问虚拟机。仅主机模式Host-Only相当于创建了一个完全隔离的虚拟网络只有宿主机和虚拟机在这个网络里虚拟机可以访问宿主机但默认不能访问外部网络除非宿主机开启IP转发。三种模式没有绝对的好坏取决于你的需求。只是大多数教程安装时默认NAT很方便但后面做SSH、挂载目录、联调时就发现不对劲了。所以装之前想清楚自己要用虚拟机来干什么网络模式的选择会直接影响后面的体验。3.2 桥接模式下怎么设置才能让虚拟机正常上网很多人把VMware网络模式改成桥接后虚拟机突然上不了网就开始怀疑系统配置有问题。其实大部分情况是物理机的网卡支持了多个网络接口而无线网卡桥接起来特别容易出问题。在VMware里切换桥接模式时需要选择具体桥接到哪张物理网卡。如果你的电脑同时有有线和无线网卡虚拟机桥接到了有线网卡但电脑实际用的是Wi-Fi那虚拟机当然上不了网。解决办法是在VMware的“虚拟网络编辑器”里把桥接模式关联的网卡改成实际在用的那张网卡或者干脆选择“自动”。桥接模式下虚拟机里的Ubuntu最好也配置成静态IP和宿主机在同一个网段网关指向路由器的IPDNS设置为公共DNS或路由器IP。比如宿主机是192.168.31.100路由器网关是192.168.31.1那虚拟机可以设置成192.168.31.200/24网关192.168.31.1。配置方式就是用第二节提到的Netplan写法把网卡名改成虚拟机里的实际网卡名。这样做完之后不仅虚拟机本身可以上网局域网里其他设备也能直接通过192.168.31.200访问虚拟机做SSH、Web服务、数据库联调都很方便。3.3 宿主机和虚拟机互通的几种方式如果只是想让宿主机和虚拟机互相访问NAT模式其实最简单。NAT模式下虚拟机通常有个类似192.168.x.x的地址宿主机可以直接ping通虚拟机虚拟机也能通过NAT地址访问宿主机。但反过来如果虚拟机改了静态IP可能会丢失NAT网段下的地址导致宿主机无法访问。一个稳妥的做法是在VMware的NAT设置里记住虚拟网络的网段比如192.168.88.0/24然后把虚拟机的静态IP设置成这个网段内的地址比如192.168.88.10。宿主机通常在这个网段里占用一个地址比如192.168.88.1或192.168.88.2不同版本有差异这样两者就能互访。还有人喜欢用Host-Only模式做隔离环境这时候虚拟机只能和宿主机通信没有外部网络。如果需要外网可以在宿主机上开启Internet连接共享或者额外加一块NAT网卡做“双网卡”方案一块网卡走Host-Only供内部通信另一块网卡走NAT供外部上网。这种玩法在搭建实验环境时非常实用配置起来也不复杂就是多一张网卡、多一点Netplan配置的事。3.4 VirtualBox下的类似场景补充VirtualBox的网络模式和VMware大同小异对应关系分别是“桥接”、“网络地址转换NAT”、“仅主机网络Host-Only”。有个显著区别是VirtualBox的NAT模式默认没有提供宿主机到虚拟机的端口转发如果你要在NAT模式下SSH进虚拟机需要手动在“端口转发”规则里配置比如把宿主机的2222端口转发到虚拟机的22端口。另外VirtualBox默认会创建一块虚拟网卡网段通常固定为10.0.2.0/24虚拟机的原始NAT地址一般是10.0.2.15网关10.0.2.2。如果你在VirtualBox里使用Ubuntu后网络不通先检查虚拟机的网络适配器是不是选成了“未连接”这个错误我在初学者环境里见过太多次了。实操心得不管VMware还是VirtualBox安装Ubuntu时如果网络连不上系统安装向导里后续下载更新、安装第三方驱动这些步骤会卡很久很多人误以为是系统卡死了。建议在安装界面先跳过“下载更新”装完系统进入桌面再慢慢调网络这样能省下大量等待时间。4. SSH远程连接配置完成后第一个要验证的能力4.1 Ubuntu默认没开SSH几步把它打开Minimal版Ubuntu安装完后连SSH服务都没有桌面版即使装了OpenSSH Server也很少默认开启。很多人直接用Xshell连接Ubuntu失败第一反应是IP配错了其实很可能只是服务没装、没启动或者防火墙拦住了。安装和启动过程其实就三条命令sudo apt update sudo apt install -y openssh-server sudo systemctl enable --now ssh装完以后用sudo systemctl status ssh确认状态是active (running)再用ip addr查到IP地址Xshell里填主机IP端口默认22用户名填你登录系统时的用户名就能连上了。如果你习惯用root直接登录需要额外修改/etc/ssh/sshd_config把PermitRootLogin prohibit-password改成PermitRootLogin yes然后重启SSH服务。不过我个人建议创建普通用户加sudo权限然后配置密钥登录安全性和便捷性都会更好。4.2 连不上的时候按这个顺序排查SSH连不上是网络配置里最高频的故障之一。我总结了一套排查顺序按部就班走一遍基本都能定位问题。先ping目标主机IP如果ping不通说明网络层就有问题SSH肯定也连不上。这时回到基础网络配置检查IP、网关、网段。如果ping得通但SSH连不上检查SSH服务状态systemctl status ssh是否正常。再确认端口有没有被监听ss -lntp | grep 22如果没输出说明SSH服务没起来或端口不对。如果服务正常检查防火墙sudo ufw status看到22/tcp被拦截时放行sudo ufw allow 22/tcp。最后确认虚拟机网络模式。NAT模式下宿主机访问虚拟机一般没问题但局域网其他设备要访问虚拟机必须改成桥接模式否则肯定失败。这里有个容易忽略的细节云服务器或安装了桌面发行版的电脑可能会有多个网卡SSH绑定的IP可能不匹配。查看ss -lntp时分清楚是监听了0.0.0.0:22还是只监听了某个IP如果只监听内网IP外网连接自然失败。4.3 修改端口、密钥登录和防火墙放行的细节为了提高安全性很多人喜欢把SSH默认端口从22改成其他端口比如2222。改完后必须记得重启SSH服务并且把防火墙里旧端口规则删掉、新端口加进去否则自己把自己关在门外。密钥登录配置也不复杂本地生成一对密钥把公钥内容追加到远程主机的~/.ssh/authorized_keys文件里权限设对就行。记住两点~/.ssh目录权限最好是700authorized_keys文件权限最好是600权限太宽松SSH会拒绝加载。防火墙方面Ubuntu默认装了ufw如果之前开启过ufw enable那所有端口默认都会被拦。常用命令有sudo ufw status verbose查看状态sudo ufw allow 22/tcp放行端口sudo ufw reload重载规则。不建议直接systemctl stop ufw图省事生产环境还是要保持防火墙开启的。注意在云服务器上修改SSH端口或防火墙前先确保云控制台的安全组规则也放行了新端口否则改了以后会直接失联这种坑踩一次就长记性了。5. 网络配置常见问题与排查技巧实录5.1 DNS解析问题能ping通IP但上不了网多半是这里有时候静态IP配好了能ping通192.168.1.1网关也能ping通223.5.5.5这种公网IP但输入www.baidu.com却提示无法解析域名。这个现象基本确定是DNS配置有问题。查看当前DNS配置用resolvectl status或者直接看cat /etc/resolv.conf。Ubuntu新版通常由systemd-resolved管理这个文件所以直接改resolv.conf是无意义的重启后就回滚了。正确做法是在Netplan配置里写nameservers段或者在NetworkManager连接设置里修改DNS。如果确认Netplan已经配置了DNS但ping www.baidu.com还是不行可以试试临时指定DNS来验证网络本身是否通畅resolvectl query www.baidu.com这个命令会显示解析结果和使用的DNS服务器能快速定位是系统DNS配置问题还是上游DNS服务器本身有问题。实际经验里联通、电信家庭路由器自带的DNS解析有时候很慢换成223.5.5.5阿里DNS或119.29.29.29腾讯DNS通常能立刻改善。5.2 重启后配置丢失大概率是改错了文件“重启后IP又变回去了”这个问题几乎每周都能在社区看到。原因无非几种第一改的是运行时配置比如直接用ip addr add这种命令添加的IP没写入配置文件第二改了Netplan配置文件但没执行netplan apply重启后配置还在但没生效这情况相对少第三改错文件了比如编辑了/etc/network/interfaces但系统实际用的是NetworkManager或Netplan。正确做法是把修改落实到/etc/netplan/下的YAML文件里然后执行sudo netplan apply。如果你用的是NetworkManager也可以在图形界面里修改连接配置或者在nmcli里改注意方式统一别混着用。另外提醒一个细节如果你是克隆虚拟机后去改静态IP原始克隆源里的配置可能带有多余网卡规则导致新机器分配不到IP。遇到这种情况先netplan config看当前配置必要时把YAML里残留的网卡信息删掉再重新配置。5.3 DHCP和静态IP来回切换的管理技巧在开发和测试环境里今天用DHCP自动获取明天又要静态IP来回手改Netplan配置很麻烦。这里有个小技巧在同一份Netplan配置里同时保留DHCP和静态两种方式注释掉其中一种即可。比如network: version: 2 ethernets: ens33: dhcp4: true # addresses: # - 192.168.1.100/24 # routes: # - to: default # via: 192.168.1.1需要静态时把注释打开、dhcp4设为false需要自动获取时反过来。YAML里用#注释很统一切换起来只需编辑apply两步比重新写文件快得多。如果你更习惯用NetworkManagernmcli提供了灵活的profile管理方式用nmcli connection modify可以随时调整IPv4方法设置为auto或manual还不用动文件。桌面版用户推荐优先熟悉nmcli服务器无图形界面时用Netplan就好。5.4 双系统时间错乱与网络配置的关联问题装双系统的用户经常遇到日历时间不准八小时偏差这跟网络配置没有直接关系但很多人排查网络时总会顺手把时间也检查一遍所以我放进来提醒一下。Windows和Linux对硬件时钟的处理方式不一样Windows认为硬件时钟是本地时间Linux认为硬件时钟是UTC时间安装双系统时容易把硬件时钟写乱。解决办法是在Ubuntu里把硬件时钟改为本地时间sudo timedatectl set-local-rtc 1 --adjust-system-clock这个设置不会影响网络配置但能让双系统切换时少一个莫名其妙的问题。5.5 嵌入式开发板挂载Ubuntu目录的网络问题嵌入式和硬件开发的朋友经常要把开发板挂载Ubuntu主机上的NFS目录或者反过来用虚拟机里的Ubuntu作为交叉编译环境给板子传文件。这类场景依赖网络配置正确尤其是要保证虚拟机桥接或NAT模式下能和开发板在同一个网段里通信。我见过的最常见坑是防火墙拦截NFS相关端口比如2049、111等。在Ubuntu上配好NFS服务后如果开发板mount -t nfs总是超时可以先在Ubuntu上执行sudo ufw allow from 开发板IP来放行整个主机访问或者干脆先临时sudo ufw disable验证通了以后再精确配置规则。还有种情况是虚拟机网络模式选择了NAT但开发板在局域网里NAT模式下虚拟机无法被板子主动访问这时把网卡改成桥接模式基本能解决。实操提醒做嵌入式联调时尽量让Ubuntu、开发板、宿主机三者处于同一物理局域网网段并都把IP设置成静态。频繁使用DHCP会导致每次重启地址变动然后调试到一半又连不上了整个体验非常折磨。6. 网络配置思路的进阶建议聊了这么多其实都是从“不通”到“通”的过程。但我越来越觉得真正高质量的网络配置不是三下五除二让网通就算完事而是把整个过程理得明明白白明确设备角色、规划好IP、管理好网关和DNS、做好防火墙规则平时还得留好排查路径。无论是虚拟机、云服务器还是物理机这套思路都通用。遇到网络问题别急着在网上搜“Ubuntu 网络配置”然后照抄一堆代码先坐下来理一理自己的网络拓扑宿主机、虚拟机、路由器、开发板各自在哪个网段谁依赖谁谁应该走哪条网卡。想清楚了再动手改配置通常几分钟就能解决问题。否则今天改这个、明天试那个很容易把系统配置搞混乱到时候想回滚都不知道从哪开始。根据我个人经验最值得养成的习惯是每次配置完静态IP后顺手把网关、DNS、网卡名、网段这些关键信息写进一个备忘文件放到/etc/netplan/README或者自己的笔记里。等过了一个月、半年再回来看这份记录比任何教程都有用。