计算机网络基础

第一章：计算机网络基础（运维核心）

运维工程师日常核心工作离不开网络相关操作，高频场景包括：处理各类网络故障（如网络延迟、丢包、端口不通、DNS解析失败）、部署基础网络服务（如DNS、DHCP、防火墙）、优化网络性能、保障网络安全。核心要求是熟练掌握网络分层模型、核心协议、网络设备特性及故障排查方法，确保服务器之间、服务器与用户之间的网络通畅、稳定、安全，从根源减少业务中断风险。

1.1 网络分层模型（OSI七层模型与TCP/IP四层模型）

网络分层的核心逻辑是“分而治之”，将复杂的网络通信流程拆解为多个独立、可管理的层次，每个层次负责特定的功能模块，层与层之间通过标准化接口通信。对运维而言，分层模型是排查网络故障的“导航图”——排查故障时需严格遵循“从下到上”（物理层→应用层）或“从上到下”的顺序，精准定位故障所在层级，避免盲目排查、浪费时间。

1.1.1 OSI七层模型（理论核心，运维定位故障的框架）

OSI（开放式系统互联）七层模型是网络通信的理论基础，从下到上分为7个层次，每层均有明确的功能、核心协议、核心设备及典型故障点，是运维排查网络问题的核心依据，必须熟练掌握各层的核心要点：

物理层（第1层）：网络通信的最底层，负责实现物理介质的连接，传输二进制原始数据（电信号、光信号、无线电信号），不涉及数据的封装和解析。核心设备：网线（五类线、六类线、光纤）、网卡、交换机端口、光纤模块、集线器（已逐步淘汰）；常见故障：网线断裂、网线松动、网卡硬件故障、交换机端口损坏、光纤模块接触不良、端口速率协商失败；故障表现：服务器无法联网、ping不通任何设备、网卡指示灯不亮（正常应亮绿灯，闪烁表示有数据传输）。
数据链路层（第2层）：承接物理层的二进制数据，将其封装为“帧”（添加帧头、帧尾，包含MAC地址），核心作用是识别设备的MAC地址（物理地址，全球唯一），实现相邻设备之间的直接通信（如服务器与交换机、交换机与交换机之间）。核心协议：以太网协议（局域网核心）、ARP协议（地址解析协议，将IP地址转换为MAC地址）、RARP协议（反向地址解析，较少用）；核心设备：交换机（二层交换机，核心设备）、网桥；常见故障：MAC地址冲突、ARP欺骗（导致网络中断、流量劫持、数据泄露）、帧丢失（导致丢包）、VLAN配置错误（跨VLAN无法通信）；故障表现：内网部分设备无法通信、网络时断时续、访问内网设备卡顿。
网络层（第3层）：核心作用是“寻址”和“路由选择”，将数据链路层的“帧”解封，封装为“数据包”（添加IP地址），实现跨网段通信（如内网设备访问外网、不同子网的内网设备通信），负责将数据包从源主机准确传输到目标主机。核心协议：IP协议（网络层核心，负责IP寻址）、ICMP协议（互联网控制消息协议，用于连通性测试和错误反馈）、ARP协议（跨网段通信时的地址解析）、路由协议（RIP、OSPF，用于路由器之间的路由信息交换）；核心设备：路由器（三层设备，核心设备）、三层交换机；常见故障：IP地址冲突、IP地址配置错误（如子网掩码错误）、路由配置错误（路由表缺失、路由环路）、网络延迟过高、丢包严重；故障表现：跨网段ping不通、能ping通内网但无法访问外网、访问跨网段设备延迟极高。
传输层（第4层）：负责端到端的通信（源主机应用程序到目标主机应用程序），核心是保障数据的可靠传输或快速传输，区分不同应用程序（通过端口号）。核心协议：TCP协议（传输控制协议，可靠传输）、UDP协议（用户数据报协议，快速传输）；核心概念：端口号（0-65535，其中0-1023为知名端口，如22、80、443，1024-49151为注册端口，49152-65535为临时端口）；常见故障：端口占用、连接超时、TCP三次握手失败、TCP连接泄露、UDP丢包；故障表现：应用程序无法启动（提示端口被占用）、无法连接目标服务（如SSH登录失败、数据库连接超时）、实时业务（如视频、语音）卡顿。
会话层（第5层）：负责建立、维护和终止应用程序之间的会话连接，管理会话的发起、保持和结束，相当于“应用程序之间的通信桥梁”。核心功能：会话建立（如用户登录系统）、会话维护（如保持SSH连接）、会话终止（如用户退出系统）；常见故障：会话异常中断（如SSH连接频繁断开、FTP文件传输中断、远程桌面连接掉线）；故障原因：网络不稳定、会话超时设置过短、服务器资源不足。
表示层（第6层）：负责数据的编码、解码、加密、解密、压缩、解压缩，确保不同系统、不同应用程序之间的数据格式兼容。核心功能：数据格式转换（如JSON与XML转换）、加密解密（如SSL/TLS加密）、压缩解压缩（如GZIP压缩）；常见故障：数据编码不兼容（如不同系统之间的文件无法识别、接口调用失败）、加密解密失败（如HTTPS证书失效、证书不匹配）、压缩格式不支持；故障表现：无法打开跨系统传输的文件、HTTPS网页无法访问（提示证书错误）、接口返回乱码。
应用层（第7层）：直接为应用程序提供网络服务，是用户可见的层次，将网络功能与应用程序结合，实现具体的业务场景（如网页访问、文件传输、邮件发送）。核心协议：HTTP（超文本传输协议，网页访问）、HTTPS（加密版HTTP）、FTP（文件传输协议）、DNS（域名解析协议）、SSH（远程登录协议）、SMTP（邮件发送协议）、POP3/IMAP（邮件接收协议）；常见故障：服务端口未开启、应用协议不兼容、服务异常（如DNS服务器宕机、SSH服务未启动）、服务配置错误；故障表现：无法访问网页、无法远程登录服务器、无法发送邮件、域名无法解析。

1.1.2 TCP/IP四层模型（实操核心，简化版）

OSI七层模型过于理论化，实际运维工作中，常用TCP/IP四层模型（简化合并层次），更贴合实操场景，其与OSI七层模型的对应关系、核心功能及运维关注点如下表所示，需重点记忆对应关系和运维排查重点：

TCP/IP四层	对应OSI层次	核心功能	核心协议/设备	运维核心关注点
网络接口层	物理层 + 数据链路层	物理介质连接、帧传输、MAC地址寻址、相邻设备通信	以太网协议、ARP协议；交换机、网卡、网线	排查网线、网卡、交换机故障；检查MAC地址冲突、ARP欺骗
网络层	网络层	IP寻址、路由选择、跨网段数据包传输	IP协议、ICMP协议；路由器、三层交换机	排查IP冲突、路由配置错误、延迟丢包；测试网关连通性
传输层	传输层	端到端通信、端口区分、数据可靠/快速传输	TCP协议、UDP协议；服务器端口	排查端口占用、连接异常、TCP握手/挥手故障
应用层	会话层 + 表示层 + 应用层	为应用程序提供具体网络服务，实现业务场景	HTTP、HTTPS、DNS、SSH等；各类网络服务	排查服务异常、协议兼容、证书问题、DNS解析故障

运维排查核心技巧：网络故障排查优先遵循“从下到上”原则，先检查物理层（网线、网卡、交换机），再检查网络层（IP、网关、路由），最后检查传输层（端口、连接）和应用层（服务、协议），避免跳过底层故障，盲目排查上层问题（如网线断了，却反复检查DNS配置）。

1.2 核心网络协议（运维高频，必掌握）

运维日常工作中，接触最多、最核心的网络协议为TCP、UDP、IP、ICMP、DNS，需熟练掌握每类协议的核心功能、常用端口、典型故障及排查方法；其余协议（如FTP、SMTP、OSPF）仅需了解基础作用，无需深入钻研底层原理，重点关注实操场景。

1.2.1 IP协议（网络层核心，寻址基石）

IP协议（互联网协议）是网络层的核心协议，核心作用是“寻址”——为互联网中的每台设备分配唯一的IP地址，确保数据包能准确从源主机传输到目标主机，是跨网段通信的基础。目前主流使用IPv4协议，IPv6协议逐步普及（解决IPv4地址枯竭问题）。

IPv4地址：由32位二进制数组成，格式为x.x.x.x（点分十进制），每个x的取值范围为0-255（如192.168.1.1）。IPv4地址分为公有IP和私有IP，运维场景中以私有IP使用最多：
- 公有IP：互联网中唯一，需向运营商（电信、联通、移动）申请，用于外网设备访问（如服务器对外提供服务的IP）；
- 私有IP：仅用于内网（局域网），无法直接访问互联网，无需申请，常用网段（运维必记）：
  - 192.168.0.0/16（最常用，如公司内网、家庭网络，可细分多个子网，如192.168.1.0/24、192.168.2.0/24）；
  - 10.0.0.0/8（大型内网常用，如企业总部内网）；
  - 172.16.0.0/12（中型内网常用）。
IPv6地址：由128位二进制数组成，格式为xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx（冒分十六进制），如2001:0db8:85a3:0000:0000:8a2e:0370:7334（可简化书写，省略前导0和连续的0段，如2001:db8:85a3::8a2e:370:7334）。IPv6地址数量极多，可满足所有设备联网需求，现代服务器（如CentOS 8、Ubuntu 20.04+）已默认支持IPv6，运维需了解其基础格式和配置方法。
常见故障及表现：
- IP地址冲突：两台设备使用同一IP地址，表现为“网络时断时续、无法访问互联网、系统提示‘IP地址已被占用’”；
- IP地址配置错误：如IP地址与子网掩码不匹配、网关填写错误，表现为“能ping通内网部分设备，无法ping通网关，无法访问外网”；
- IP地址耗尽：内网未部署DHCP服务器，手动配置IP导致地址重复，或内网设备过多，可用IP不足，表现为“新增设备无法分配IP，无法联网”。

Linux实操命令（必背，高频使用）：

# 查看所有网卡的IP配置、MAC地址、网卡状态（最常用，推荐）
ip addr show
# 查看指定网卡的IP配置（如eth0，根据实际网卡名称修改）
ip addr show eth0

# 查看路由表（排查网关、路由配置是否正确）
ip route show
# 查看默认网关（快速确认网关配置）
ip route show default

# 临时配置IP地址（重启服务器或重启网络服务后失效，用于临时测试）
ip addr add 192.168.1.100/24 dev eth0
# 临时删除IP地址
ip addr del 192.168.1.100/24 dev eth0

# 临时设置默认网关（重启失效）
ip route add default via 192.168.1.254 dev eth0
# 临时删除默认网关
ip route del default via 192.168.1.254

1.2.2 ICMP协议（网络层辅助协议，连通性测试核心）

ICMP协议（互联网控制消息协议）是网络层的辅助协议，不负责数据传输，核心作用是“网络连通性测试”和“错误反馈”——向目标设备发送回声请求（ping请求），接收目标设备的回声响应（ping响应），判断目标设备是否可达；同时，当网络出现错误（如目标不可达、超时、路由错误）时，返回错误信息，帮助运维定位故障。

运维最常用的ping命令，就是基于ICMP协议实现的，是排查网络连通性的第一步。

核心功能：
- 连通性测试：通过发送ping请求，判断目标设备（IP/域名）是否可达；
- 错误反馈：当数据包无法到达目标设备时，返回错误类型（如目标不可达、请求超时、路由不可达）；
- 延迟和丢包测试：通过ping命令的输出，查看网络延迟和丢包率，判断网络稳定性。
运维实操（必练）：
- 基础用法：ping 目标IP/域名（如ping 192.168.1.254、ping baidu.com），默认持续发送请求，按Ctrl+C停止；
- 常用参数（高频）：
  - -c 次数：指定发送ping请求的次数（如ping -c 4 192.168.1.1，发送4个请求后自动停止）；
  - -i 间隔：指定两次ping请求的间隔时间（单位：秒，如ping -i 0.5 192.168.1.1，每0.5秒发送一次请求）；
  - -s 大小：指定ping数据包的大小（单位：字节，如ping -s 1024 192.168.1.1，发送1024字节的数据包）；
  - -W 超时：指定等待响应的超时时间（单位：秒，如ping -W 2 192.168.1.1，超过2秒未响应则视为超时）。
