做运维这些年我见过太多人把Linux网络配置停留在“能用就行”的层面改个IP、ping通网关、SSH能登上去就以为完事了。可一旦遇到多网卡流量不对称、DNS解析时好时坏、或者xshell突然连不上服务器就会彻底卡壳。这篇“初始网络下”不打算再讲IP地址、子网掩码、默认网关这些入门常识而是把配置体系、多网卡路由、排错工具链、以及网络服务安全这几块一次讲透。内容适合已经会基本操作的初学者也适合带过一阵服务器、想系统补一补网络认识的中级用户。先说个我自己踩过的例子。有次给一台Ubuntu 22.04配静态IP改完/etc/netplan/下的yamlnetplan apply也执行成功了可外网怎么都ping不通。后来才发现是DNS配置被systemd-resolved缓存吃掉了resolvectl status一看实际生效的DNS跟我写的根本不是同一个。这种问题文档里不会写教程里也经常一笔带过但实际环境里非常常见。所以这篇我打算把这类“只有动手踩过才能明白”的细节都摊开讲。1. 从ifconfig开始但不要止步于ifconfig理解Linux的配置体系1.1 网卡命名变了命令也早就该换了很多老教程还在教ifconfig、route -n、netstat但这些命令在新系统上要么没预装要么输出信息不全。现代Linux发行版普遍使用ip命令它是iproute2工具包的一部分也是内核网络栈的标准管理接口。先明确网卡命名的变化。老系统里网卡叫eth0、eth1新系统为了可预测性改成enp3s0、ens33这种格式。命名规则基于硬件位置和总线信息比如enp3s0表示PCIe总线3号槽位上的板载网卡。不能用旧名字去套新系统否则看ip addr会认出不来。ip命令的核心用法就几个ip addr show # 查看所有网卡和IP地址简写 ip a ip link show # 查看网卡链路状态简写 ip l ip route show # 查看路由表简写 ip r ip addr add 192.168.1.10/24 dev eth0 # 临时添加IP ip link set eth0 up # 临时启用网卡临时命令重启即失效想持久化必须走配置文件。这个区别很多新手混淆——临时加个IP测试可以但保存不了就会在重启后“消失”于是又跑到论坛上问为什么配置不生效。1.2 各发行版配置文件差异别拿A系统的经验套B系统Linux网络配置最大的坑就是发行版之间差异巨大。同样是配静态IP三套系统三种玩法发行版配置文件路径常用管理工具RHEL/CentOS/Rocky 9/etc/NetworkManager/system-connections/nmcliRHEL/CentOS 7/8/etc/sysconfig/network-scripts/ifcfg-*nmcli或直接编辑文件Ubuntu 18.04/etc/netplan/*.yamlnetplan applyDebian/etc/network/interfacessystemctl restart networking有个容易踩的误区很多人以为Ubuntu一定还是/etc/network/interfaces结果在新版本上改了文件、重启网络服务发现完全没生效。原因是Ubuntu从18.04开始用Netplan统一管理网络配置底层的interfaces文件只是一个兼容入口实际控制权在Netplan手里。CentOS这边图形化安装或桌面环境默认会用NetworkManager接管所有网卡。命令行改了ifcfg-*文件后如果不通过nmcli重载NetworkManager可能重新覆盖你的配置。所以RHEL系最稳妥的持久化方式是nmcli connection modify ens33 ipv4.addresses 192.168.1.10/24 ipv4.gateway 192.168.1.1 ipv4.method manual nmcli connection up ens331.3 一份可以直接抄的Netplan配置示例Ubuntu上用Netplan配置静态IP常见写法如下network: version: 2 renderer: networkd ethernets: ens33: dhcp4: false addresses: - 192.168.1.10/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 119.29.29.29 mtu: 1500写完执行sudo netplan apply用ip addr和ip route验证。这里有个细节addresses必须写CIDR格式只写IP不写掩码会直接报错。另一个细节是renderer这一项如果服务器上装了NetworkManager可以改成renderer: NetworkManager否则两个网络管理服务会打架。配置多IP地址也是常见需求比如一块网卡上同时跑内网和管理网addresses: - 192.168.1.10/24 - 10.0.0.10/24这种情况下要注意路由表——系统会自动为直连网段添加路由但默认网关只会走一个另一段要访问不同网段必须另加静态路由否则就是“IP配了但ping不通对面”的经典翻车现场。1.4 DNS配置的“老大难”systemd-resolved的缓存问题DNS问题几乎每个Linux管理员都撞到过。最典型的症状是ping网关通、pingIP通、ping域名不通。现代Ubuntu默认启用systemd-resolved它接管了DNS解析并把/etc/resolv.conf做成了一个软链接指向自己的状态文件。你直接改/etc/resolv.conf写DNS重启后一定被覆盖。正确做法有两个方向第一在Netplan的nameservers里指定DNS然后netplan apply。第二如果不想用Netplan就关掉systemd-resolved手动管理resolv.confsudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved sudo rm /etc/resolv.conf sudo vim /etc/resolv.conf # 写入 nameserver 223.5.5.5 等还有个更隐蔽的问题systemd-resolved有缓存你改了DNS配置后ping仍然解析到旧IP。解决办法是清缓存sudo resolvectl flush-caches排查DNS问题时dig命令比nslookup更好用它能明确告诉你查询走了哪个DNS服务器、耗时多少、返回了什么记录。先看/etc/resolv.conf或resolvectl status确认实际生效的DNS是哪台再用dig 指定DNS 域名对比不同服务器的解析结果差异基本能定位问题出在本地还是上游。2. 多网卡与路由策略让流量按预期方向走2.1 哪些场景需要多网卡不止是“插两根线”多网卡配置常见于虚拟化宿主机、机房服务器、以及做软路由的机器。以Proxmox VE这类虚拟化平台为例一台宿主机通常有一块管理网卡另外几块网卡分别桥接给不同的虚拟机业务。如果不把路由策略配清楚虚拟机流量可能从管理网卡出去造成安全隐患。另一种典型场景是“管理网业务网”分离管理网走内网交换机业务网走公网线路。两块网卡各司其职互不干扰。这里的关键不是把两个IP配上就完事而是要让系统知道哪些流量走哪个网卡。2.2 查看路由表与配置静态路由路由表是Linux网络的核心决策依据。ip route输出里最核心的是default via 网关 dev 网卡这一条它决定所有未匹配更精确路由的流量往哪走。多网卡时最常见的问题是默认路由冲突。比如两块网卡都配置了网关系统会选一条metric值更小的作为默认路由另一条“有网关却用不上”于是从它出去的网络全都不通。解决方案分两种。简单场景直接给网卡配置不同的metricip route add default via 192.168.1.1 dev eth0 metric 100 ip route add default via 10.0.0.1 dev eth1 metric 200metric越大优先级越低所以上述配置表示eth0是主用eth1是备用。但仅靠metric解决不了“让特定网段走特定出口”的需求这时要用策略路由。策略路由的配置思路是给不同网卡打上不同路由表标签用ip rule根据源地址或目标地址选择对应路由表。一个简化的例子# 创建独立路由表10并为它添加默认路由 ip route add default via 10.0.0.1 dev eth1 table 10 # 源地址为10.0.0.10的流量查路由表10 ip rule add from 10.0.0.10 table 10这种配置在生产环境非常实用尤其配合iptables的标记功能可以实现多线负载均衡、业务流量隔离、内网网段按需分流等复杂需求。2.3 网卡绑定Bonding的常见模式与选型多网卡不只是“各干各的”还可以绑成一根逻辑网卡来实现冗余和带宽叠加。Linux内核的bonding驱动支持多种模式生产中常用两种mode1 (active-backup)主备模式同一时间只有一张网卡工作另一张待命。不需要交换机额外配置是最稳妥的冗余方案。mode4 (802.3ad)动态链路聚合需要交换机支持LACP协议并做对应配置。两块网卡同时工作吞吐量叠加但配置复杂度也上去了。配置bonding时要特别注意两块物理网卡上不能配置IPIP必须配置在bond0上。我曾经见过有人先把IP配在eth0上再想绑bond时发现IP冲突排查半天才回过神。KVM虚拟化环境里bond还可以跟bridge叠加使用实现“物理网卡绑定为bond0桥接到br0虚拟机通过br0上网”。这套链路里每一层都有自己独立的故障点逐层ethtool和ping验证才能快速定位问题。2.4 虚拟机网络模型NAT、桥接与OVS的区别说到KVM网络很多人卡在NAT和桥接的概念上。简单类比NAT模式相当于虚拟机躲在宿主机后面蹭网虚拟机通过宿主机转发访问外部网络外部访问不了虚拟机桥接模式相当于虚拟机直接插在局域网交换机上跟宿主机平级拥有独立可被外部访问的IP。NAT的典型配置是default虚拟网络virsh net-list能看到。它适合临时测试但虚拟机对外提供服务时必须做端口映射非常繁琐。桥接则直白很多# 创建名称为br0的桥接设备并把物理网卡ens33加入 sudo ip link add name br0 type bridge sudo ip link set ens33 master br0 sudo ip link set br0 up这样配置后虚拟机虚拟网卡直接挂到br0上跟物理网络中其他机器处于同一二层网络广播、组播、DHCP请求统统直接透传。Open vSwitchOVS是另一种高性能虚拟交换机方案支持VLAN、流表、隧道等高级特性适合大规模虚拟网络编排。实际生产中如果只是几台虚拟机跑测试用Linux bridge就够如果做OpenStack这类平台OVS几乎是标配。3. 连不上按这套顺序排查基本都能解决3.1 xshell连不上的三步定位法跟Linux服务器相关热搜里“xshell连接ubuntu网络配置”出现频率很高。很多人的排查习惯是一通乱试最后发现是防火墙没放行SSH端口。我建议按下面这个顺序固定下来第一看链路层和IP层。在本机ping 服务器的IP能不丢包就说明二层、三层没问题。如果ping不通检查两台机器是否在同一网段、服务器IP是否还在可能DHCP租约变了、网线/网卡是否正常。第二看端口监听。服务器上执行ss -lntp | grep 22如果没有输出说明sshd没有监听检查systemctl status sshd或systemctl status sshUbuntu上服务名是ssh不是sshd。第三看防火墙。Ubuntu默认的ufw如果没放行22端口外部连接会直接被丢掉sudo ufw allow 22/tcpCentOS/Rocky系同理sudo firewall-cmd --permanent --add-servicessh sudo firewall-cmd --reload这个过程看似简单但很多人会卡在第二步明明systemctl status ssh显示active但ss就是看不到22端口。这种情况多半是sshd配置改了端口去/etc/ssh/sshd_config里看Port选项改回22或者记住你改成几号了。3.2 DNS解析失败的完整排查链路DNS问题很容易被误判为“网络不通”。有个老梗“ping通IPping不通域名99%是DNS1%是域名被封”虽然现在情形复杂一点但排查思路依然有效。第一步确认系统解析用的是哪台服务器cat /etc/resolv.conf # 或者 resolvectl status第二步用dig直接查询。比如用公共DNS解析一个域名dig 223.5.5.5 www.example.com如果指定DNS返回正常但系统默认解析不行问题就在本机DNS配置或缓存。第三步检查是不是被/etc/hosts里的旧记录影响——hosts文件优先级别最高里面有残留的旧IP会直接劫持你对某个域名的解析。第四步排查systemd-resolved的缓存清缓存命令上文提过就不重复了。还有一个值得注意的坑公司内网域名在办公网络正常解析拿到家里就连不上这不是Linux的问题而是你的DNS服务器根本不在同一个网络里。用dig 内网DNS服务器 内网域名一试便知。3.3 tcpdump抓包确认问题究竟出在哪一端有时候“连不上”很诡异同一网段的A机器能连服务器B机器就是连不上。这种时候最有效的办法是抓包看实际过程。在服务器上执行sudo tcpdump -i ens33 port 22 -n在B机器上用xshell发起连接观察抓包结果。正常的TCP三次握手应该出现这样的交换SYN - SYN-ACK - ACK。如果只看到客户端的SYN包服务器没有任何回复说明服务器的防火墙或应用层根本没响应。如果看到SYN、然后服务器回了RST重置说明端口被拒绝多半是防火墙规则在起作用。抓包是排查网络问题的“终极武器”它不依赖任何上层工具的反馈直接看每个数据包的来龙去脉。我还习惯顺手存一份.pcap文件用Wireshark事后慢慢回放比在终端里看滚动输出轻松得多sudo tcpdump -i ens33 port 22 -n -w /tmp/ssh-issue.pcap3.4 网络测速与延迟别只会看speedtest网页热搜词里“网络测速”“网络测速在线测网速”高频出现。在Linux服务器上测速网页工具往往不可用命令行工具才是正道。想测局域网内两台机器之间的带宽用iperf3最准# 服务端接收流量 iperf3 -s # 客户端发送流量 iperf3 -c 192.168.1.100 -t 30TCP模式下结果能反映真实吞吐。此时想压榨极限可以加-P 8开8个并发流。如果怀疑网卡协商速率不对先看ethtool ens33输出的Speed字段千兆网卡协商成了100Mb/s那测出来的数字当然只有十分之一。测外网带宽可以用speedtest-cli但它的结果受本地网络和服务器线路影响只能参考。更实用的日常监控是ping -s 1400测大包延迟和丢包率再配合mtr看每一跳的路由质量和丢包位置。我自己排查“游戏服务器卡”时常拿mtr跑到目标IP哪一跳开始丢包、哪一跳延迟飙高一眼就能判断问题在运营商段还是机房段。4. 网络通了之后服务安全基线同样重要4.1 用ss摸清服务器到底开了哪些端口网络配通只是开始紧接着要面对的是“这台机器暴露在网络上安不安全”的问题。第一步永远是搞清服务器上监听哪些端口ss -lntup这个命令列出所有TCP和UDP监听端口以及对应的进程。我建议每台新服务器上线前都执行一遍对着清单核对每个端口是不是必须的。多出来的监听端口找到对应服务全部关掉或卸载。有个真实案例用户装了个图形桌面桌面环境和辅助服务监听了大量端口结果服务器被扫描到弱口令一夜之间成了矿机。用ss排查后才发现单纯一个多余的服务往往就是安全破口。最小化开放是最朴素也最有效的安全策略。4.2 防火墙白名单式开放才是正确姿势热搜里有“常用的网络安全模型有哪些”这个问题其中一个经典模型叫“默认拒绝”。落实到防火墙策略上就是只放行明确需要的流量其余一律拦截。ufwUbuntu和firewalldCentOS/Rocky都支持这种策略# ufw 示例 sudo ufw default deny incoming sudo ufw allow ssh sudo ufw allow 80/tcp sudo ufw enable # firewalld 示例 sudo firewall-cmd --set-default-zonedrop sudo firewall-cmd --permanent --add-servicessh sudo firewall-cmd --permanent --add-port443/tcp sudo firewall-cmd --reload很多新手喜欢直接把防火墙关掉“方便调试”我强烈不推荐。正确姿势是临时加一条放行规则问题解决后立刻删掉。关掉防火墙的服务器在互联网上活不过一天这不是夸张——扫描器每时每刻都在全网段测试22端口弱口令。4.3 文件共享服务的安全陷阱如果服务器上开了NFS、Samba、FTP这类文件共享服务安全风险更大。NFS本身的历史设计缺陷不少对外网开放NFS基本等于裸奔Samba的配置权限写错一个选项整个目录就能被匿名访问FTP更是明文传输账号密码在链路上裸奔。针对共享文件这个需求我的建议是能用SFTP就不用FTP能用WebDAVHTTPS就不用Samba能只在内网监听就不要把端口暴露到公网。/etc/exports里NFS的网段限制一定要写具体/data 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)不要把IP段写成*或者0.0.0.0/0这是最基本的底线。4.4 网络协议的理解决定你排查问题的速度热搜词里有“网络通信协议”“网络协议分析”。说实话懂TCP三次握手、四次挥手、路由协议这些底层机制跟只会敲命令的人在排障效率上是天壤之别。比如抓包时看到大量TCP Retransmission不理解这是重传机制在起作用就不知道去查丢包看到TCP Zero Window不明白这是接收方缓冲区满了就会以为网络拥塞。我建议做运维和Linux相关工作的朋友不必把OSI七层模型倒背如流但TCP/IP四层模型、TCP状态流转、DNS解析过程、ARP工作方式这四样必须弄明白。命令可以现查模型必须内化。磨刀不误砍柴工这比背一百条命令都有用。5. 实操中容易踩的细节坑汇总给你5.1 解压文件名乱码和网络也有关系热搜里有“linux 解压文件乱码”这个词平时大家觉得是编码问题但我在实际工作中遇到过因为网络传输方式不对导致的乱码。比如Windows之间用FTP传的zip包中文文件名是GBK编码拿到Linux上解压就是乱码。处理方式是# 安装convmv后转换文件名编码 convmv -f GBK -t UTF-8 --notest ./*或者用7z解压时指定编码7z x 文件.zip -o 目标目录 -scsGBK这个问题的根源在于协议传输过程中的编码声明不一致理解这一点后举一反三——从Windows下载的txt文件、CSV表格拿到Linux上打开乱码原理都一样。5.2 流量监控工具快速定位“谁在跑满带宽”有几台服务器每天固定时段网络飙升CPU却不高单看监控图根本找不到原因。这时候上iftop和nload立刻能看清实时流量来源sudo nload sudo iftop -i ens33 -n -Niftop界面会按连接显示实时速率一眼看出是哪个IP、哪个端口在耗流量。看到某个外网IP一直在拉数据配合ss -tnp找到对应PID再顺藤摸瓜定位进程基本就真相大白了。还有个被低估的工具是vnstat它默默按月、按天记录网卡流量查历史趋势非常方便。服务器被人拖了流量翻vnstat历史记录攻击开始的时间点一目了然。5.3 改配置“看似成功其实失败”的经典场景“配置改了、服务重启了、但就是不生效”是运维日常最耗时的坑。总结一下常见的几类原因一是NetworkManager跟networkd之争动态管理工具覆盖了手工配置二是Netplan yaml语法检查不彻底虽然netplan apply没报错但配置内容不符合预期比如两个地址配在同一网段却指望同时生效三是改了sysctl内核参数没执行sysctl -p重载比如TCP缓冲区调优后重启网络服务参数被重置。我个人习惯是每次修改配置前先备份原文件修改后用diff输出变更cp /etc/netplan/01-network-manager-all.yaml{,.bak} diff /etc/netplan/01-network-manager-all.yaml /etc/netplan/01-network-manager-all.yaml.bak改完配置后不要立刻重启先netplan generate做语法检查再netplan apply应用降低“手一抖配错整台机器失联”的概率。5.4 保存你的网络拓扑和配置快照最后一条是工作习惯层面的建议花十分钟把当前网络的拓扑、IP分配、VLAN划分、防火墙规则画成一张图存在团队仓库里。配置变更时同步更新图排障的时候对着图看效率翻倍。我自己是在/opt/network-docs/下面建了个目录把每个网卡的配置、bond模式、路由规则、防火墙策略写成Markdown配上拓扑图一起提交到git。遇到需要回滚的变更直接看git历史找回退版本比靠记忆猜靠谱太多。用git管网络配置的好处是团队的每个人都能看到变更记录“谁在什么时候改了什么”在排障时能省掉大量用来猜的时间。Linux网络的知识点分散命令多、发行版差异大但底层逻辑始终是配置、路由、解析、安全这四件事。把这四件事串起来理解再遇到“配置不生效”“连不上服务器”“网络慢”这三大类问题基本都能从容应对。
