4. 网络层故障排查：IP、子网掩码、网关与路由
网络层，说白了就是数据包在互联网上找路的那一层。IP地址是门牌号，子网掩码划片区，默认网关是出小区的路口，路由表则是整个导航地图。这一层出问题，最常见的表现就是——能ping通自己，但死活ping不通隔壁工位的同事。
我处理过的网络故障里，大概有六成都能归到网络层配置错误。今天咱们就把这些点挨个捋一遍。
4.1 IP地址配置：别小看这个门牌号
IP地址配错了，网络肯定不通。但有些错误藏得很深。
核心原则：同一广播域内的设备，IP地址必须在同一网段，且不能冲突。
我遇到过最坑的一次：某公司新来的运维把服务器IP配成了网关地址，结果全网断断续续掉线。查了整整两小时，最后发现是IP冲突。嗯，从那以后我养成了一个习惯——配IP之前先扫一遍ARP表。
排查IP配置问题的常用命令：
# Windows
ipconfig /all
# Linux
ip addr show
# 或
ifconfig -a检查要点：
- IP地址是否在预期范围内
- 是否与同网段其他设备冲突（用arp -a看）
- DHCP获取的地址是否过期（ipconfig /renew试试）
4.2 子网掩码：划片区的尺子
子网掩码决定了你的设备认为“哪些IP是邻居，哪些需要找网关”。掩码错了，设备会误判通信范围。
举个例子：
设备A：192.168.1.10/24（掩码255.255.255.0）
设备B：192.168.2.20/24（掩码255.255.255.0）这两个设备不在同一网段，通信必须经过网关。但如果把设备A的掩码改成/16（255.255.0.0），它就会认为设备B是邻居，直接发ARP请求——结果当然不通。
注意：子网掩码不一致会导致“单向可达”的诡异现象。A能ping通B，B却ping不通A。为什么？因为A认为B在本地，B认为A在远端，B的回应包会发给网关，网关如果没配回程路由，包就丢了。
快速计算网段的技巧：
IP地址：192.168.1.100
掩码：255.255.255.0（/24）
网络地址：192.168.1.0
广播地址：192.168.1.255
可用主机：192.168.1.1 - 192.168.1.254我个人习惯用 ipcalc 工具（Linux）或在线计算器，但手算也得会——面试常考。
4.3 默认网关：出小区的唯一路口
默认网关是设备访问非本地网络时的下一跳。配错了，内网能通，外网全挂。
检查默认网关的命令：
# Windows
route print -4 | findstr "0.0.0.0"
# Linux
ip route show default
# 或
route -n | grep "^0.0.0.0"常见故障场景：
- 网关地址配错：比如网关是192.168.1.1，你配成了192.168.1.254——而这个地址没人用，包就丢了
- 网关没配：设备只有IP和掩码，没有默认网关，只能和同网段通信
- 网关设备挂了：ping网关不通，那肯定出不去
小技巧：先ping网关，通了再ping外网。如果网关通但外网不通，问题可能在路由或DNS上。
4.4 路由表分析：数据包的导航图
路由表决定了数据包怎么走。每台设备（包括PC）都有路由表，只是PC的很简单——要么本地直连，要么走默认网关。
查看路由表：
# Windows
route print -4
# Linux
ip route show
# 或
netstat -rn路由匹配原则：最长前缀匹配。说白了，就是找最精确的那条路由。
举个例子：
目标IP：192.168.1.100
路由表中有：
192.168.1.0/24 → 直连
0.0.0.0/0 → 192.168.1.1
匹配结果：走192.168.1.0/24，因为前缀更长（24 > 0）我排查过一个案例：某台服务器能ping通同网段，但访问另一个网段时通时不通。查路由表发现，有一条旧的静态路由指向了错误的下一跳。删掉那条路由后，问题解决。
排查思路：
- 用
traceroute或tracert看数据包走到哪一步断了 - 在每一跳设备上查路由表，看有没有回程路由
- 检查路由的度量值（metric），有时候路由存在但优先级低
4.5 ICMP协议：Ping与Traceroute的深度使用
ICMP是网络层的“信使”，负责传递错误信息和诊断结果。Ping和Traceroute都是基于ICMP的工具。
4.5.1 Ping：不只是测通断
很多人用ping就是敲一下看通不通。其实ping能告诉你很多信息。
# 基本用法
ping 8.8.8.8
# 持续ping（Linux默认，Windows加 -t）
ping -t 192.168.1.1
# 指定包大小（测试MTU问题）
ping -l 1472 192.168.1.1
# 指定TTL（测试路径跳数）
ping -i 5 8.8.8.8解读ping结果：
- Request timed out：没收到回应。可能是目标不可达，也可能是防火墙拦截了ICMP
- Destination Host Unreachable：本地路由表里没有到目标的路径
- TTL expired in transit：数据包超过了最大跳数，说明有路由环路
- Reply from ...: bytes=32 time<1ms TTL=128：正常回应，TTL值可以推断操作系统类型（Windows默认128，Linux默认64）
注意：很多生产环境会禁用ICMP。ping不通不代表网络不通，可能是防火墙策略。这时候要用TCP层面的工具（如telnet、nc）来验证端口连通性。
4.5.2 Traceroute：追踪每一跳
Traceroute利用TTL机制，逐跳探测路径上的每个路由器。
# Windows
tracert 8.8.8.8
# Linux/macOS
traceroute 8.8.8.8输出解读：
1 <1 ms <1 ms <1 ms 192.168.1.1
2 2 ms 2 ms 2 ms 10.0.0.1
3 * * * Request timed out.
4 15 ms 15 ms 15 ms 172.16.0.1
5 20 ms 20 ms 21 ms 8.8.8.8第三跳超时，常见原因：
- 该路由器禁用了ICMP回应
- 有防火墙拦截了TTL超时消息
- 路径上有负载均衡设备
我记得有一次排查跨国访问慢的问题，用traceroute发现数据包绕到了欧洲，明明目标在亚洲。后来发现是BGP路由策略的问题，调整后延迟从300ms降到了80ms。
4.5.3 高级用法：路径MTU发现
用ping配合DF（Don't Fragment）标志，可以探测路径上的MTU值。
# Linux
ping -M do -s 1472 8.8.8.8
# Windows
ping -f -l 1472 8.8.8.8从1472开始，逐步减小包大小，直到能ping通。最终值加上28（IP头+ICMP头）就是路径MTU。
实战经验：VPN连接经常出现“能ping通但打不开网页”的问题，多半是MTU不匹配。把MTU从1500降到1400，问题往往就解决了。
4.6 知识体系总览
下面这张图把网络层故障排查的核心逻辑串起来了：
4.7 实战案例：一次典型的网络层故障排查
最后分享一个我实际处理过的案例，帮你把上面的知识点串起来。
现象：某办公室的电脑能上内网，但打不开外网网站。其他同事正常。
排查过程：
- 查IP配置：
ipconfig /all→ IP、掩码、网关都有，DHCP正常 - ping网关：通，延迟<1ms
- ping外网IP（如114.114.114.114）：不通，显示"Destination Host Unreachable"
- 查路由表：
route print -4→ 发现默认网关的metric值是256（无效），而另一条到10.0.0.0/8的metric是20 - 根因：有人手动添加了一条静态路由，导致默认网关被覆盖
- 修复：删除那条静态路由，
route delete 0.0.0.0然后重新获取DHCP - 验证：ping 114.114.114.114 通了，网页正常打开
经验总结：遇到网络故障，别急着重启。先看配置，再看路由，最后用工具验证。80%的问题都能在十分钟内定位。