- 常见故障及排查：
  - ping不通目标设备：可能是目标设备未开机、网络中断、防火墙拦截ICMP请求、目标设备IP配置错误；
  - ping丢包严重：可能是网络拥堵、网线质量差、路由故障、目标设备负载过高；
  - ping延迟过高：可能是跨网段距离过远、路由转发效率低、外网链路故障。

注意：部分服务器或防火墙会默认拦截ICMP请求（禁止ping），此时ping会提示“请求超时”，但不代表目标设备不可达，需通过其他方式（如telnet、nc命令）测试端口连通性。

1.2.3 TCP协议（传输层，可靠传输核心）

TCP协议（传输控制协议）是传输层的核心协议，核心特点是“可靠传输”——通过一系列机制（三次握手、四次挥手、重传机制、流量控制、拥塞控制），确保数据从源主机准确、完整地传输到目标主机，不丢失、不重复、不乱序。

TCP协议适用于对数据完整性要求高的场景，如HTTP/HTTPS网页访问、SSH远程登录、数据库连接（MySQL、Redis）、文件传输（FTP）等，是运维工作中最常接触的协议之一。

核心特性（运维必记）：面向连接、可靠传输、流量控制（避免发送方发送过快，接收方无法处理）、拥塞控制（避免网络拥堵）、面向字节流。
核心流程（三次握手、四次挥手）：
- 三次握手（建立连接，确保双方通信能力正常）：故障点：三次握手失败，常见原因是服务器端口未开启、防火墙拦截TCP请求、服务器负载过高，表现为“连接超时”“无法建立连接”。
  - 客户端 → 服务器：发送SYN（同步）报文，请求建立连接；
  - 服务器 → 客户端：发送SYN+ACK（同步+确认）报文，确认收到请求，并请求建立连接；
  - 客户端 → 服务器：发送ACK（确认）报文，确认收到服务器的请求，连接建立完成。
- 四次挥手（关闭连接，确保数据传输完成）：故障点：四次挥手异常，常见原因是服务器进程异常退出、网络中断，导致连接无法正常关闭，形成“TIME_WAIT”或“CLOSE_WAIT”状态，占用端口资源，最终导致服务器端口耗尽，服务无法启动。
  - 客户端 → 服务器：发送FIN（终止）报文，请求关闭连接；
  - 服务器 → 客户端：发送ACK（确认）报文，确认收到关闭请求（此时服务器仍可能在发送剩余数据）；
  - 服务器 → 客户端：发送FIN（终止）报文，告知客户端数据已发送完成，请求关闭连接；
  - 客户端 → 服务器：发送ACK（确认）报文，确认收到关闭请求，连接关闭。
常见故障及表现：
- 连接超时：三次握手失败，表现为“无法连接目标服务”“SSH登录超时”；
- 端口占用：某端口被其他进程占用，导致对应服务无法启动（如MySQL服务默认端口3306被占用，启动失败）；
- 连接泄露：四次挥手异常，导致大量连接处于TIME_WAIT/CLOSE_WAIT状态，占用端口和内存资源，表现为“服务器卡顿、服务无法响应”；
- 数据传输异常：重传机制失效，导致数据丢失、乱序，表现为“文件传输中断、网页加载不全”。
常用端口（运维必记，对应服务）：
- SSH（远程登录）：22端口（最常用，必须掌握）；
- HTTP（网页服务）：80端口；
- HTTPS（加密网页服务）：443端口；
- MySQL（数据库）：3306端口；
- Redis（缓存）：6379端口；
- FTP（文件传输）：21端口（控制端口）、20端口（数据端口）。

Linux实操命令（必背，高频使用）：

# 查看所有TCP连接状态（排查连接异常、连接泄露，最常用）
netstat -an | grep TCP
# 简化查看，仅显示TCP连接（推荐，更高效）
ss -tuln  # 查看所有监听的TCP/UDP端口
ss -an | grep TCP  # 查看所有TCP连接

# 查看指定端口的TCP连接状态（如22端口，SSH）
ss -an | grep :22

# 查看端口占用情况（定位占用端口的进程，核心命令）
lsof -i:22  # 查看22端口的占用进程（进程ID、进程名称）
# 若lsof命令未安装，可先安装：yum install lsof -y（CentOS）、apt install lsof -y（Ubuntu）

# 终止占用端口的进程（需谨慎，避免终止核心进程）
kill -9 进程ID  # 强制终止进程，进程ID通过lsof -i:端口号获取

# 查看TCP连接状态统计（排查连接泄露）
netstat -an | grep TCP | awk '{print $6}' | sort | uniq -c

1.2.4 UDP协议（传输层，快速传输核心）

UDP协议（用户数据报协议）是传输层的另一种核心协议，与TCP协议相反，核心特点是“快速传输”——无连接、不可靠、不保证数据完整性，无需进行三次握手和四次挥手，直接发送数据，减少协议开销，提升传输速度。

UDP协议适用于对实时性要求高、对数据完整性要求不高的场景，如DNS解析、视频流、语音通话、实时游戏等。

核心特性（运维必记）：无连接、不可靠、速度快、面向数据报、无流量控制和拥塞控制。
常见故障及表现：
- UDP丢包：由于无重传机制，网络拥堵、延迟过高时易出现丢包，表现为“视频卡顿、语音失真、实时游戏延迟”；
- 端口占用：UDP端口被其他进程占用，导致对应服务无法启动（如DNS服务默认端口53被占用，解析失败）；
- 数据乱序：无顺序控制机制，可能出现数据接收顺序与发送顺序不一致，表现为“语音错乱、视频画面卡顿”。
常用端口（运维必记，对应服务）：
- DNS（域名解析）：53端口（UDP为主，TCP为辅）；
- DHCP（IP自动分配）：67端口（服务器端）、68端口（客户端）；
- SNMP（网络设备监控）：161端口；
- 视频流/语音通话：随机临时端口（1024以上）。

运维区分：TCP协议侧重“可靠”，UDP协议侧重“快速”；排查网页、数据库、SSH等服务故障，重点关注TCP协议；排查DNS、视频、语音等服务故障，重点关注UDP协议。

1.2.5 DNS协议（应用层核心协议，域名解析基石）

DNS协议（域名系统协议）是应用层的核心协议，核心作用是“域名解析”——将用户易记的域名（如baidu.com、www.qq.com）转换为计算机可识别的IP地址（如180.101.49.12），是用户访问互联网、服务器访问外部服务的基础，也是运维高频排查点（域名解析失败是最常见的应用层故障之一）。

核心功能：
- 正向解析（最常用）：域名 → IP地址（如baidu.com → 180.101.49.12）；
- 反向解析（多用于日志排查、安全审计）：IP地址 → 域名（如180.101.49.12 → baidu.com）；
- 域名层级解析：DNS采用层级结构（根域名服务器→顶级域名服务器→权威域名服务器），确保解析的准确性和高效性。
常见故障及表现：
- DNS解析失败：表现为“能ping通IP地址，无法访问域名”“浏览器提示‘无法解析域名’”；
- DNS劫持：恶意篡改DNS解析结果，导致访问域名时跳转到错误IP（如访问baidu.com跳转到恶意网站）；
- DNS延迟过高：解析域名耗时过长，表现为“网页加载慢、首次访问域名卡顿”；
- DNS服务器宕机：无法提供解析服务，表现为“所有域名无法解析，仅能通过IP访问”。
运维实操（必练）：
- 查看DNS配置：Linux系统中，DNS配置文件为/etc/resolv.conf，里面的nameserver字段就是DNS服务器IP； cat /etc/resolv.conf # 查看当前DNS配置
- 测试DNS解析（排查解析故障）： # 用nslookup测试解析（简单直观，显示解析的IP地址） ``nslookup baidu.com ``# 用dig测试解析（更详细，显示解析过程、DNS服务器、解析时间） ``dig baidu.com
- 故障解决（高频操作）：
  - 更换DNS服务器：使用公共DNS服务器（稳定、可靠），如阿里云DNS：223.5.5.5、223.6.6.6；谷歌DNS：8.8.8.8、8.8.4.4；114DNS：114.114.114.114；
  - 清除DNS缓存：Linux系统（Systemd）执行systemd-resolve --flush-caches，Windows系统执行ipconfig /flushdns；
  - 手动配置DNS：修改/etc/resolv.conf文件，添加nameserver字段（临时生效），或修改网卡配置文件（永久生效）。

1.3 网络设备（运维实操重点，无需深入硬件）

运维工作中，接触最多的网络设备是交换机、路由器、防火墙，核心要求是掌握每类设备的核心功能、运维关注点及常见故障排查方法，无需深入了解硬件原理和内部构造，重点聚焦“如何排查设备相关的网络故障”。

1.3.1 交换机（二层设备，内网核心）

交换机是局域网（内网）的核心设备，属于二层设备（工作在数据链路层），核心功能是“连接内网设备”（服务器、办公PC、打印机等），基于MAC地址转发二层帧，实现内网设备之间的通信，相当于“内网数据中转站”——将一台设备发送的数据，精准转发到目标设备，不转发到无关设备，提升内网通信效率。

运维关注点（高频）：
- 端口状态：查看交换机端口是否处于“Up”状态（正常）、“Down”状态（故障），或“Err-disabled”状态（错误禁用）；Down状态需优先检查网线、端口是否损坏；
- 端口速率：交换机端口速率（100M/1000M/10G）需与服务器网卡速率匹配，否则会导致速率协商失败，限制内网网速（如服务器网卡支持1000M，交换机端口仅支持100M，内网网速会被限制在100M）；
- VLAN配置：若内网划分VLAN（虚拟局域网），需确认交换机VLAN配置正确，避免跨VLAN无法通信；
- 端口流量：查看交换机端口的进出流量，排查是否有端口流量过高（如被攻击、大文件传输），导致内网拥堵。
常见故障及排查方法：
- 端口Down：重新插拔网线，更换网线测试；更换交换机端口，排查端口是否损坏；检查服务器网卡状态（是否Up）；
- 内网网速慢：检查交换机端口速率协商是否正常（优先协商为1000M）；排查是否有端口流量过高，导致拥堵；重启交换机（临时解决）；
- 广播风暴：内网大量广播包导致网络卡顿、设备无法通信，排查方法：查看交换机端口广播包数量，定位产生广播风暴的设备（如故障PC、摄像头），断开该设备后测试；
- 跨VLAN无法通信：检查交换机VLAN配置（如VLAN ID、 trunk端口配置），确认跨VLAN路由是否正常。

注意：运维无需登录交换机配置（除非有网络管理员权限），遇到交换机相关故障，优先排查网线、网卡，若无法解决，联系网络管理员排查交换机配置和硬件。

1.3.2 路由器（三层设备，跨网段核心）

路由器是跨网段通信的核心设备，属于三层设备（工作在网络层），核心功能是“连接不同网段”（如内网与外网、内网不同子网），基于IP地址进行路由选择，将数据包从一个网段转发到另一个网段，实现跨网段通信（如内网设备访问外网、不同子网的服务器通信）。

路由器的内网IP地址，就是内网所有设备的“网关”——内网设备要访问外网，必须通过网关（路由器）转发数据包。

