这周我帮一个同事排查服务器网络问题他配好静态IP后重启了一下发现配置全丢了网卡回到了DHCP自动获取的状态。聊了几句才知道他前一步用nmcli改的连接后一步又在/etc/network/interfaces里写了一大段配置两边互相不知道对方的存在一通操作下来自然白费。这其实是很多刚接触Linux网络配置的人都会踩的坑——Linux网络基础教会了你命令但你未必清楚这些命令背后改的是哪个文件、那个文件又归谁管。这系列文章我原本计划分三篇这是第二篇名字就叫“Linux网络基础2”。上一篇我们聊了TCP/IP协议栈、socket通信、端口和服务的基础概念这一篇我打算把重心放在如何真正上手配置和管理Linux网络上重点讲清楚网卡配置、网络服务管理、路由和连通性排查这几条主线。文章会覆盖systemd-networkd、Netplan、NetworkManager三种主流配置方式也会把常见故障的排查思路整理出来适合运维新手入门也适合那些已经会配IP但遇到问题时没有清晰排查思路的人看。1. 先搞清Linux网络的三层结构1.1 网卡配置、网络服务、内核路由各管什么很多初学者最容易搞混的一件事就是不知道Linux的网络配置到底分几个层面。其实拆开来看就三条线内核协议栈负责实际收发数据包网络管理服务负责把用户配置转化成内核能理解的规则配置文件则是网络管理服务读取的数据来源。打个比方内核网络协议栈就像城市里已经修好的高速路数据包在上面跑得飞快但它不知道路该怎么规划网络管理服务相当于交通指挥中心负责根据预案和实时情况调整红绿灯、设置限速牌而配置文件就是那份应急预案指挥中心照着上面的内容执行。你改配置文件相当于在改预案你用命令直接修改网络参数相当于指挥中心临时下达指令。两者的区别在于预案是持久化的重启后依然生效临时指令只管到本次关机前。这也解释了一个常见的困惑为什么我在一台机器上执行ip addr add添加了IP地址重启之后就不见了因为你只动了内核层面的参数没有把配置写进网络管理服务读取的配置文件里。反过来为什么我改了/etc/network/interfaces之后重启才生效运行中的系统却还没变因为系统正在运行的网络参数还停留在内核里你必须让网络服务重新加载配置把新预案同步到指挥中心。了解这个三层结构之后再看任何一篇网络配置教程你都能立刻判断出对方教的是哪一层操作也就能理解每个步骤到底为什么存在。1.2 网卡命名规则与查看方法配置网络的第一步是搞清楚机器上有哪些网卡以及它们的名字是什么。如果你运行ip addr看到输出里有eth0、ens33、enp0s3、eno1这类名字它们其实不是乱起的背后有一套命名规则。老派的Linux发行版基本都用eth0、eth1这种按探测顺序命名的格式从内核2.4时代一直用到systemd出现之前。后来因为网卡探测顺序不稳定插入新网卡可能导致编号变化systemd和biosdevname搞出了一套更可预测的命名方案en代表以太网后面的字母和数字分别表示设备所在的总线位置、PCIe插槽编号或MAC地址。比如enp0s3的意思就是以太网设备位于PCIe总线0、插槽3的位置。如果你在虚拟机里看到ens33那是VMware虚拟网卡的固定槽位编号重启不会变。了解每块网卡叫什么之后就要学会查看它的状态。最常用的两条命令是ip addr或简写ip a和ip link# 查看所有网卡及其IP地址 ip addr # 只查看网卡的链路层状态UP/DOWN、MAC地址 ip link # 查看某块网卡详细信息 ip -d link show eth0ip addr输出里state UP表示网卡链路正常启用inet后面跟的是IPv4地址inet6是IPv6地址。我习惯先跑一次ip addr确认现状再去改配置这个习惯帮我减少了大量“改了半天发现原本就没问题”的无效工作。另外网卡名字差了后面配置文件的Match规则就找不到对应设备这是初学者特别容易忽略的细节。提示别再用ifconfig了。虽然它在很多老教程里还是主角但现代发行版默认都不装net-tools了ip命令才是iproute2套件中的正统工具。如果你发现ifconfig能用要么是老系统要么是自己装的。2. 动手配置从网卡到DNS的完整链路2.1 基于systemd-networkd的静态IP配置systemd-networkd是目前很多服务器版Linux默认的网络管理服务设计思路清晰配置文件也简单。它读取的是/etc/systemd/network/目录下的.network文件这些文件以优先级数字越小越优先排列语法是类似INI的键值对格式。给一块网卡配静态IP最典型的配置长这样# /etc/systemd/network/10-eth0.network [Match] Nameeth0 [Network] Address192.168.1.100/24 Gateway192.168.1.1 DNS223.5.5.5 DNS8.8.8.8我来解释下每个字段的含义。[Match]段里的Name告诉networkd这条规则管的是哪块网卡如果网卡名匹配不上整个配置直接忽略[Network]段里的Address是你要分配给网卡的IP和子网掩码用CIDR写法/24等价于255.255.255.0Gateway是默认网关DNS是域名服务器地址。写完这个文件之后你需要重启networkd服务让配置生效sudo systemctl restart systemd-networkd重启后再看ip addr网卡上应该已经多了一个192.168.1.100/24的地址。如果你希望系统开机自动应用配置还应该确认networkd服务是开机自启的sudo systemctl enable --now systemd-networkd这里有个典型的坑很多人只写了.network文件但忘了启用服务结果重启后配置依旧没生效。这个路径其实就藏在前面说的三层结构里你写了预案配置文件但预案没有被执行机构systemd-networkd服务读取自然无效。如果网卡需要同时配置多个IP地址比如一个管理IP、一个业务IP直接在[Network]段里写两条Address行就行。DHCP方式也一样把Address、Gateway、DNS全不写改成DHCPyes即可。2.2 Netplan与NetworkManager的配置差异如果你的机器是Ubuntu大概率会遇到Netplan。Netplan是一个配置前端用YAML语法描述网络方案然后选择后端比如systemd-networkd或NetworkManager来实施。默认配置在/etc/netplan/目录下常见的文件名是00-installer-config.yaml或50-cloud-init.yaml。典型的Netplan静态IP配置长这样# /etc/netplan/00-installer-config.yaml network: version: 2 ethernets: eth0: addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 8.8.8.8写完YAML文件后先跑sudo netplan generate检查配置语法再执行sudo netplan apply让它生效。这里特别强调语法检查因为YAML对缩进极其敏感一个多打出来的空格就能让整个配置无法解析而且报错信息往往看不出问题在哪。我见过太多人把YAML缩进从2个空格改成4个空格后整个配置就失效了。我推荐一个调试习惯执行完netplan apply之后先看看/run/systemd/network/目录下生成了哪些.network文件。这些文件是Netplan翻译之后真正交给systemd-networkd执行的最终版本读一遍它们就能确认你的意图有没有正确转化排查起来直指问题核心。而NetworkManager又是另一套完全不同的方案它常见于桌面版发行版、RHEL/Rocky系服务器以及需要频繁切换网络环境比如笔记本插网线、连Wi-Fi的场景。NetworkManager用连接配置connection profile的形式管理网络每个连接配置相当于一套独立的网络参数集合你可以随时切换激活哪套配置。用nmcli配置静态IP的命令略多一点# 查看当前的连接配置 nmcli connection show # 在新连接上配置静态IP sudo nmcli connection modify eth0 ipv4.method manual \ ipv4.addresses 192.168.1.100/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns 223.5.5.5 # 激活配置 sudo nmcli connection up eth0这套命令的逻辑是先找到管理网卡的那个连接配置名字可能和网卡名相同也可能像“Wired connection 1”这样然后修改它的IPv4设置最后激活。NetworkManager的优点是动态切换方便但如果你是个服务器管理员我反而建议严格控制它的使用范围尤其是不要让它和systemd-networkd同时管理同一块网卡——两台“指挥中心”抢一辆车结果就是配置混乱。2.3 DNS配置的几个坑DNS这一项看着简单实则暗坑最多。传统Linux系统里DNS配置写在/etc/resolv.conf格式非常简单nameserver 223.5.5.5 nameserver 8.8.8.8但这个文件在现代系统上的地位很特殊——它往往不是一个真实文件而是一个软链接。如果你运行ls -l /etc/resolv.conf大概率会看到它指向/run/systemd/resolve/stub-resolv.conf或/run/NetworkManager/resolv.conf。也就是说你直接编辑/etc/resolv.conf改动可能随时被其他服务覆盖。Ubuntu系统尤其需要警惕systemd-resolved的存在。systemd-resolved默认监听127.0.0.53端口会把自己的地址写进resolv.conf所有DNS查询先经过它转发。如果你想绕过它直接用上游DNS要么修改systemd-resolved的配置要么干脆禁用这个服务改用systemd-networkd直接管理DNS然后删掉resolv.conf的软链接换成普通文件。不过这么做之前要想清楚systemd-resolved还承担着缓存的职责去掉之后DNS解析性能可能微微下降。我的建议是能用netplan或networkd管理DNS就尽量别手动改resolv.conf。在networkd的配置文件里写DNS条目或者用nmcli的ipv4.dns参数系统会自动生成正确的resolv.conf。如果确实需要手动指定记得改用resolvectl dns eth0 223.5.5.5这样的命令在systemd-resolved环境里而不是直接编辑软链接文件。注意改了DNS之后别急着说“没生效”——先用resolvectl statussystemd-resolved环境或nmcli device show eth0NetworkManager环境看看实际的DNS配置是啥再用dig或nslookup测试解析基本就能定位问题出在哪一层。3. 路由与连通性排查链路问题的正确姿势3.1 路由表怎么读默认网关为什么重要配置好网卡有了IP不代表机器就能任意访问网络了。IP地址负责回答“我是谁”而“数据该往哪走”这件事由路由表说了算。Linux内核的路由表是一个决策树当你要访问一个目标地址内核按优先级从上到下匹配路由表项找到匹配项就走对应的网关或网卡。查看路由表的命令是ip route或ip r$ ip route default via 192.168.1.1 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100输出里192.168.1.0/24那条叫直连路由意思是访问这个网段内的地址直接通过eth0发送不需要经过网关default via 192.168.1.1则是默认路由凡是没有更精确匹配的目标全部丢给网关192.168.1.1处理。默认路由是通往外界的最后一道门它一旦丢失机器立刻“上不了网”。这里我再多说一句路由匹配的逻辑。内核选路时匹配的是“最长前缀优先”——比如目标地址是192.168.1.50它既能匹配192.168.1.0/24也能匹配默认路由0.0.0.0/0但前者的前缀更长、更精确所以走直连路由而访问8.8.8.8时直连路由完全匹配不上只能走默认路由。这个机制你理解透了排查“ping不通但路由好像没错”这类问题就有思路了——你完全可以手动添加一条更精确的路由让流量走指定出口比如# 访问10.10.0.0/16时强制走192.168.2.1这个网关 sudo ip route add 10.10.0.0/16 via 192.168.2.1临时添加的路由需要写入配置才能持久化按发行版不同可以写进networkd的[Route]段、Netplan的routes:列表或ifcfg文件的ROUTE字段。一个实用技巧先临时ip route add验证效果确认没问题再写进配置文件。这样避免了配置文件一改就出问题、来回试错浪费时间的尴尬。3.2 从ping到traceroute的排查路径排查网络连通性问题我有一套固定的递进式流程基本能快速圈定故障范围。第一步验证协议栈本身ping 127.0.0.1。如果这个都通不了说明本机TCP/IP协议栈有问题这个概率极低但值得花一秒排除。第二步验证本机IPping自己网卡的IP地址比如ping 192.168.1.100。这一步通过代表网卡和IP配置正常协议栈能正确收发本机流量。第三步验证网关ping默认网关ping 192.168.1.1。通了说明物理链路、二层交换、本机三层路由都没问题不通则往后定位——先ip link看网卡状态再检查网线或虚拟交换机。第四步验证外网ping一个公网IP比如114.114.114.114或223.5.5.5。如果不通但第三步通说明本机依赖的上一级路由有问题可能是网关缺路由也可能是ISP侧链路故障。第五步验证DNSping通了外网IP之后再试ping www.example.com或dig www.example.com。如果IP通但域名不通问题就限定在DNS解析环节回到前面说的DNS排查那条线。这套流程每一步都对应一个特定故障域帮你在脑子里形成一个倒树状排查图。凡是能通一层就把故障范围缩到上面那一层每次全靠感觉猜哪里出问题效率极低。当你走完上面五步发现某段路径不通但又不是本机问题就需要traceroute出场了。它沿途向每个路由节点发送探测包能看到数据包到底走到哪一跳就断了traceroute -n 8.8.8.8加-n参数表示不做反解域名直接显示IP速度快很多。如果你发现前两跳正常第三跳开始* * *那问题基本卡在这一段链路上。不要省略这一步很多人一上来就traceroute却不会看输出反而被满屏的星号搞懵。星号不一定代表故障——有些路由器出于安全考虑不回复TTL超时类型的ICMP包但数据仍然正常转发。判断标准是如果星号之后的下一跳还能继续通说明那一段只是“不回应探测”而已如果星号之后输出的路径断了那才是真断点。3.3 用ss与ip命令确认服务状态网络连通性解决了下一步往往是确认“服务到底听没听端口”。比如你部署了一个Web服务浏览器访问却连不上除了服务器防火墙的因素还得看端口监听状态。这方面ss基本是查端口的首选命令# 查看所有TCP监听端口 ss -tlnp # 查看所有UDP监听端口 ss -ulnp # 查看所有已建立的连接包括远程地址 ss -tnp参数含义拆开说-t只显示TCP-u只显示UDP-l只显示监听状态LISTEN-n不做域名和端口名解析-p显示进程信息。其中-p需要root权限否则看不到是哪个进程在监听。你运行之后会看到类似这样的输出LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:((nginx,pid1234,fd9))0.0.0.0:80表示nginx监听在所有网卡的80端口上fd9是进程内部的文件描述符编号。如果你发现服务明明启动了却不监听任何端口大概率是配置里的listen地址写错或者启动时直接崩了用systemctl status或直接看进程日志就能发现原因。配合ss的另一个常用工具是ping和arp但这里我想特别提醒在测试端口连通性时光ping通不代表TCP端口就开放——三层IP通四层端口可能是关闭的。要测试某个远程端口开没开可以直接用nc比如nc -zv 192.168.1.200 3306-z不发送数据只检查端口联通-v输出详情。这个习惯帮我快速越过“网络通但服务没起”这类尴尬场景少走很多弯路。4. 常见故障速查与实用建议4.1 配置丢失、重启失效的典型场景前面已经说过配置丢失最常见的根源就是改错了配置层。我这边遇到过的代表性场景按发生频率排一下第一类是改了配置文件但没重启网络服务。举例来说你在/etc/systemd/network/下新增了一个.network文件系统当前并没有加载运行中的网络自然还是旧配置。解决方式是确认网络管理服务是什么然后systemctl restart systemd-networkd或systemctl restart NetworkManager。第二类是NetworkManager和systemd-networkd同时管同一块网卡。很多系统安装时默认启用NetworkManager你又开了systemd-networkd两套服务都尝试管理同一块设备。结果时而你改的配置生效时而另一套配置覆盖了你。处理方法很干脆选一个服务管网络另一个停掉并禁用。比如留NetworkManager就systemctl disable --now systemd-networkd。第三类是只配置了临时路由或临时IP没写进配置文件。这种情况最隐蔽因为你当下测试一切正常一重启就打回原形。我在2.1节里已经反复强调过三层结构的区别这里就不再赘述了。另外还有一个跟重启失效密切相关的细节如果你用的是DHCP获取地址网卡本身没问题但DHCP服务器比如路由器分配地址租约过期后没有续租系统会在租约到期后释放IP。遇到这种情况用dhclient -r释放当前租约再dhclient重新获取或者直接重启网络服务通常就能解决。4.2 双网卡路由冲突与优先级问题服务器上装了双网卡一块接内网一块接外网配置好之后却发现访问内网偶尔慢甚至有时候内网完全不通——这类问题我遇到过好多次。原因几乎都是路由冲突或者默认路由的优先级没有控制好。双网卡场景下最著名的坑是两块网卡都配置了默认网关但系统只会使用其中一条默认路由。ip route输出里默认路由可能同时存在两条default via 192.168.1.1 dev eth0 metric 100 default via 10.0.0.1 dev eth1 metric 200路由选择时会优先选择metric值小的那条也就是eth0走192.168.1.1。如果内网流量想走eth1而eth1没有更精确的路由就只能走eth0这条默认路由数据包出错了口。解决方式有两种要么给内网网段写专门的路由让它走eth1而不依赖默认路由要么调整两条默认路由的metric值。比如我在Rocky Linux上用nmcli配置时会明确把内网网卡的默认路由metric调大把外网网卡的默认路由metric调小sudo nmcli connection modify eth0 ipv4.route-metric 100 sudo nmcli connection modify eth1 ipv4.route-metric 200 sudo nmcli connection up eth0 sudo nmcli connection up eth1如果你用systemd-networkd方法就是在对应的.network文件里加RouteMetric。调整优先级的关键在于想清楚哪块网卡负责“兜底”访问外部流量剩下那块专门走内网专用路由。双网卡还有一种情况是内网访问某台机器的IP恰好和外网某IP网段重叠这类问题靠路由表本身很难优雅解决需要做策略路由基于源地址或端口分流这是下一步进阶内容这里先留个引子。对于绝大多数场景调整metric优先级已经能把问题解决。4.3 进阶话题预告bond、VLAN与桥接如果你负责的服务器网络流量比较大或者对链路冗余有要求那么网卡bond绑定就是一个绕不开的话题。bond把多块物理网卡聚合成一块逻辑网卡对外表现为一个IP对内可以根据负载均衡或主备模式分配流量。常见的bond模式有mode1主备一块工作一块备用热切换和mode4基于LACP的链路聚合需要交换机配合。配置bond在systemd-networkd里需要写一个.netdev文件来定义bond设备再写一个.network文件把物理网卡作为bond的成员看着繁琐思路其实很清楚先创建上层逻辑设备再把物理设备绑定到它下面。VLAN则是另一种划分网络的方案。你在单块物理网卡上通过给报文打802.1Q标签就能在二层隔离出多个虚拟网络。比如交换机配置了VLAN 10和VLAN 20服务器只需要一块物理网卡在上面创建两个VLAN子接口就能分别和这两个VLAN通信。用systemd-networkd创建VLAN接口时需要指定VLAN10这样的ID同样遵循先创接口再绑IP的顺序。桥接bridge在虚拟化和容器场景中用得最多。它把物理网卡和虚拟网卡连在同一个二层交换机上——一块物理网卡比如eth0作为桥的成员虚拟机的虚拟网卡也加入同一个桥这样虚拟机看起来就像直接插在这个物理局域网里一样。配置桥接设备时注意一点物理网卡本身不能配IP地址IP要配在桥接设备上不然数据包又会被本机收走达不到转发效果。顺带提一个跟我最近工作相关的场景有些嵌入式网关设备会把网口转串口服务器serial-over-Ethernet接进来本质上就是那些设备的网络接口只是一个二层入口最后数据都通过TTL串口透传到后面的智能设备。理解这种场景的关键在于分清物理接口和逻辑链路的差别你只要把握住Linux网络配置“物理网卡 → 逻辑设备 → IP绑定”这条主线这类组合玩法上手都不难。提示不管做bond、VLAN还是桥接都建议先在虚拟机或测试环境里练熟了再上生产机。这类配置一旦失败轻则网络断开重则直接失联远程服务器就只剩带外管理口能救所以千万别在生产环境上一上来就手改配置。写在配置之外的几点经验写到这里这期的网络基础实操部分基本就讲完了最后分享几个我在实操中沉淀下来的小习惯。第一改任何网络配置之前先把当前生效的配置完整记录一遍——ip addr、ip route、resolvectl status的输出存到文件里。这不仅能让你改错了快速回滚还能锻炼你阅读系统当前状态的能力。第二同一个时间只通过一个管理服务改配置别混着用nmcli和networkd。我吃过亏后定下的规矩是新服务器先确认网络管理服务是谁再动手改。第三配置完第一时间重启网络服务并验证不要攒着好几处改动一起生效。风险控制上大批量配置前先备份配置文件这是再老练的运维也不敢省的步骤。网络这块坑深但底层逻辑无非那几层网卡、IP、路由、DNS外加一个网络管理服务把它们串起来。你把这些层面之间的关系想清楚基本就能独立排查大多数网络问题了。如果这篇东西能帮你在实际配置时少踩几个坑那就值了。后面我会在下一期里接着聊聊更进阶的内容比如策略路由和组播有兴趣的话欢迎留言聊聊你遇到过的网络问题我来做针对性拆解。