ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Ubuntu 20.04静态IP配置实战:Netplan与常见坑全解析

Ubuntu 20.04静态IP配置实战:Netplan与常见坑全解析 1. 网络不通时别急着改配置文件——先搞清楚谁在管你的网卡先讲一个我自己的惨痛经历。去年帮实验室一台装了Ubuntu 20.04的工控机配置静态IP当时照着网上老教程直接改了/etc/network/interfaces重启网络服务后机器直接失联了。后来才发现Ubuntu 20.04默认用的是Netplan压根儿不看interfaces文件我改了半天全白费还白白折腾了一个下午的网络排查。这个问题的根源在于很多网上的教程还在讲16.04甚至更老版本的配置方法而Ubuntu从18.04开始就已经切换到了Netplan作为默认网络配置工具。你如果拿旧方法去配新系统配置不生效是必然的。所以在你动手之前必须先搞清楚一个问题现在这台机器上到底是谁在管网络Ubuntu 20.04的网络管理架构是这样的底层是systemd-networkd或NetworkManager上层是Netplan负责把YAML格式的配置转换成底层工具的配置。你在/etc/netplan/目录下看到的01-network-manager-all.yaml或者99-config.yaml文件才是真正需要修改的地方。想判断当前网络由谁接管在终端里敲这行命令networkctl status或者看一下系统里到底跑了哪些网络服务systemctl status NetworkManager systemd-networkd如果NetworkManager是running状态说明GUI桌面环境下的网络管理优先常见于桌面版Ubuntu。如果systemd-networkd是running状态说明服务器版或精简安装环境Netplan直接管理。如果两个都在跑就得看Netplan配置里到底renderer指向谁。用ip addr看一下当前网卡命名Ubuntu 20.04的网卡一般叫ens33、enp3s0、eth0之类老教程里常写的eth0在部分新机器上可能不叫这个名字了千万先确认好再动手。2. 场景不同静态IP的配置路径完全不一样2.1 服务器版系统Netplan是唯一正确的入口如果你用的是Ubuntu Server 20.04没有桌面环境那Netplan就是唯一的管理入口。先看现有配置cat /etc/netplan/*.yaml典型的默认配置长这样network: version: 2 ethernets: ens33: dhcp4: true要改成静态IP参照下面的配置模板network: version: 2 ethernets: ens33: dhcp4: no addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 114.114.114.115 optional: true这里有几个容易踩坑的地方addresses后面写的/24代表子网掩码255.255.255.0对应关系一定要换算清楚否则网关和IP不同网段配置上去直接无法上网。routes里用的是to: default加via: 网关地址的写法有些老教程写的是gateway4: 192.168.1.1这个写法在Netplan的较新版本里已经被弃用了虽然目前还能用但会警告建议直接用routes的写法。nameservers里我习惯填国内公共DNS和运营商DNS223.5.5.5是阿里DNS119.29.29.29是腾讯DNS按你的实际网络环境来。最后那个optional: true是给“开机时网卡还没就绪但系统不卡住”用的。不写的话有些主板网卡驱动加载慢开机过程会在网络服务上等好几秒甚至失败。配置改完后用这条命令应用sudo netplan apply在应用前先建议用sudo netplan try试试这个命令会在10秒内让你确认配置是否正常如果应用后SSH断开10秒后会自动回滚配置避免把自己锁在机器外面。2.2 虚拟机场景NAT模式和桥接模式的网关要区分清楚很多人在VMware或VirtualBox里装Ubuntu 20.04配静态IP时搞不懂为什么填了静态IP就不通了。我以VMware为例说明一下。VMware的虚拟网络编辑器里常见的两个模式模式默认网段默认网关使用场景NAT模式VMnet8192.168.146.0/24192.168.146.2虚拟机共享宿主机上网外部无法直接访问虚拟机桥接模式VMnet0与宿主机同网段与宿主机网关相同虚拟机作为独立设备接入局域网可以被其他机器访问在NAT模式下配置静态IP如果虚拟机之前是DHCP自动获取的你得先看一眼当前分配到的IP是多少ip addr showVMware的NAT网段默认是192.168.146.x但不同人设置不一样看实际分配来判断网段。比如虚拟机拿到的是192.168.146.128那你手动配置时必须在这个网段内挑一个没被占用的地址网关填192.168.146.2掩码填/24。千万注意网关不要填成了192.168.146.1——虽然在VMware里这个地址也通但NAT模式下真正的网关是.2填.1的话上不了外网。桥接模式就简单一点把虚拟机的IP配置成和宿主机同一个网段网关也用同一个DNS也一致就行。唯一要注意的是别和局域网里其他设备的IP冲突。2.3 桌面版系统图形界面和命令行的取舍Ubuntu 20.04桌面版默认是NetworkManager在管网络你直接在设置里改是最稳妥的。打开设置→网络→点击有线连接旁边的齿轮图标→IPv4选项卡把自动(DHCP)改成手动然后填地址、掩码、网关和DNS。但桌面版也可以改Netplan配置文件改之前要先确认/etc/netplan/下的yaml文件renderer是不是NetworkManagernetwork: version: 2 renderer: NetworkManager如果renderer是NetworkManager那么你改了Netplan配置后还必须用sudo netplan apply让NetworkManager接管新的配置。这里有个很典型的坑桌面版装好系统后默认是DHCP你在文件里写好静态IP后apply图形界面里的IP不一定立刻变需要断开网络重连或重启NetworkManager服务才生效。所以桌面版我的建议是只是简单设一个固定地址直接图形界面操作省事。需要配置多网卡、VLAN、网桥等复杂网络必须走Netplan文件。3. 那些配完还是上不了网的常见坑一次说清3.1 子网掩码和网关不匹配网络时通时断如果你填写的IP地址和网关不在同一个网段表现是能ping通网关但上不了外网或者外网时通时不通。举个例子网段规划是192.168.199.1作为网关结果你IP填的是192.168.1.199掩码是255.255.255.0那你的主机找网关时会发现大家不在一栋楼不同的网段数据包根本送不出去。正确做法是先通过ip route查看原来的默认路由看网关到底是什么地址。ip route输出里default via 192.168.199.1 dev ens33里的192.168.199.1就是网关。你的静态IP必须和这个网关处于同一个/24网段内。3.2 DNS配置了却没有生效很多时候IP通了、网关也通了但浏览器打不开网页ping baidu.com提示未知域名。这种99%是DNS的问题。Ubuntu 20.04有个systemd-resolved服务DNS解析的全过程是这样的你的程序查询DNS时会先读/etc/resolv.conf而这个文件在20.04上是个软链接指向/run/systemd/resolve/stub-resolv.conf里面写的DNS服务器地址是127.0.0.53这是systemd-resolved自己监听的本地解析器。你的DNS请求先发到本地再由它转发给真正的DNS服务器。所以你在/etc/resolv.conf里手动改DNS是不显示的也不推荐直接改。正确方式是改Netplan里nameservers部分然后sudo netplan apply再用命令确认resolvectl status | grep -A2 DNS Server看到你自己的DNS地址就说明生效了。如果你想立刻测试直接ping 223.5.5.5看通不通通了再ping www.baidu.com这样就能区分是网络层问题还是DNS解析层问题。3.3 系统有多个网卡默认路由走错了口子这坑主要在多网卡服务器上出现。比如服务器有两张网卡一张连着内网192.168.10.x一张连着外网192.168.1.x你给两张网卡都配了default via的默认路由系统会按照路由表的优先级来选经常出现内网流量绕到外网口或者外网流量跑到内网口的情况。配置多网卡时默认路由只应该保留一个另一个网卡不要配置routes的default只在addresses里配IP就行。如果你需要同时访问多个不同网段就在Netplan里配置多条静态路由network: version: 2 ethernets: ens160: dhcp4: no addresses: - 192.168.10.100/24 routes: - to: default via: 192.168.10.1 - to: 172.16.0.0/16 via: 192.168.10.254第一条是默认路由决定所有未知网段的数据包怎么走第二条是把访问172.16.0.0/16这个内网网段的流量专门走192.168.10.254这个三层交换机的地址。3.4 IP地址冲突网络一会儿通一会儿断静态IP和局域网内其他设备地址重复时表现极其隐蔽刚配完用着没问题过一会儿网络突然断了过几秒又自己恢复来回折腾。排查方式是在本机上ping一下你设置的IP如果发现Reply from 本机IP: Destination host unreachable或者能ping通但ARP信息反复变动大概率就是IP冲突了。Linux里可以用arping检测sudo apt install iputils-arping -y sudo arping -I ens33 -c 3 192.168.1.100如果收到其他设备MAC地址的响应就说明这个IP被占用了。换个没占用的地址或者进路由器后台查一下IP分配情况。3.5 断电重启后配置丢失这是一个很多人特别容易忽略的点。重启后配置丢了最常见的两个原因改的是临时配置比如直接用ifconfig ens33 192.168.1.100 netmask 255.255.255.0 up这种命令设置没有写进Netplan文件重启自然就丢了。写入了Netplan文件但文件的权限不对或者格式有误。Netplan对YAML格式的缩进要求极其严格少一个空格或者tab和空格混用netplan apply直接报错。建议每次改完配置后用sudo netplan try验证格式再重启一次机器确认配置还在。这个习惯能帮你省掉很多种莫名其妙的问题。4. 两个真实故障排查过程静态IP配好后的连锁反应4.1 案例一网关多址导致的上网断断续续那台工控机配好静态IP后当天一切正常第二天网络开始断断续续。我登录上去ip route看到默认路由指向192.168.199.1ping网关也通但延时不稳。后来抓包发现问题出在网关设备有多个接口导致ARP请求一直无法正确应答。最终是到交换机上确认了核心网关的正确IP是192.168.199.254在Netplan里改了一下路由就恢复了。这个案例告诉我配静态IP时网关地址一定要到核心设备上去核实不要盲目相信之前文档里的IP特别是改过网络结构的办公环境。4.2 案例二虚拟机克隆后网卡名变了用模板克隆出的Ubuntu虚拟机启动后发现原来是ens33的网卡变成了ens38但Netplan配置里还写着ens33。netplan apply能执行成功但没有任何实际作用ip addr看还是没配上静态IP。这是因为克隆机的网卡MAC变了udev规则重新给它分配了网络接口名。解决方式是用ip addr确认新网卡名。修改Netplan里的ens33为ens38。或者直接把YAML里的匹配规则改成通配符方式network: version: 2 ethernets: en*: dhcp4: no addresses: - 192.168.199.100/24用通配符匹配网卡名以后无论接口名怎么变配置都能套用上。5. 进阶心法一劳永逸的Netplan配置习惯如果你经常在Ubuntu 20.04上做开发、部署配静态IP算是基本功但有三个习惯是我经历过无数踩坑后总结出来的直接分享给你。配置前先备份。在修改任何Netplan文件之前养成备份习惯sudo cp /etc/netplan/01-network-manager-all.yaml /etc/netplan/01-network-manager-all.yaml.bak备份文件不要放在/etc/netplan/目录下后缀还是.yaml否则netplan apply会把它也当成一个配置项加载导致配置冲突。备份文件正确做法是换个扩展名比如.bak或者挪到~/下。能远程就不要本地配置。如果是给机房服务器配置改静态IP前必须确认有带外管理如IPMI、iDRAC或者现场有人能操作否则配置一应用网络就断你SSH连接直接掉线人在外地就彻底失联了。配置联动的服务。静态IP配好后很多服务要跟着改否则问题不断SSH连接工具里的主机IP要更新。如果配了NFS、Samba等共享服务客户端挂载的地址也要改。定时任务、脚本里写死的IP要全局搜一遍。特别是跑深度学习训练或机器人开发环境的朋友IP一变roscore、ssh、docker容器端口映射全都得跟着重来一遍。另外Ubuntu 20.04的Netplan还有一个不太显眼的特性如果你在系统更新时从较老版本升级到20.04Netplan配置可能是自动生成的格式和手动写的不完全一样。这时你最好用sudo nano /etc/netplan/*.yaml打开看看实际内容不要直接套网上的模板覆盖否则原有网卡命名、渲染器等信息可能被错误匹配。还有一点嵌入式设备上装Ubuntu 20.04比如树莓派或NPU开发板树莓派的官方Ubuntu镜像通常用的是cloud-init来配置网络/etc/netplan/下的文件是cloud-init动态生成的。这种情况下你改了Netplan文件重启后被cloud-init覆盖回去静态IP照样配不上。正确做法是禁用cloud-init的网络配置功能sudo touch /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg然后往里面写一行network: {config: disabled}再去改Netplan文件这样才能真正生效。6. 我自己的一套标准流程按这个顺序基本不会翻车最后分享一套我总结的标准操作流程每次配静态IP都按这个顺序走步骤简单不容易漏确认网卡名ip addr记住类似ens33的接口名。先看当前网络信息ip route和ip addr记下原来的网关、IP、DNS。备份原有Netplan配置sudo cp /etc/netplan/*.yaml ~/netplan.backup。编辑配置sudo nano /etc/netplan/99-static-ip.yaml按前面给出的模板填写。验证配置格式sudo netplan try观察网络是否正常。确认生效ip addr和ip route再ping一下网关和外网。重启验证sudo reboot确保配置在重启后依然生效。每次配完都有一种“这台机器终于安分了”的感觉。配置静态IP这事本身不难难的是搞清楚你所在的环境里各种隐藏的关系——谁管网络、网关在哪、有没有冲突。把这些梳理清楚了剩下的就是在YAML里填几个数字的事。做开发的人都知道环境问题的排查往往比功能实现更耗时提前把网络层的基础打好后面能省下大把时间和不必要的麻烦。
返回列表