运维关注点（高频）：
- 网关配置：路由器的内网IP就是内网设备的网关（如192.168.1.254），网关配置错误，会导致内网设备无法访问外网；
- 路由配置：路由器需正确配置路由表，确保数据包能跨网段传输（如内网到外网的路由、不同子网之间的路由），路由配置错误会导致跨网段ping不通；
- 外网端口状态：查看路由器外网端口（连接运营商线路）的状态，是否正常连接，若Down状态，会导致整个内网无法访问外网；
- 负载情况：查看路由器CPU、内存负载，负载过高会导致路由转发效率低，网络延迟过高。
常见故障及排查方法：
- 内网无法访问外网：检查路由器外网端口是否正常（Up状态）；检查路由器路由配置（是否有默认路由指向外网）；检查网关配置（内网设备网关是否为路由器内网IP）；重启路由器（临时解决）；联系运营商排查外网线路故障；
- 跨网段无法通信：检查路由器路由表，确认是否有对应网段的路由；检查路由器子网掩码配置，确认不同子网是否能正常转发；
- 路由器死机：表现为整个内网无法联网、ping不通网关，排查方法：重启路由器，检查路由器电源、散热情况（避免过热死机）；
- 网络延迟过高：检查路由器负载，排查是否有大量流量占用；检查路由转发路径，是否有冗余路由导致转发延迟。

1.3.3 防火墙（安全设备，防护核心）

防火墙是网络安全的核心设备，核心功能是“过滤网络流量”——根据预设的规则，允许或禁止特定IP、端口、协议的网络流量，保护内网设备和服务器安全，防止恶意攻击（如端口扫描、暴力破解、流量攻击），是运维工作中不可或缺的安全设备（分为硬件防火墙和软件防火墙，如Linux系统的firewalld、iptables）。

运维关注点（高频）：
- 规则配置：防火墙规则需遵循“最小开放原则”，只开放业务必需的端口、IP和协议，禁止不必要的流量（如禁止外部IP访问服务器的22端口，仅允许内网IP访问）；
- 规则生效状态：确认防火墙规则是否正确生效，避免配置规则后未重启防火墙，导致规则无效；
- 日志排查：查看防火墙日志，定位被拦截的流量（如哪些IP被禁止、哪些端口被拦截），区分是正常拦截还是误拦截；
- 运行状态：确认防火墙是否正常运行，若防火墙宕机，会导致内网失去防护，或正常流量无法通过。
常见故障及排查方法：
- 防火墙拦截正常流量：表现为“内网能访问服务器，外网无法访问”“ping不通目标设备”“服务端口无法访问”；排查方法：查看防火墙规则，确认是否禁止了对应IP、端口或协议；临时关闭防火墙测试（确认是否为防火墙拦截）；
- 防火墙规则无效：配置规则后，流量未被拦截或允许，排查方法：检查规则配置是否正确（如端口号、IP地址、协议是否错误）；重启防火墙，使规则生效；
- 防火墙宕机：表现为“无法访问防火墙管理界面”“所有流量无限制通过”，排查方法：重启防火墙硬件/软件，检查防火墙电源、网络连接；
- 恶意流量拦截：防火墙频繁拦截某IP的流量，排查该IP是否为恶意IP（如暴力破解、端口扫描），可将其加入黑名单，禁止访问。

重要提醒：生产环境中，禁止随意关闭防火墙（即使是排查故障），临时关闭后需立即开启，避免服务器暴露在公网，遭受恶意攻击；若需开放端口，需严格控制开放范围（如仅开放给指定IP），避免大范围开放端口带来安全风险。

Linux软件防火墙实操命令（必背）：

# 查看firewalld防火墙运行状态
systemctl status firewalld
# 启动firewalld防火墙
systemctl start firewalld
# 停止firewalld防火墙（生产环境慎用）
systemctl stop firewalld
# 设置firewalld开机自启
systemctl enable firewalld

# 查看已开放的端口（常用）
firewall-cmd --list-ports
# 开放端口（永久生效，需重启防火墙）
firewall-cmd --add-port=80/tcp --permanent  # 开放80端口（TCP）
# 关闭端口（永久生效，需重启防火墙）
firewall-cmd --remove-port=80/tcp --permanent
# 重启防火墙，使规则生效
firewall-cmd --reload

# 查看防火墙规则（详细）
firewall-cmd --list-all
# 开放指定IP访问某端口（如允许192.168.1.0/24网段访问22端口）
firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port protocol="tcp" port="22" accept' --permanent

1.4 网络故障排查实操（运维高频，必练）

网络故障排查的核心思路的是：定位故障范围 → 按分层排查 → 验证故障解决，避免盲目操作。以下是运维工作中最常见的4类网络故障，结合前文知识点和实操命令，详细梳理排查步骤，可直接套用，提升排查效率。

1.4.1 故障1：服务器无法访问外网（能ping通内网，无法ping通外网）

故障现象：服务器能ping通内网其他设备（如192.168.1.10）和内网网关（如192.168.1.254），但ping外网域名（如baidu.com）提示“未知域名”，ping外网IP（如180.101.49.12）提示“请求超时”，无法访问外网服务。

排查步骤（从下到上，优先排查核心点）：

检查物理层：确认服务器网线连接正常（重新插拔网线）、交换机端口处于Up状态、路由器外网端口正常（联系网络管理员确认）；
检查网络层（核心步骤）：
1. 查看服务器IP配置：执行ip addr show，确认IP地址、子网掩码配置正确（如192.168.1.100/24）；
2. 确认网关配置：执行ip route show default，查看默认网关是否为内网路由器IP（如192.168.1.254），若缺失或错误，临时添加网关：ip route add default via 192.168.1.254 dev eth0；
3. 测试网关连通性：执行ping 192.168.1.254，若ping不通，说明网关故障（重启路由器，或联系网络管理员排查）；若能ping通，说明网关正常，问题出在路由或外网。
测试外网连通性：执行ping 180.101.49.12（百度IP），若能ping通，说明外网链路正常，问题出在DNS解析；若ping不通，说明外网链路故障（联系运营商排查）；
检查DNS解析（核心步骤）：
1. 查看DNS配置：执行cat /etc/resolv.conf，确认nameserver配置正确（如223.5.5.5）；
2. 测试DNS解析：执行nslookup baidu.com，若提示“未知域名”，说明DNS配置错误或DNS服务器宕机，临时更换DNS：echo "nameserver 223.5.5.5" >> /etc/resolv.conf；
检查防火墙：执行firewall-cmd --list-ports，确认是否禁止了出站流量（如禁止所有外网访问），临时关闭防火墙测试（systemctl stop firewalld），若能访问外网，说明防火墙规则拦截，调整规则后开启防火墙。

解决方案总结：优先排查网关和DNS配置，其次排查外网链路和防火墙，大部分此类故障均为网关缺失、DNS错误导致。

1.4.2 故障2：端口不通（如SSH 22端口、HTTP 80端口无法访问）

故障现象：客户端无法访问服务器的特定端口（如SSH 22端口无法登录、HTTP 80端口无法打开网页），ping服务器IP能通，但端口测试提示“连接拒绝”“连接超时”。

排查步骤（从应用层到传输层，优先排查服务和端口）：

检查对应服务状态（核心步骤）：确认端口对应的服务是否启动（如22端口对应sshd服务、80端口对应httpd服务）； # 查看sshd服务状态（22端口） ``systemctl status sshd ``# 若未启动，启动服务并设置开机自启 ``systemctl start sshd ``systemctl enable sshd `` ``# 查看httpd服务状态（80端口） ``systemctl status httpd ``# 启动httpd服务 ``systemctl start httpd
检查端口监听状态：执行ss -tuln | grep 端口号（如ss -tuln | grep 22），确认端口是否处于“LISTEN”（监听）状态；若无监听记录，说明服务未启动，或服务配置的端口不是该端口（如sshd配置文件修改了默认端口）；
检查防火墙（核心步骤）：执行firewall-cmd --list-ports，确认该端口是否已开放；若未开放，添加防火墙规则并重启防火墙： # 开放22端口（永久生效） ``firewall-cmd --add-port=22/tcp --permanent ``# 重启防火墙 ``firewall-cmd --reload
检查网络连通性：从客户端执行telnet 服务器IP 端口号（如telnet 192.168.1.100 22）或nc -zv 服务器IP 端口号，若提示“连接成功”，说明端口正常；若提示“连接拒绝”，说明服务未启动或端口未监听；若提示“连接超时”，说明防火墙拦截或网络中断；
定位端口占用：若端口处于监听状态，但无法访问，执行lsof -i:端口号，查看是否有其他进程占用该端口；若有，终止占用进程（kill -9 进程ID），重启对应服务。

解决方案总结：端口不通的核心原因是“服务未启动、端口未监听、防火墙拦截、端口被占用”，按步骤排查即可快速定位。

1.4.3 故障3：网络延迟高、丢包严重（如访问网页慢、数据库连接卡顿）

故障现象：访问网页、数据库、远程服务时卡顿，ping目标IP或域名时，延迟过高（如外网延迟>100ms、内网延迟>50ms），丢包率>1%，影响业务正常运行。

排查步骤（从本地到远程，优先排查延迟来源）：

测试延迟和丢包（核心步骤）：执行ping 目标IP -c 10（如ping baidu.com -c 10），查看丢包率（%packet loss）和平均延迟（avg），区分延迟/丢包来源（本地、内网、外网）； # 测试内网延迟（如ping网关） ``ping 192.168.1.254 -c 10 ``# 测试外网延迟（如ping百度IP） ``ping 180.101.49.12 -c 10 补充说明：内网正常延迟应≤10ms，丢包率0%；外网延迟根据链路不同略有差异，一般≤50ms，丢包率≤1%，超出则视为异常。
排查本地服务器问题（优先排除自身故障）：检查服务器负载：执行top或htop命令，查看CPU、内存、磁盘IO使用率，若负载过高（如CPU≥80%、内存≥90%），会导致服务器处理网络请求缓慢，表现为延迟高；解决方案：终止无用进程、扩容资源（临时）、优化业务程序（长期）。
检查网卡状态：执行ip addr show，查看网卡是否有错误包（如rx errors、tx errors），若有，说明网卡硬件故障或驱动异常；解决方案：重新启动网卡（systemctl restart network）、更新网卡驱动、更换网卡。
检查本地网络配置：确认网卡速率协商正常（执行ethtool eth0，查看Speed是否为1000M），速率过低会限制传输速度，导致延迟升高；解决方案：重新插拔网线、更换支持高速率的网线/交换机端口。
排查内网链路问题（若内网延迟/丢包异常）：测试内网其他设备：从其他内网服务器/PC ping目标服务器，若均出现延迟高、丢包，说明问题出在内网链路（交换机、网线）；若仅单台设备异常，说明该设备自身故障。
排查交换机故障：联系网络管理员，查看交换机端口流量、广播包数量，确认是否存在端口拥堵、广播风暴；解决方案：重启交换机、调整端口速率、定位并断开产生广播风暴的设备。
检查网线质量：若服务器与交换机之间的网线为五类线（支持100M），更换为六类线（支持1000M），劣质网线、过长网线（超过100米）会导致信号衰减，出现延迟和丢包。
排查外网链路问题（若外网延迟/丢包异常）：测试多外网点：ping多个外网IP（如百度、阿里、腾讯），若均出现延迟高、丢包，说明外网链路故障；若仅单个域名/IP异常，说明目标服务器或对应链路故障。
追踪路由路径：执行traceroute 目标IP（如traceroute baidu.com），查看数据包传输的每一跳延迟，定位延迟/丢包所在的路由节点；若某一跳延迟骤升、丢包严重，说明该路由节点故障，联系运营商排查。
检查路由器状态：联系网络管理员，查看路由器CPU、内存负载，确认路由器是否存在转发瓶颈；解决方案：重启路由器、优化路由器路由配置、升级路由器硬件。
排查防火墙/安全设备问题：若防火墙开启了流量限制、入侵检测等功能，可能会导致网络延迟升高；排查方法：查看防火墙日志，确认是否有大量流量被检测、拦截；临时关闭防火墙测试，若延迟恢复正常，说明防火墙规则需优化（如调整检测灵敏度、放开必要流量）。
检查内网安全设备（如入侵检测系统IDS），确认是否存在异常流量检测，导致数据包转发延迟；解决方案：调整安全设备检测规则，排除正常业务流量。

解决方案总结：延迟高、丢包严重的排查核心是“先定位来源（本地/内网/外网），再针对性排查设备、链路、配置”，优先排除本地服务器和内网链路故障，外网故障及时联系运营商处理。

1.4.4 故障4：DNS解析失败（能ping通IP，无法访问域名）

故障现象：服务器/客户端能ping通外网IP（如180.101.49.12），但访问域名（如baidu.com）提示“无法解析域名”“未知主机”，浏览器无法打开网页，依赖域名的服务（如数据库远程连接、API调用）无法正常运行。

排查步骤（聚焦DNS配置和解析链路，快速定位）：

确认解析故障类型（核心步骤）：执行ping 域名（如ping baidu.com），若提示“未知主机”，说明DNS解析失败；
执行ping 对应IP（如ping 180.101.49.12），若能ping通，确认是DNS解析问题，而非网络中断；若ping不通，说明是网络链路问题，参考故障1排查。
检查本地DNS配置（最常见原因）：查看DNS配置文件：执行cat /etc/resolv.conf，确认nameserver字段是否配置正确（如阿里云DNS：223.5.5.5、223.6.6.6）；若配置为空、错误，或指向不可用的DNS服务器，会导致解析失败。
临时更换DNS服务器（快速测试）：执行echo "nameserver 223.5.5.5" > /etc/resolv.conf（覆盖原有配置），或echo "nameserver 223.5.5.5" >> /etc/resolv.conf（追加配置），更换后重新测试nslookup baidu.com，若能解析，说明原DNS配置错误。
确认DNS配置生效：执行systemd-resolve --status（Systemd系统），查看当前生效的DNS服务器，确保与/etc/resolv.conf配置一致；若不一致，重启网络服务：systemctl restart network。
测试DNS解析链路（排查DNS服务器故障）：用dig命令测试解析细节：执行dig baidu.com，查看“ANSWER SECTION”是否有解析结果（即域名对应的IP）；若“ANSWER SECTION”为空，说明DNS服务器无法解析该域名，可能是DNS服务器宕机、解析权限问题。
测试不同DNS服务器：分别用阿里云DNS（223.5.5.5）、谷歌DNS（8.8.8.8）测试解析，执行nslookup baidu.com 223.5.5.5、nslookup baidu.com 8.8.8.8；若某一个DNS能解析，说明另一个DNS服务器异常，更换为可用DNS即可。
清除DNS缓存（解决解析缓存异常）： Linux系统（Systemd）：执行systemd-resolve --flush-caches，清除系统DNS缓存；
客户端（如Windows）：执行ipconfig /flushdns，清除客户端DNS缓存；
若服务器使用了本地DNS缓存服务（如nscd），重启服务：systemctl restart nscd，清除缓存。
排查防火墙/安全设备拦截（特殊情况）：确认防火墙是否禁止了DNS相关端口（UDP 53端口、TCP 53端口），执行firewall-cmd --list-ports，若未开放53端口，添加规则：firewall-cmd --add-port=53/udp --permanent、firewall-cmd --add-port=53/tcp --permanent，重启防火墙后测试。
排查是否存在DNS劫持：执行nslookup baidu.com，查看解析结果是否为正确IP（如180.101.49.12）；若解析到错误IP，说明存在DNS劫持，更换公共DNS服务器（如阿里云DNS），并联系网络管理员排查劫持来源。

解决方案总结：DNS解析失败的核心原因是“DNS配置错误、DNS服务器异常、缓存过期、防火墙拦截”，优先更换公共DNS测试，再逐步排查配置和拦截问题，高效解决故障。

1.5 运维实操注意事项（避坑重点）

网络运维实操中，很多故障都是由于操作不规范、忽略细节导致的，以下是高频注意事项，务必牢记，避免踩坑，提升运维效率和安全性：

操作前备份配置：修改网络配置（如IP、网关、DNS）、防火墙规则前，务必备份原有配置（如备份/etc/resolv.conf、网卡配置文件），避免配置错误导致网络中断，无法恢复；备份命令示例：cp /etc/resolv.conf /etc/resolv.conf.bak。
生产环境慎用“停止服务”操作：禁止随意停止防火墙、网络服务、核心进程（如sshd、network），尤其是生产服务器，临时停止后需立即开启，避免服务器暴露在风险中，或导致业务中断；若需停止测试，需提前告知业务负责人，确认无影响后再操作。
排查故障遵循“先易后难”原则：优先排查简单、高频的故障原因（如网线松动、DNS配置错误、服务未启动），再排查复杂问题（如路由配置、防火墙规则、硬件故障），避免盲目排查，浪费时间。
重视日志排查：网络故障排查时，多查看相关日志（防火墙日志、网络日志、服务日志），日志能精准定位故障原因（如被拦截的流量、服务启动失败的原因）；常用日志查看命令：journalctl -u network（网络服务日志）、journalctl -u firewalld（防火墙日志）。
规范IP地址管理：内网服务器IP地址建议采用静态IP配置，避免使用DHCP自动分配（防止IP地址冲突）；建立IP地址台账，记录每台服务器的IP、MAC地址、用途，便于排查IP冲突、定位设备。
定期检查网络状态：日常运维中，定期执行基础命令（ip addr show、ss -tuln、ping 网关），检查网络配置、端口监听、连通性，提前发现潜在故障（如网卡错误、端口异常），做到防患于未然。
权限控制：网络设备（交换机、路由器、防火墙）的配置权限需严格控制，仅授权给网络管理员，运维工程师无需掌握设备配置权限，遇到设备相关故障，及时联系网络管理员，避免误操作导致全网故障。

本章总结：计算机网络基础是运维工作的核心基石，重点掌握网络分层模型（OSI七层、TCP/IP四层）、核心协议（TCP、UDP、IP、ICMP、DNS）、网络设备（交换机、路由器、防火墙）的实操要点，熟练运用Linux运维命令，遵循“分层排查、先易后难”的思路，就能快速解决绝大多数网络故障，为后续系统运维工作打下坚实基础。

第二章：核心网络服务部署与运维（实操落地版）

运维工程师日常工作中，除了排查网络故障，核心职责还包括部署、维护各类基础网络服务——这些服务是保障业务正常运行的“基础设施”，如DNS服务（域名解析）、DHCP服务（IP自动分配）、防火墙服务（安全防护）、SSH服务（远程登录），需熟练掌握每类服务的部署步骤、配置方法、日常维护及故障处理，实现“部署-维护-故障解决”全流程实操落地。

本章核心目标：掌握4类高频网络服务的部署与运维，能独立完成服务安装、配置、启动、监控及常见故障排查，贴合生产环境实操，所有命令可直接套用，兼顾稳定性和安全性。

2.1 SSH服务（远程登录核心，必部署）

SSH（Secure Shell）服务是运维工程师远程管理服务器的核心工具，通过加密方式实现远程登录、命令执行、文件传输，替代不安全的Telnet（明文传输），是所有服务器必部署的基础服务，重点掌握“部署-配置-安全优化-故障处理”全流程。

2.1.1 服务部署（CentOS/Ubuntu通用）

大部分Linux系统（如CentOS 7/8、Ubuntu 20.04+）默认已安装openssh-server（SSH服务端），若未安装，执行以下命令部署，确保服务正常安装并启动。

# 一、CentOS系统（yum包管理）
# 安装SSH服务
yum install openssh-server -y
# 启动SSH服务
systemctl start sshd
# 设置开机自启（避免服务器重启后服务失效）
systemctl enable sshd
# 查看服务运行状态（确认启动成功）
systemctl status sshd

# 二、Ubuntu系统（apt包管理）
# 更新软件源（可选，确保安装最新版本）
apt update
# 安装SSH服务
apt install openssh-server -y
# 启动并设置开机自启
systemctl start sshd
systemctl enable sshd
# 查看服务状态
systemctl status sshd

补充说明：启动成功后，服务默认监听22端口（TCP），可通过ss -tuln | grep 22查看监听状态，出现“LISTEN”即为正常。

2.1.2 核心配置优化（安全+便捷，生产环境必做）

SSH默认配置（/etc/ssh/sshd_config）存在安全隐患（如允许密码登录、默认端口易被扫描），需修改配置文件优化，步骤如下：

备份配置文件（必做，避免配置错误导致无法远程登录）： cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
修改配置文件（用vim编辑，核心配置项如下）： vim /etc/ssh/sshd_config 核心配置修改（注释掉原配置，添加新配置，确保生效）： Port 2222 # 更改默认端口（22→2222，避免端口扫描和暴力破解，可自定义端口，范围1024-65535）
PermitRootLogin no # 禁止root用户直接远程登录（核心安全优化，避免root权限泄露）
PermitPasswordLogin no # 禁止密码登录，强制使用密钥登录（更安全，避免密码暴力破解）
PubkeyAuthentication yes # 开启密钥登录（配合上面配置，必开启）
ClientAliveInterval 300 # 客户端超时时间（300秒，无操作则断开连接，避免闲置连接占用资源）
重启SSH服务，使配置生效：systemctl restart sshd
配置密钥登录（补充步骤，配合PermitPasswordLogin no使用）：客户端生成密钥对（Windows用Xshell、Linux直接执行命令）： ssh-keygen -t rsa # 生成RSA密钥对，一路回车即可（默认保存路径~/.ssh/）
将客户端公钥上传到服务器（授权登录）： ssh-copy-id -p 2222 用户名@服务器IP # 如ssh-copy-id -p 2222 root@192.168.1.100
验证密钥登录：客户端执行ssh -p 2222 用户名@服务器IP，无需输入密码即可登录，说明配置成功。

2.1.3 日常维护与常见故障处理

SSH服务故障直接影响远程管理，需重点关注日常维护，快速排查常见问题：

故障1：SSH无法登录（提示“Connection refused”）排查步骤：① 执行systemctl status sshd，确认服务是否启动；② 执行ss -tuln | grep 端口号，确认端口是否监听；③ 检查防火墙，确认端口已开放；④ 检查配置文件，确认端口、登录权限配置正确。
解决方案：启动SSH服务（systemctl start sshd）、开放对应端口、修正sshd_config配置并重启服务。

故障2：密钥登录失败（提示“Permission denied”）排查步骤：① 确认客户端公钥已上传到服务器~/.ssh/authorized_keys文件；② 检查服务器~/.ssh目录权限（必须为700）、authorized_keys文件权限（必须为600），权限过高会导致密钥验证失败；③ 检查公钥内容是否完整，无多余空格或换行。

解决方案：修改权限（chmod 700 ~/.ssh、chmod 600 ~/.ssh/authorized_keys）、重新上传公钥。

日常维护要点：① 定期查看SSH日志（journalctl -u sshd），排查暴力破解、异常登录；② 定期更新openssh-server版本（yum update openssh-server -y），修复安全漏洞；③ 避免随意修改sshd_config配置，修改前务必备份。

2.2 DHCP服务（内网IP自动分配，免手动配置）

DHCP（动态主机配置协议）服务核心作用是“自动为内网设备（服务器、PC、摄像头）分配IP地址、子网掩码、网关、DNS服务器”，避免手动配置IP导致的地址冲突，减少运维工作量，适合内网设备较多的场景（如企业内网、机房），重点掌握部署、配置及IP分配管理。

2.2.1 服务部署（以CentOS 8为例，使用dhcpd服务）

安装DHCP服务： yum install dhcp-server -y 补充：Ubuntu系统安装命令为apt install isc-dhcp-server -y。
配置DHCP服务（核心步骤，修改配置文件）：备份默认配置文件： cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.bak
编辑配置文件（vim /etc/dhcp/dhcpd.conf），添加IP分配规则（根据内网网段自定义），示例配置（内网网段192.168.1.0/24）： # 定义DHCP服务全局配置 ``option domain-name "example.com"; # 内网域名（自定义） ``option domain-name-servers 223.5.5.5, 223.6.6.6; # 分配给客户端的DNS服务器 ``default-lease-time 86400; # 默认租约时间（24小时） ``max-lease-time 604800; # 最大租约时间（7天） `` ``# 定义IP地址池（分配给客户端的IP范围） ``subnet 192.168.1.0 netmask 255.255.255.0 { `` range 192.168.1.100 192.168.1.200; # 可分配IP范围（100-200，共101个IP） `` option subnet-mask 255.255.255.0; # 子网掩码 `` option routers 192.168.1.254; # 内网网关（路由器IP） `` option broadcast-address 192.168.1.255; # 广播地址 ``}
配置说明：① range字段定义可分配IP范围，避免与静态IP（如服务器固定IP）冲突；② 租约时间可根据需求调整，短期租约适合临时设备，长期租约适合固定设备；③ 必须确保网关、DNS配置正确，否则客户端获取IP后无法访问外网。
启动DHCP服务并设置开机自启： systemctl start dhcpd ``systemctl enable dhcpd ``# 查看服务状态，确认启动成功 ``systemctl status dhcpd
验证服务有效性：在内网一台未配置IP的PC/服务器上，设置“自动获取IP地址”，重启网卡（systemctl restart network）；
执行ip addr show，查看获取的IP是否在配置的range范围内（如192.168.1.100-200）；
执行ip route show，确认网关、DNS是否与DHCP配置一致，能ping通网关和外网，说明服务正常。

2.2.2 日常维护与常见故障处理

故障1：客户端无法获取IP地址（提示“未获取到IP”）排查步骤：① 确认DHCP服务是否正常运行（systemctl status dhcpd）；② 检查配置文件，确认IP地址池是否有可用IP（未耗尽）；③ 检查客户端网卡是否设置为“自动获取IP”；④ 检查内网链路，确保客户端与DHCP服务器连通（ping DHCP服务器IP）。
解决方案：启动DHCP服务、扩容IP地址池（调整range范围）、修正客户端网卡设置、排查内网连通性。

故障2：客户端获取到错误IP（如不在配置的IP池内）排查步骤：① 检查DHCP配置文件，确认subnet、range配置正确，无语法错误；② 检查内网是否有其他DHCP服务器（冲突），执行netstat -an | grep 67（DHCP服务器默认端口67），定位其他DHCP服务器并关闭；③ 清除客户端DHCP缓存（dhclient -r，重新获取IP）。

解决方案：修正DHCP配置文件并重启服务、关闭冲突的DHCP服务器、清除客户端缓存后重新获取IP。

日常维护要点：① 定期查看DHCP租约日志（cat /var/log/messages | grep dhcpd），了解IP分配情况；② 定期检查IP地址池使用情况，避免IP耗尽；③ 若内网有固定IP设备，需在DHCP配置中排除对应IP（添加host 设备名 { hardware ethernet MAC地址; fixed-address 固定IP; }），避免IP冲突。

2.3 DNS服务（内网域名解析，提升运维效率）

前文已介绍DNS协议的基础用法，此处重点部署内网DNS服务（基于bind软件），实现“内网设备用域名访问服务器”（如用server1.example.com访问192.168.1.100），无需记忆复杂IP，提升运维效率，同时避免依赖外网DNS，确保内网解析稳定。

2.3.1 服务部署（以CentOS 8为例，bind服务）

安装bind服务及相关工具： yum install bind bind-utils -y ``# Ubuntu系统：apt install bind9 bind9-utils -y
配置DNS服务（核心步骤，分3步：主配置、区域配置、解析记录配置）：第一步：修改主配置文件（/etc/named.conf），允许内网设备解析： vim /etc/named.conf 核心修改（注释原有的localhost限制，添加内网网段允许）： // listen-on port 53 { 127.0.0.1; }; # 注释掉，允许所有网卡监听53端口 ``// allow-query { localhost; }; # 注释掉，改为允许内网网段 ``allow-query { 192.168.1.0/24; 127.0.0.1; }; # 允许内网192.168.1.0/24网段解析
第二步：添加区域配置（在主配置文件末尾添加，定义内网域名解析规则）：zone "example.com" IN { # 内网域名（自定义，如company.com） `` type master; # 主DNS服务器 `` file "example.com.zone"; # 解析记录文件（存放在/var/named/目录下） `` allow-update { none; }; # 禁止更新解析记录（安全） ``};
第三步：创建解析记录文件（/var/named/example.com.zone），添加内网服务器解析记录： cd /var/named/ ``# 复制模板文件，创建解析记录文件 ``cp named.localhost example.com.zone ``# 修改文件权限（必须为named用户，否则服务无法读取） ``chown named:named example.com.zone ``# 编辑解析记录 ``vim example.com.zone 核心解析记录（修改模板内容，适配内网场景）： $TTL 1D # 解析记录缓存时间（1天） ``@ IN SOA example.com. admin.example.com. ( `` 0 ; serial（序列号，更新记录时递增） `` 1D ; refresh（刷新时间） `` 1H ; retry（重试时间） `` 1W ; expire（过期时间） `` 3H ) ; minimum（最小缓存时间） `` IN NS ns.example.com. # DNS服务器域名 ``ns IN A 192.168.1.100 # DNS服务器自身IP（必须正确） ``server1 IN A 192.168.1.101 # 内网服务器1，域名server1.example.com ``server2 IN A 192.168.1.102 # 内网服务器2，域名server2.example.com ``gateway IN A 192.168.1.254 # 网关域名，方便记忆配置说明：① @代表当前域名（example.com）；② NS记录指定DNS服务器，A记录实现“域名→IP”正向解析；③ 序列号serial每次修改解析记录后需递增（如从0改为1），否则解析不生效。
启动bind服务并设置开机自启： systemctl start named ``systemctl enable named ``# 查看服务状态，确认启动成功 ``systemctl status named
验证服务有效性：在本地DNS服务器上测试：执行nslookup server1.example.com，若能解析到192.168.1.101，说明配置成功；
在内网其他设备上测试：将设备DNS配置为内网DNS服务器IP（192.168.1.100），执行nslookup server2.example.com，能解析到对应IP，说明服务正常。

2.3.2 日常维护与常见故障处理

DNS服务的稳定性直接影响内网设备通信和外网访问，日常需重点关注服务运行状态、解析记录更新及日志排查，快速处理各类解析故障，确保解析服务不中断。

故障1：内网设备无法解析内网域名（能解析外网域名）排查步骤：① 确认bind服务是否正常运行（systemctl status named），若未启动，启动服务并设置开机自启；② 检查内网设备DNS配置，确认是否指向内网DNS服务器IP（如192.168.1.100），若指向外网DNS，需修改为内网DNS；③ 测试本地解析：在DNS服务器上执行nslookup server1.example.com，若能正常解析，说明服务配置正常，问题出在客户端；若无法解析，检查解析记录文件（/var/named/example.com.zone），确认记录配置正确（如IP、域名无错误）、序列号serial已递增；④ 检查解析记录文件权限，确保为named:named（ls -l /var/named/example.com.zone），权限错误会导致服务无法读取记录；⑤ 检查防火墙，确认开放53端口（UDP/TCP），执行firewall-cmd --list-ports，若未开放，添加规则：firewall-cmd --add-port=53/udp --permanent、firewall-cmd --add-port=53/tcp --permanent，重启防火墙。
解决方案：启动bind服务、修正客户端DNS配置、修正解析记录文件并递增序列号、调整文件权限、开放53端口。

故障2：所有域名无法解析（内网+外网均无法解析）排查步骤：① 确认bind服务是否宕机，执行systemctl status named，若服务异常，重启服务（systemctl restart named），查看服务日志（journalctl -u named），定位故障原因（如配置文件语法错误、解析记录文件损坏）；② 检查主配置文件（/etc/named.conf），执行named-checkconf命令，检测配置文件语法错误，若有错误，根据提示修正；③ 检查解析记录文件，执行named-checkzone example.com /var/named/example.com.zone，检测记录文件语法错误，修正后重启服务；④ 测试DNS服务器连通性，从客户端ping内网DNS服务器IP，若ping不通，排查网络链路故障（网线、交换机端口）；⑤ 若内网DNS依赖外网DNS解析外网域名，检查主配置文件是否添加“转发器”（未添加则无法解析外网），需添加转发器配置。

补充：转发器配置（主配置文件末尾添加）： forwarders { 223.5.5.5; 223.6.6.6; }; # 转发外网解析请求到阿里云DNS 添加后重启bind服务，即可实现外网域名解析。

解决方案：重启bind服务、修正配置文件/解析记录文件语法错误、排查网络连通性、添加外网转发器。

故障3：解析延迟过高（访问内网/外网域名卡顿）排查步骤：① 检查DNS服务器负载，执行top命令，查看named进程CPU、内存使用率，若负载过高，优化解析记录（减少冗余记录）、升级服务器资源；② 检查解析缓存，bind服务默认开启缓存，可通过rndc flush命令清除缓存，测试解析速度；③ 检查转发器，若依赖外网转发器，更换延迟更低的公共DNS（如阿里云、114DNS）；④ 检查内网链路，若内网解析延迟高，排查交换机、网线故障，确保DNS服务器与客户端连通顺畅。

解决方案：优化服务器资源、清除解析缓存、更换外网转发器、排查内网链路故障。

日常维护要点：定期查看服务状态：每天执行systemctl status named，确认服务正常运行，避免服务宕机未发现；

定期检查日志：执行journalctl -u named，排查解析错误、服务异常等问题，提前发现潜在故障；

更新解析记录：当内网服务器IP变更时，及时修改解析记录文件（/var/named/example.com.zone），递增序列号serial，重启bind服务，确保解析生效；

备份配置文件：定期备份主配置文件（/etc/named.conf）和解析记录文件（/var/named/*.zone），避免配置丢失或错误导致服务无法恢复；

定期更新bind版本：执行yum update bind -y（CentOS）、apt update bind9 -y（Ubuntu），修复安全漏洞，提升服务稳定性。

2.4 防火墙服务（安全防护核心，必配置）

前文已介绍防火墙的基础概念和Linux firewalld的基础命令，此处重点聚焦防火墙的实操配置、规则优化及故障处理——防火墙是服务器安全的“第一道防线”，生产环境中必须严格配置，既要拦截恶意流量，也要确保正常业务流量通行，实现“安全与便捷兼顾”。

本节重点讲解Linux系统自带的firewalld防火墙（CentOS 7/8、RHEL 7/8默认防火墙），Ubuntu系统可参考（Ubuntu默认使用ufw防火墙，核心逻辑一致，命令略有差异）。

2.4.1 防火墙基础配置（生产环境必做）

防火墙配置核心原则：最小开放原则，仅开放业务必需的端口、IP和协议，禁止所有不必要的流量，重点配置“入站规则”（控制外部访问服务器），出站规则可默认放行（根据业务需求调整）。

确认防火墙状态（先确保服务正常运行）： # 查看firewalld运行状态 ``systemctl status firewalld ``# 若未启动，启动并设置开机自启（生产环境必须开启） ``systemctl start firewalld ``systemctl enable firewalld
核心规则配置（常用场景，直接套用）：场景1：开放常用业务端口（SSH、HTTP、HTTPS），仅允许内网IP访问（最安全）： # 开放22端口（SSH），仅允许192.168.1.0/24内网网段访问 ``firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port protocol="tcp" port="22" accept' --permanent ``# 开放80端口（HTTP），允许所有IP访问（对外提供网页服务） ``firewall-cmd --add-port=80/tcp --permanent ``# 开放443端口（HTTPS），允许所有IP访问 ``firewall-cmd --add-port=443/tcp --permanent ``# 开放3306端口（MySQL），仅允许指定内网IP（192.168.1.10）访问 ``firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.1.10" port protocol="tcp" port="3306" accept' --permanent
场景2：禁止特定IP访问（拦截恶意IP）： # 禁止10.0.0.5这个IP访问服务器（所有端口） ``firewall-cmd --add-rich-rule='rule family="ipv4" source address="10.0.0.5" reject' --permanent ``# 禁止172.16.0.0/12网段访问服务器的22端口 ``firewall-cmd --add-rich-rule='rule family="ipv4" source address="172.16.0.0/12" port protocol="tcp" port="22" reject' --permanent
场景3：放行特定协议（如ICMP协议，允许ping）： # 允许内网网段192.168.1.0/24 ping服务器 ``firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" protocol value="icmp" accept' --permanent ``# 禁止外网IP ping服务器（提升安全性） ``firewall-cmd --add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" protocol value="icmp" reject' --permanent
重启防火墙，使规则生效（所有永久规则修改后必须重启）： firewall-cmd --reload
查看已配置的规则（验证配置是否正确）： # 查看所有开放的端口和规则（详细） ``firewall-cmd --list-all ``# 仅查看开放的端口 ``firewall-cmd --list-ports ``# 仅查看富规则（IP、端口限制规则） ``firewall-cmd --list-rich-rules

2.4.2 规则优化与管理（生产环境进阶）

日常运维中，需根据业务变化调整防火墙规则，同时做好规则管理，避免规则冗余、冲突，提升防火墙运行效率和安全性。

规则备份与恢复（必做）：备份规则：将当前防火墙规则导出到文件，便于后续恢复（如配置错误时）： firewall-cmd --list-all-zones > /etc/firewalld/firewall_rules.bak
恢复规则：当规则配置错误，导致服务无法访问时，可恢复备份的规则： # 先清空当前所有规则（谨慎操作，确保备份有效） ``firewall-cmd --flush ``# 重新加载备份的规则（需手动编辑备份文件，提取核心规则后执行） ``# 示例：恢复开放22、80端口的规则 ``firewall-cmd --add-port=22/tcp --permanent ``firewall-cmd --add-port=80/tcp --permanent ``firewall-cmd --reload

规则删除（清理冗余规则）： # 删除指定端口规则（如删除80端口） ``firewall-cmd --remove-port=80/tcp --permanent ``# 删除指定富规则（如删除禁止10.0.0.5访问的规则） ``firewall-cmd --remove-rich-rule='rule family="ipv4" source address="10.0.0.5" reject' --permanent ``# 重启防火墙生效 ``firewall-cmd --reload

临时规则与永久规则区分（避坑重点）：临时规则：配置时不加--permanent参数，重启防火墙后失效，适合临时测试（如临时开放端口排查故障）； # 临时开放8080端口（重启防火墙后失效） ``firewall-cmd --add-port=8080/tcp

永久规则：配置时加--permanent参数，重启防火墙后仍生效，适合生产环境长期使用；

注意：临时规则不会同步到永久规则，若需将临时规则转为永久规则，需重新添加并加上--permanent参数。

端口转发（进阶配置，可选）：当服务器有多个网卡，或需要将外部访问的端口转发到内网其他服务器时，可配置端口转发（如将外部访问的80端口，转发到内网192.168.1.101的80端口）：# 开启端口转发功能（永久生效） ``firewall-cmd --add-masquerade --permanent ``# 配置端口转发：外部访问80端口 → 转发到192.168.1.101的80端口 ``firewall-cmd --add-forward-port=port=80:proto=tcp:toaddr=192.168.1.101:toport=80 --permanent ``# 重启防火墙生效 ``firewall-cmd --reload

2.4.3 常见故障处理与日常维护

故障1：业务端口无法访问（确认服务正常，怀疑防火墙拦截）排查步骤：① 确认服务正常运行（systemctl status 服务名）、端口正常监听（ss -tuln | grep 端口号）；② 查看防火墙规则，确认该端口是否已开放（firewall-cmd --list-ports | grep 端口号）；③ 若端口已开放，检查是否有IP限制（富规则），确认访问IP在允许范围内；④ 临时关闭防火墙测试（systemctl stop firewalld），若能访问，说明确实是防火墙拦截；⑤ 查看防火墙日志，定位拦截记录（journalctl -u firewalld | grep 被拦截IP），确认拦截原因。
解决方案：开放对应端口、调整富规则（允许访问IP）、修正规则配置并重启防火墙。

故障2：防火墙规则配置错误，导致所有流量无法通过排查步骤：① 临时关闭防火墙（systemctl stop firewalld），确保业务能正常访问，确认是规则配置问题；② 查看已配置的规则（firewall-cmd --list-all），排查冗余、冲突规则（如同时开放和禁止同一个端口）；③ 恢复备份的规则，或清空所有规则后重新配置核心规则。

解决方案：恢复备份规则、清空冗余/冲突规则、重新配置核心规则并重启防火墙。

故障3：防火墙无法启动（提示配置错误）排查步骤：① 查看防火墙启动日志（journalctl -u firewalld），日志会提示具体的配置错误（如规则语法错误、端口格式错误）；② 检查主配置文件（/etc/firewalld/firewalld.conf）和规则文件（/etc/firewalld/zones/public.xml），修正语法错误；③ 若无法定位错误，可恢复默认配置（firewall-cmd --reset），重新配置规则。

解决方案：修正配置文件语法错误、恢复默认配置后重新配置规则。

日常维护要点：定期检查规则：每周查看一次防火墙规则（firewall-cmd --list-all），清理冗余、过期规则，避免规则过多影响运行效率；

定期查看日志：每周查看防火墙日志（journalctl -u firewalld），排查恶意访问、规则拦截异常等问题，及时调整规则；

禁止随意关闭防火墙：生产环境中，仅在排查故障时临时关闭，排查完成后立即开启，避免服务器暴露在公网风险中；

定期更新firewalld版本：执行yum update firewalld -y，修复安全漏洞，提升防火墙防护能力；

规则变更记录：每次修改防火墙规则后，做好记录（如修改时间、修改内容、修改原因），便于后续追溯和问题排查。

2.5 本章总结

本章重点讲解了4类运维高频网络服务（SSH、DHCP、DNS、防火墙）的部署、配置、日常维护及故障处理，核心要点的是“实操落地”——所有命令可直接套用生产环境，所有故障排查步骤遵循“先定位原因、再针对性解决”的思路，兼顾安全性和稳定性。

运维工程师需牢记：网络服务是业务运行的“基础设施”，部署时需注重安全优化（如SSH密钥登录、防火墙最小开放），维护时需定期检查服务状态和日志，故障处理时需快速定位、高效解决，确保服务不中断，为业务稳定运行提供保障。后续章节将讲解网络性能优化、网络安全加固等进阶内容，进一步提升运维实操能力。

第三章：网络性能优化与安全加固（进阶实操）

当掌握了基础网络故障排查和核心网络服务运维后，运维工程师的核心进阶方向是“优化网络性能”和“加固网络安全”——生产环境中，不仅要确保网络通畅，还要提升网络传输效率、降低延迟，同时防范各类网络攻击（如暴力破解、DDoS攻击、端口扫描），保障网络和服务器的安全稳定运行。

本章核心目标：掌握网络性能优化的核心方法（针对延迟、丢包、卡顿），熟练运用性能监控工具，掌握常见网络安全攻击的防范措施，实现“性能达标、安全可控”，贴合生产环境进阶运维需求。

3.1 网络性能监控工具（实操必备）

优化网络性能的前提是“精准定位性能瓶颈”，需熟练掌握各类Linux网络性能监控工具，实时查看网络流量、延迟、丢包、端口状态等指标，快速找到性能短板，为优化提供依据。以下是运维高频监控工具，重点掌握用法和指标解读。

3.1.1 iftop（实时流量监控，核心工具）

iftop工具用于实时监控服务器的网络流量（入站、出站），能直观查看每个IP的流量占用情况，快速定位“流量异常”（如某IP占用大量带宽，导致网络拥堵），是排查网络卡顿、带宽耗尽的核心工具。

安装iftop工具： # CentOS系统（yum包管理） ``yum install iftop -y ``# Ubuntu系统（apt包管理） ``apt update && apt install iftop -y
核心用法：直接执行命令进入交互界面，无需复杂参数，上手简单。 iftop交互界面核心解读（重点关注3个部分）：
1. 顶部栏：显示当前监控的网卡（如eth0、ens33）、系统时间、流量单位（默认KB，按大写K切换单位：KB→MB→GB）；
2. 中间主体栏：显示每个网络连接的详细信息，格式为「源IP:端口 → 目标IP:端口」，对应三列流量数据：
  - TX：当前连接的出站流量（服务器发送给其他设备的数据）；
  - RX：当前连接的入站流量（其他设备发送给服务器的数据）；
  - TOTAL：当前连接的总流量；
3. 底部栏：显示整体流量统计，包括入站（RX）、出站（TX）的瞬时流量和平均流量（1秒、5秒、10秒平均），可快速判断整体带宽占用情况。
常用交互命令（进入界面后按对应按键，提升操作效率）：
1. h：查看帮助信息（所有交互命令说明）；
2. n：切换显示模式（默认显示主机名，按n切换为IP地址，更便于定位设备）；
3. s：切换显示“源IP”和“目标IP”的排序，可快速找到流量来源/去向；
4. t：切换显示格式（双列→单行→多行），双列模式最直观，适合快速排查；
5. p：显示端口号（默认不显示端口，按p可查看具体端口，便于定位业务流量）；
6. q：退出iftop交互界面（核心，避免占用终端）。
实操场景：当服务器出现“网络卡顿、访问缓慢”时，第一步执行iftop，若发现某IP（如10.0.0.8）的TX/RX流量持续过高（如超过100MB/s），需进一步判断：
1. 若为恶意IP（非业务IP）：立即通过防火墙禁止其访问（firewall-cmd --add-rich-rule='rule family="ipv4" source address="10.0.0.8" reject' --permanent && firewall-cmd --reload）；
2. 若为正常业务IP（如数据库、web服务器）：需优化业务（如限制单IP带宽、扩容服务器带宽、优化业务程序减少冗余流量）。

3.1.2 iperf3（带宽测试工具，量化性能）

iftop用于实时监控流量，而iperf3用于量化测试网络带宽（最大传输速率）、延迟、丢包率，适合测试内网设备之间、服务器与外网之间的带宽瓶颈，比如“判断服务器到网关的最大带宽是否达标”“测试跨机房链路的传输性能”。

安装iperf3工具： # CentOS系统 ``yum install iperf3 -y ``# Ubuntu系统 ``apt install iperf3 -y
核心用法：需两台设备配合（服务器A作为服务端，服务器B作为客户端），测试两者之间的带宽。
1. 步骤1：在服务端（如192.168.1.100）启动iperf3服务，监听默认端口5201： iperf3 -s # -s 表示启动服务端
2. 步骤2：在客户端（如192.168.1.101）执行测试命令，向服务端发送流量，测试带宽： # 基础测试（默认TCP协议，测试10秒） ``iperf3 -c 192.168.1.100 ``# 常用参数（贴合运维实操） ``iperf3 -c 192.168.1.100 -t 30 # -t 30：测试30秒，结果更精准 ``iperf3 -c 192.168.1.100 -u # -u：测试UDP协议带宽（适合视频、语音等业务） ``iperf3 -c 192.168.1.100 -P 10 # -P 10：启动10个并行连接，测试最大并发带宽
结果解读（重点关注3个核心指标）：
1. Bandwidth：带宽速率（单位Mbps），若测试结果远低于服务器/链路的额定带宽（如1000M网卡，测试结果仅100Mbps），说明存在带宽瓶颈；
2. Latency：延迟（单位ms），正常内网延迟≤10ms，外网延迟≤50ms，延迟过高需排查链路或路由；
3. Loss：丢包率（%），正常丢包率≤1%，丢包率过高说明链路不稳定（如网线质量差、交换机拥堵）。
实操场景：服务器带宽额定为1000M（千兆网卡），但业务访问时带宽始终上不去，执行iperf3测试后，发现带宽仅能达到100M，排查方向：
1. 检查网卡速率：执行ethtool eth0，查看Speed是否为1000M，若为100M，重新插拔网线或更换交换机端口；
2. 检查交换机端口：联系网络管理员，确认交换机端口速率是否协商为1000M，避免端口速率限制；
3. 检查网线：五类线仅支持100M，更换为六类线（支持1000M）。

3.1.3 netstat/ss（端口与连接监控，补充工具）

前文已介绍netstat和ss命令的基础用法，此处重点聚焦“性能监控”场景——通过查看端口监听状态、连接数量、连接状态，排查“端口占用、连接泄露”等导致的性能问题，是运维日常排查的高频工具。

核心用法（性能监控重点命令）：

# 1. 查看所有TCP/UDP连接状态，统计各类连接数量（排查连接泄露）
ss -an | grep TCP | awk '{print $6}' | sort | uniq -c
# 解读：重点关注TIME_WAIT、CLOSE_WAIT状态的连接数量，若数量过多（如超过1000），说明存在连接泄露

# 2. 查看指定端口的连接情况（如22端口，排查SSH连接异常）
ss -an | grep :22
# 解读：若出现大量来自同一IP的连接，可能是暴力破解，需通过防火墙禁止该IP

# 3. 查看所有监听端口及对应的进程（定位端口占用）
ss -tulnp
# 解读：-t（TCP）、-u（UDP）、-l（监听）、-n（IP/端口）、-p（进程），快速找到占用端口的进程

# 4. 查看网络连接统计（整体性能参考）
netstat -s  # 统计TCP/UDP连接的详细信息，如握手失败次数、重传次数
# 解读：若TCP重传次数过多，说明网络不稳定、丢包严重

注意：netstat命令已逐步被ss命令替代（ss命令更高效，占用资源更少），生产环境中优先使用ss命令；仅在老旧系统（如CentOS 6）中使用netstat。

3.1.4 ping/mtr（延迟与丢包追踪，定位链路瓶颈）

ping命令用于基础连通性测试，而mtr命令（结合ping和traceroute的功能）可追踪数据包传输的每一跳链路，精准定位延迟、丢包的具体节点，适合排查“跨网段、外网链路”的性能问题（如“访问阿里云服务器延迟高，到底是哪一跳出了问题”）。

安装mtr工具： # CentOS系统 ``yum install mtr -y ``# Ubuntu系统 ``apt install mtr -y
核心用法：直接执行命令，追踪目标IP/域名的链路： # 基础用法：追踪百度域名的链路 ``mtr baidu.com ``# 常用参数（实操必备） ``mtr -c 10 baidu.com # -c 10：发送10个数据包，统计结果更精准 ``mtr -n baidu.com # -n：显示IP地址，不显示主机名，便于定位节点
结果解读（重点关注2个核心指标）：示例：mtr测试结果中，第3跳（10.0.1.1）丢包率50%、延迟80ms，说明该路由器（10.0.1.1）负载过高或故障，需联系网络管理员排查。
1. Loss%：每一跳的丢包率，若某一跳丢包率>1%，说明该节点存在故障（如路由器、交换机拥堵）；
2. Avg：每一跳的平均延迟（ms），若某一跳延迟骤升（如从10ms升至100ms），说明该链路节点存在瓶颈。

3.2 网络性能优化实操（针对性解决延迟、丢包、卡顿）

网络性能优化的核心思路：先定位瓶颈（用3.1节工具），再针对性优化，避免盲目操作。以下是生产环境中最常见的4类性能问题（延迟高、丢包严重、带宽不足、连接泄露），结合工具排查，给出可直接落地的优化方案，兼顾实操性和稳定性。

3.2.1 优化方向1：降低网络延迟（解决“访问卡顿、响应慢”）

延迟过高的核心原因：链路距离过远、路由转发效率低、网卡配置不当、DNS解析延迟，针对性优化如下：

优化DNS解析延迟（最易忽略，效果显著）：
1. 更换优质公共DNS：优先使用本地运营商DNS或阿里云、腾讯公共DNS，避免使用国外DNS（如谷歌8.8.8.8），减少解析延迟； # 修改DNS配置（永久生效，CentOS 8为例） ``vim /etc/sysconfig/network-scripts/ifcfg-eth0 # 编辑网卡配置文件 ``# 添加以下内容（阿里云DNS） ``DNS1=223.5.5.5 ``DNS2=223.6.6.6 ``# 重启网络服务生效 ``systemctl restart NetworkManager
2. 开启DNS缓存：在服务器上部署本地DNS缓存服务（如nscd），减少重复解析，提升解析速度： # 安装nscd服务 ``yum install nscd -y ``# 启动并设置开机自启 ``systemctl start nscd ``systemctl enable nscd ``# 清除DNS缓存（必要时） ``systemctl restart nscd
优化网卡配置（提升数据传输效率）：
1. 关闭网卡节能模式：节能模式会降低网卡速率，导致延迟升高，需关闭： # 查看网卡节能状态（以eth0为例） ``ethtool --show-power eth0 ``# 关闭节能模式 ``ethtool --set-power eth0 off ``# 永久关闭：编辑网卡配置文件，添加以下内容 ``echo "ETHTOOL_OPTS=\"--set-power off\"" >> /etc/sysconfig/network-scripts/ifcfg-eth0 ``systemctl restart NetworkManager
2. 设置网卡速率为固定值：避免速率协商失败导致的延迟，将网卡速率固定为1000M（千兆网卡）： # 临时设置（重启网卡失效） ``ethtool -s eth0 speed 1000 duplex full autoneg off ``# 永久设置：编辑网卡配置文件 ``echo "ETHTOOL_OPTS=\"speed 1000 duplex full autoneg off\"" >> /etc/sysconfig/network-scripts/ifcfg-eth0 ``systemctl restart NetworkManager
优化路由配置（减少转发环节）：若跨网段通信延迟高，检查路由表，删除冗余路由、添加静态路由，减少路由转发次数： # 查看路由表，排查冗余路由 ``ip route show ``# 添加静态路由（如内网192.168.2.0/24网段，通过网关192.168.1.254转发） ``ip route add 192.168.2.0/24 via 192.168.1.254 dev eth0 ``# 永久添加静态路由：编辑/etc/sysconfig/network-scripts/route-eth0文件 ``echo "192.168.2.0/24 via 192.168.1.254 dev eth0" > /etc/sysconfig/network-scripts/route-eth0 ``systemctl restart NetworkManager

3.2.2 优化方向2：解决丢包严重（解决“数据丢失、连接不稳定”）

丢包严重的核心原因：链路质量差、网络拥堵、交换机/路由器负载过高、TCP重传配置不当，针对性优化如下：

排查并优化链路质量：
1. 更换劣质网线/光纤：五类线、破损网线、过长网线（超过100米）会导致信号衰减，丢包率升高，更换为六类线（千兆）、优质光纤；
2. 检查光纤模块：若使用光纤连接，检查光纤模块接触是否良好、是否损坏，更换故障模块；
3. 排查交换机端口：联系网络管理员，查看交换机端口是否存在拥堵、故障，更换交换机端口测试。
优化TCP协议配置（减少重传，降低丢包影响）：通过修改Linux内核参数，优化TCP重传机制、缓冲区大小，减少丢包带来的影响（临时生效，重启服务器失效；永久生效需写入配置文件）： # 临时优化TCP参数（直接执行命令） ``# 1. 增大TCP接收缓冲区（单位：字节） ``sysctl -w net.core.rmem_max=16777216 ``# 2. 增大TCP发送缓冲区 ``sysctl -w net.core.wmem_max=16777216 ``# 3. 减少TCP重传次数（默认15次，改为5次，快速释放连接） ``sysctl -w net.ipv4.tcp_retries2=5 ``# 4. 开启TCP快速重传（加速丢包恢复） ``sysctl -w net.ipv4.tcp_fastopen=3 `` ``# 永久优化：将参数写入/etc/sysctl.conf文件 ``echo "net.core.rmem_max=16777216" >> /etc/sysctl.conf ``echo "net.core.wmem_max=16777216" >> /etc/sysctl.conf ``echo "net.ipv4.tcp_retries2=5" >> /etc/sysctl.conf ``echo "net.ipv4.tcp_fastopen=3" >> /etc/sysctl.conf ``# 使配置生效 ``sysctl -p
限制异常流量（避免网络拥堵导致丢包）：通过iftop找到占用带宽过高的IP/端口，若为非业务流量（如恶意下载、攻击流量），通过防火墙限制其带宽或禁止访问；若为业务流量，需扩容带宽或优化业务（如分片传输大文件）。

3.2.3 优化方向3：提升带宽利用率（解决“带宽耗尽、访问缓慢”）

带宽耗尽的核心原因：业务流量过大、恶意流量占用、带宽配置不足，针对性优化如下：

限制单IP/端口带宽（避免单个设备占用全部带宽）：使用Linux流量控制工具（tc），限制单IP或端口的最大带宽，确保带宽合理分配（以限制192.168.1.101的带宽为100MB/s为例）： # 1. 安装tc工具（部分系统默认已安装） ``yum install iproute-tc -y ``# 2. 限制192.168.1.101的出站带宽为100MB/s（eth0网卡） ``tc qdisc add dev eth0 root handle 1: htb default 12 ``tc class add dev eth0 parent 1: classid 1:1 htb rate 100Mbit ``tc class add dev eth0 parent 1:1 classid 1:12 htb rate 100Mbit ``tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.1.101 flowid 1:12 ``# 3. 取消限制（必要时） ``tc qdisc del dev eth0 root
优化业务流量（减少冗余数据）：
1. 开启数据压缩：在web服务器（如Nginx）、API服务中开启GZIP压缩，减少数据传输量，降低带宽占用；
2. 分片传输大文件：避免一次性传输超大文件（如10GB以上），采用分片传输（如FTP分片、断点续传），减少带宽占用峰值；
3. 限制非必要流量：禁止服务器下载、更新非业务软件，关闭不必要的后台服务（如自动更新、日志同步），减少冗余流量。
扩容带宽（长期解决方案）：若业务流量持续增长，带宽长期处于饱和状态（通过iftop监控，带宽占用≥90%），需联系运营商扩容带宽（如从100M升级为1000M），或部署负载均衡（如Nginx、HAProxy），分散流量到多台服务器，减轻单台服务器的带宽压力。

3.2.4 优化方向4：解决连接泄露（解决“端口耗尽、服务卡顿”）

连接泄露（大量连接处于TIME_WAIT、CLOSE_WAIT状态）会占用服务器端口和内存资源，导致端口耗尽、服务无法启动、访问卡顿，核心优化方案如下：

排查连接泄露原因： # 查看各类连接状态数量，定位异常状态 ``ss -an | grep TCP | awk '{print $6}' | sort | uniq -c ``# 若TIME_WAIT数量过多（如超过1000），说明存在连接泄露；若CLOSE_WAIT过多，说明服务进程异常
优化TCP TIME_WAIT状态配置：通过内核参数，减少TIME_WAIT连接的存活时间，加快端口释放： # 临时优化（重启失效） ``# 1. 减少TIME_WAIT连接存活时间（默认60秒，改为30秒） ``sysctl -w net.ipv4.tcp_fin_timeout=30 ``# 2. 开启TIME_WAIT快速回收 ``sysctl -w net.ipv4.tcp_tw_recycle=1 ``# 3. 开启TIME_WAIT复用（允许TIME_WAIT连接被重新使用） ``sysctl -w net.ipv4.tcp_tw_reuse=1 `` ``# 永久优化：写入/etc/sysctl.conf ``echo "net.ipv4.tcp_fin_timeout=30" >> /etc/sysctl.conf ``echo "net.ipv4.tcp_tw_recycle=1" >> /etc/sysctl.conf ``echo "net.ipv4.tcp_tw_reuse=1" >> /etc/sysctl.conf ``sysctl -p
修复服务进程异常（解决CLOSE_WAIT过多）：
1. 定位异常进程：执行ss -an | grep CLOSE_WAIT | awk '{print $5}' | sort | uniq -c，找到对应端口，再通过ss -tulnp | grep 端口号找到异常进程；
2. 重启异常服务：如进程为web服务（httpd），执行systemctl restart httpd，释放异常连接；
3. 优化业务程序：CLOSE_WAIT过多多为业务程序未正确关闭连接导致，需开发人员优化程序，确保连接正常关闭。

3.3 网络安全加固（防范常见攻击，保障服务安全）

网络安全加固的核心原则：最小权限、层层防护，从“端口防护、访问控制、攻击防范、日志审计”四个维度入手，防范常见网络攻击（暴力破解、DDoS攻击、端口扫描、ARP欺骗），确保服务器和网络的安全稳定，避免数据泄露、服务中断。

3.3.1 基础加固：端口与访问控制（第一道防线）

核心思路：仅开放业务必需的端口，禁止不必要的端口访问；限制访问IP，仅允许信任IP访问核心端口（如SSH、数据库端口），避免暴露在公网风险中。

防火墙规则加固（核心，必做）：延续第二章防火墙配置，进一步优化规则，实现“最小开放”： # 1. 清空原有冗余规则（谨慎操作，确保备份） ``firewall-cmd --flush ``# 2. 开放核心业务端口，仅允许信任IP访问 ``# 开放SSH端口（2222，自定义端口），仅允许内网192.168.1.0/24网段访问 ``firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port protocol="tcp" port="2222" accept' --permanent ``# 开放HTTP（80）、HTTPS（443）端口，允许所有IP访问（对外提供服务） ``firewall-cmd --add-port=80/tcp --permanent ``firewall-cmd --add-port=443/tcp --permanent ``# 开放MySQL端口（3306），仅允许指定IP（192.168.1.10）访问 ``firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.1.10" port protocol="tcp" port="3306" accept' --permanent ``# 3. 禁止所有不必要的协议和端口访问 ``firewall-cmd --add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" reject' --permanent # 禁止所有外网IP访问未开放端口 ``# 4. 重启防火墙生效 ``firewall-cmd --reload
关闭不必要的服务和端口：查看服务器上未使用的服务和端口，关闭并禁止开机自启，减少攻击面： # 查看所有运行的服务 ``systemctl list-unit-files --type=service --state=enabled ``# 关闭不必要的服务（如ftp、telnet、rpcbind等） ``systemctl stop ftp ``systemctl disable ftp ``# 查看所有监听端口，关闭未使用的端口（通过关闭对应服务实现） ``ss -tuln
修改默认端口（避免暴力破解）：将SSH、MySQL等核心服务的默认端口改为自定义端口（1024-65535之间），避免被扫描工具盯上：
1. SSH默认端口22→2222（参考第二章2.1.2节配置）；
2. MySQL默认端口3306→33060（修改my.cnf配置文件，重启MySQL服务）；
3. Redis默认端口6379→63790（修改redis.conf配置文件，重启Redis服务）。

3.3.2 进阶加固：防范常见网络攻击

针对生产环境中高频的网络攻击，给出具体的防范措施，结合工具和配置，实现精准防护。

3.3.2.1 防范SSH暴力破解（最常见攻击）

SSH暴力破解是最常见的网络攻击，攻击者通过穷举用户名和密码，尝试登录服务器，一旦成功，会获取服务器控制权，防范措施如下：

强制使用密钥登录，禁止密码登录（核心，参考第二章2.1.2节配置）：修改sshd_config配置文件，禁止密码登录，仅允许密钥登录，从根本上杜绝暴力破解： vim /etc/ssh/sshd_config ``# 修改以下配置 ``PermitPasswordLogin no # 禁止密码登录 ``PubkeyAuthentication yes # 开启密钥登录 ``# 重启SSH服务生效 ``systemctl restart sshd
限制SSH登录频率（防止穷举）：使用pam_tally2模块，限制单个IP的SSH登录失败次数，超过次数则锁定IP： # 1. 编辑PAM配置文件 ``vim /etc/pam.d/sshd ``# 添加以下内容（顶部） ``auth required pam_tally2.so deny=5 unlock_time=300 even_deny_root root_unlock_time=1800 ``# 解读： ``# deny=5：单个IP登录失败5次，锁定IP ``# unlock_time=300：普通用户锁定300秒（5分钟） ``# even_deny_root：root用户也受限制 ``# root_unlock_time=1800：root用户锁定1800秒（30分钟） `` ``# 2. 查看锁定状态 ``pam_tally2 -u root # 查看root用户的登录失败次数 ``# 3. 解锁IP（必要时） ``pam_tally2 -u root -r # 解锁root用户的锁定IP
禁止root用户直接登录（参考第二章2.1.2节）：修改sshd_config配置文件，禁止root用户直接登录，通过普通用户登录后，再切换到root用户，提升安全性： vim /etc/ssh/sshd_config ``PermitRootLogin no # 禁止root用户直接登录 ``# 重启SSH服务生效 ``systemctl restart sshd

3.3.2.2 防范DDoS攻击（流量攻击）

DDoS攻击（分布式拒绝服务攻击）通过大量恶意流量，占用服务器带宽和资源，导致服务器无法正常提供服务，常见类型有TCP洪水、UDP洪水，防范措施如下：

开启防火墙流量限制：通过firewalld限制单IP的并发连接数和流量，拦截恶意流量： # 限制单IP的并发TCP连接数为100（避免TCP洪水） ``firewall-cmd --add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" limit value="100/s" accept' --permanent ``# 限制单IP的UDP流量（避免UDP洪水） ``firewall-cmd --add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" protocol value="udp" limit value="50/s" accept' --permanent ``# 重启防火墙生效 ``firewall-cmd --reload
优化内核参数，提升抗DDoS能力：修改Linux内核参数，增大TCP连接队列、限制SYN包数量，抵御TCP SYN洪水攻击： # 临时优化 ``# 1. 增大TCP半连接队列（默认1024，改为4096） ``sysctl -w net.ipv4.tcp_max_syn_backlog=4096 ``# 2. 限制SYN包发送速率（每秒最多100个） ``sysctl -w net.ipv4.tcp_synack_retries=2 ``sysctl -w net.ipv4.tcp_syn_retries=2 ``# 3. 开启SYN Cookie（抵御SYN洪水） ``sysctl -w net.ipv4.tcp_syncookies=1 `` ``# 永久优化：写入/etc/sysctl.conf ``echo "net.ipv4.tcp_max_syn_backlog=4096" >> /etc/sysctl.conf ``echo "net.ipv4.tcp_synack_retries=2" >> /etc/sysctl.conf ``echo "net.ipv4.tcp_syn_retries=2" >> /etc/sysctl.conf ``echo "net.ipv4.tcp_syncookies=1" >> /etc/sysctl.conf ``sysctl -p
使用专业防护工具（进阶）：若服务器部署在公网，且经常遭受DDoS攻击，可使用专业防护工具，如：
1. 云服务商防护：阿里云、腾讯云等云服务商提供DDoS高防服务，可直接开启，抵御大规模DDoS攻击；
2. 开源工具：如fail2ban、ddosdefend，可自动拦截恶意IP，缓解小规模DDoS攻击。

3.3.2.3 防范ARP欺骗（内网攻击）

ARP欺骗（ARP poisoning）是内网常见攻击，攻击者伪造MAC地址，欺骗内网设备，导致网络中断、流量劫持、数据泄露，防范措施如下：

绑定静态ARP（核心）：在服务器上绑定网关、核心设备（如交换机）的MAC地址，避免被ARP欺骗： # 1. 查看网关的MAC地址（如网关IP为192.168.1.254） ``arp -n | grep 192.168.1.254 ``# 2. 绑定静态ARP（临时生效） ``arp -s 192.168.1.254 00:1c:42:xx:xx:xx # 替换为网关的MAC地址 ``# 3. 永久绑定：编辑/etc/sysconfig/network-scripts/ifcfg-eth0文件，添加以下内容 ``echo "ARPCHECK=yes" >> /etc/sysconfig/network-scripts/ifcfg-eth0 ``# 或创建静态ARP配置文件 ``echo "192.168.1.254 00:1c:42:xx:xx:xx" > /etc/ethers ``arp -f /etc/ethers # 加载静态ARP配置
开启ARP防护功能：
1. 交换机层面：联系网络管理员，在交换机上开启ARP防护（如ARP欺骗检测、ARP绑定），拦截伪造的ARP包；
2. 服务器层面：安装arpwatch工具，监控ARP欺骗行为，及时发现异常： # 安装arpwatch ``yum install arpwatch -y ``# 启动并设置开机自启 ``systemctl start arpwatch ``systemctl enable arpwatch ``# 查看ARP监控日志（发现异常ARP包） ``cat /var/log/messages | grep arpwatch

3.3.3 高级加固：日志审计与应急响应

网络安全加固不仅要“防范”，还要“监控”和“应急”——通过日志审计，及时发现攻击行为；通过应急响应，快速处置安全事件，减少损失。

3.3.3.1 日志审计（实时监控，及时发现异常）

重点监控核心服务日志、防火墙日志、系统日志，及时发现暴力破解、异常登录、攻击行为：

核心日志查看命令： # 1. SSH服务日志（查看登录记录、暴力破解尝试） ``journalctl -u sshd | grep -E "Failed|Accepted" ``# 2. 防火墙日志（查看被拦截的流量、恶意IP） ``journalctl -u firewalld | grep -i "reject" ``# 3. 系统日志（查看系统异常、网络异常） ``cat /var/log/messages | grep -i "error|warn" ``# 4. 网络连接日志（查看异常连接） ``cat /var/log/secure | grep -i "ssh"
日志归档与分析（进阶）：生产环境中，可部署日志分析工具（如ELK、Graylog），将所有服务器的日志集中收集、分析，设置告警规则（如出现多次SSH登录失败，立即发送告警），实现实时监控和异常预警。

3.3.3.2 应急响应（快速处置，减少损失）

当发现网络攻击（如暴力破解、DDoS攻击、ARP欺骗）时，需按以下步骤快速处置，避免攻击扩大：

第一步：定位攻击源：
1. 通过iftop、ss命令，找到恶意IP、异常连接；
2. 通过日志，确认攻击类型（如SSH暴力破解、DDoS攻击）。
第二步：阻断攻击源：
1. 通过防火墙禁止恶意IP访问（firewall-cmd --add-rich-rule='rule family="ipv4" source address="恶意IP" reject' --permanent && firewall-cmd --reload）；
2. 若为DDoS攻击，临时关闭受攻击的服务，或切换到备用服务器，缓解攻击压力。
第三步：修复漏洞：
1. 若为SSH暴力破解，检查SSH配置，确保密钥登录开启、密码复杂度足够；
2. 若为ARP欺骗，检查静态ARP绑定，开启ARP防护；
3. 更新服务器系统和软件，修复已知安全漏洞（yum update -y）。
第四步：恢复服务与复盘：
1. 确认攻击被阻断后，恢复受影响的服务（systemctl start 服务名）；
2. 复盘攻击原因，优化安全配置（如增加防火墙规则、加强日志监控），避免再次遭受攻击。

3.4 本章总结

本章聚焦网络运维的进阶内容，核心围绕“性能优化”和“安全加固”两大核心，实现从“能排查故障”到“能优化性能、能防范攻击”的提升，贴合生产环境的进阶运维需求。

核心要点回顾：

性能监控：掌握iftop、iperf3、mtr、ss等工具，精准定位延迟、丢包、带宽、连接等性能瓶颈；
性能优化：针对延迟、丢包、带宽不足、连接泄露四大问题，给出可直接落地的优化方案，重点优化DNS、网卡、TCP协议、路由配置；
安全加固：遵循“最小权限”原则，从端口控制、攻击防范、日志审计、应急响应四个维度，防范SSH暴力破解、DDoS攻击、ARP欺骗等常见攻击；
实操核心：所有命令、配置均贴合生产环境，可直接套用，同时注重“备份配置、谨慎操作”，避免优化、加固过程中导致服务中断。

posted @ 2026-03-28 19:17 kyle_7Qc 阅读(97) 评论(0) 收藏举报

刷新页面返回顶部

kyle-7Qc