一次网络故障排查实录：为什么我的服务器之间突然不能互访了？

本文记录了一次典型的网络故障排查过程，涉及跨网段通信、路由配置、网关转发等网络基础知识。希望通过这次真实的故障排查，帮助开发同学理解网络通信的基本原理，掌握基本的网络问题排查方法。

---

1. 问题背景：三台服务器的奇怪通信问题

最近在工作中遇到一个奇怪的问题：我们有三台服务器，它们之间的通信出现了不一致的情况。具体现象如下：

通信方向	结果	开发人员的困惑
Windows笔记本 → Linux服务器A	✅ 正常	“服务器A明明好好的啊”
Windows笔记本 → Linux服务器B	✅ 正常	“网络看起来没问题”
Linux服务器B → Linux服务器A	❌ 完全不通	“这就很迷了…”

物理拓扑示意图：

┌─────────────────┐          ┌──────────────────┐          ┌──────────────────┐
│  Windows 笔记本 │          │   三层交换机/路由器  │          │                   │
│  10.0.80.80     │          │  (网关 10.0.80.1    │          │  Linux Server B    │
│  (你的日常办公机) │◄────────►│   兼 10.1.90.1)    │◄────────►│  10.1.90.129       │
│                 │ 同网段    │                    │ 跨网段    │  (另一台服务器)    │
└────────┬────────┘          └──────────────────┘          └──────────────────┘
         │                                                        │
         │  同网段（同一VLAN）                                      │
         ▼                                                        │
┌──────────────────┐                                              │
│  Linux Server A   │←─────────────────────────────────────────────┘
│  10.0.80.169     │  （两台Linux之间的访问：不通！）
│  (目标服务器)     │
└──────────────────┘

IP地址分配：

• Windows笔记本：10.0.80.80
• Linux服务器A：10.0.80.169
• Linux服务器B：10.1.90.129
• 网关1：10.0.80.1
• 网关2：10.1.90.1

---

2. 基础知识：简单了解网络通信原理

在开始排查之前，我们先了解几个关键概念：

2.1 什么是子网和网关？

想象一下办公室的场景：

• 子网 = 同一个办公室
• 网关 = 办公室的门（连接外部世界）

同一子网内的通信：就像同一个办公室的同事，可以直接说话，不需要走出办公室。

不同子网间的通信：就像不同办公室的同事，必须走到门口（网关），由网关帮你转发到另一个办公室。

2.2 路由表：网络的"导航地图"

每台计算机都有一个"导航地图"，告诉它：

• 要去的地方是否在同一个办公室（子网）
• 如果要出去，应该走哪个门（网关）

查看路由表的命令：

# Linux/Mac
ip route

# Windows
route print

2.3 Ping命令的两种错误

1. Destination Host Unreachable（目标主机不可达）

   • 含义：“我根本不知道这条路怎么走”
   • 原因：路由表里没有去目标地址的路由

2. 100% 丢包（无响应）

   • 含义：“我的消息发出去了，但对方没回”
   • 原因：对方收到了，但回不来；或者对方屏蔽了消息

---

3. 故障排查过程

3.1 第一步：建立通信矩阵，找出规律

首先，我在三台机器上互相ping，建立了完整的通信矩阵：

                    到 Windows     到服务器B     到服务器A
Windows(10.0.80.80)    —            ✅ 通         ✅ 通
服务器B(10.1.90.129)  ✅ 通           —          ❌ 不通
服务器A(10.0.80.169)  ✅ 通         ?            —

关键发现：

• 所有涉及Windows的通信都正常
• 服务器B → 服务器A 单向不通
• 服务器A和Windows在同一网段（10.0.80.0/24）

3.2 第二步：用tracert验证路径

在Windows上执行：

tracert -d 10.0.80.169

结果：

  1    <1 ms   <1 ms   <1 ms   10.0.80.169

重要结论：只有1跳，说明Windows和服务器A在同一个子网，通信不经过网关。

3.3 第三步：检查服务器B的路由决策

在服务器B（10.1.90.129）上执行：

# 查询"如何去服务器A"
ip route get 10.0.80.169

输出：

10.0.80.169 via 10.1.90.1 dev br0 src 10.1.90.129

解读：

• via 10.1.90.1：通过网关10.1.90.1转发
• dev br0：从br0网卡发出
• 说明去程路由是正确的，包能离开服务器B

3.4 第四步：检查服务器A的路由表

在服务器A（10.0.80.169）上执行：

ip route

关键输出：

default via 192.168.1.1 dev eth1   (linkdown)
10.0.80.0/24 dev eth2

发现问题了！

• 默认网关指向192.168.1.1，但eth1网卡是linkdown（没插网线/没启用）
• 这意味着：服务器A能收到包，但回包时找不到路

3.5 第五步：验证推理

在服务器A上抓包：

tcpdump -i eth2 host 10.1.90.129

然后从服务器B ping 服务器A，观察到：

• 有来自10.1.90.129的请求包
• 没有回包

至此，问题定位完成：服务器A的默认网关配置错误，导致它能收包但不能回包。

---

4. 问题根源与解决方案

4.1 根本原因分析

问题1：服务器B上有一条错误的路由配置

# 错误配置：让服务器B认为10.0.80.x是直连网段
10.0.80.1 dev br0 scope link
# 但实际上服务器B的IP是10.1.90.129，不在10.0.80.0/24网段

问题2：服务器A的默认网关不可用

# 错误配置：默认网关指向一个不存在的接口
default via 192.168.1.1 dev eth1   # eth1是linkdown状态

4.2 解决方案

在服务器B（10.1.90.129）上：

# 1. 删除错误路由
ip route del 10.0.80.1 dev br0

# 2. 添加正确路由：去10.0.80.0/24网段走网关10.1.90.1
ip route add 10.0.80.0/24 via 10.1.90.1 dev br0

在服务器A（10.0.80.169）上：

# 添加回程路由：回10.1.90.0/24网段走网关10.0.80.1
ip route add 10.1.90.0/24 via 10.0.80.1 dev eth2

4.3 永久生效配置

对于Linux服务器，临时配置重启会失效，需要写入配置文件：

CentOS/RHEL系统：

# 服务器B的永久配置
echo "10.0.80.0/24 via 10.1.90.1" >> /etc/sysconfig/network-scripts/route-br0

# 服务器A的永久配置
echo "10.1.90.0/24 via 10.0.80.1" >> /etc/sysconfig/network-scripts/route-eth2

---

5. 网络排查速查手册

5.1 常用命令总结

用途	Linux命令	Windows命令
查看路由表	ip route	route print
查询到某IP的路由	ip route get <IP>	tracert -d <IP>
测试连通性	ping <IP>	ping <IP>
查看ARP表	ip neigh	arp -a
抓包分析	tcpdump -i <网卡> host <IP>	Wireshark

5.2 网络问题排查流程图

5.3 给开发同学的建议

1. 不要假设网络是通的：即使你能访问，不代表服务之间能访问
2. 理解"有去有回"：网络通信是双向的，去程通不代表回程通
3. 善用tracert/traceroute：快速了解数据包走的路径
4. 关注默认网关：这是跨网段通信的关键
5. 同网段 vs 跨网段：这是理解网络问题的关键分界线

---

6. 扩展思考：容器和云时代的网络

这次排查的是传统物理服务器的网络问题，但在容器化和云原生时代，网络模型变得更加复杂：

• Docker网络：bridge、host、overlay等网络模式
• Kubernetes网络：Pod网络、Service网络、CNI插件
• 云厂商VPC：虚拟私有云、子网、路由表、安全组

但核心原理不变：无论是物理机、虚拟机还是容器，网络通信都要解决"数据包从哪里来，到哪里去"的问题。理解基础的路由原理，是排查一切网络问题的基石。

---

7. 总结

这次网络故障排查教会我们几个重要道理：

1. 网络是分层的：应用层不通，先看看网络层通不通
2. 通信是双向的：A能访问B ≠ B能访问A
3. 路由表是地图：错误的地图导致去不了目的地
4. 默认网关是关键：跨网段通信的必经之路
5. 同网段通信是捷径：不经过网关，速度更快

作为开发人员，我们不需要成为网络专家，但掌握这些基础知识，能在出现网络问题时：

• 快速定位是应用问题还是网络问题
• 提供有价值的排查信息给运维同事
• 避免在错误的方向上浪费时间

记住这个简单的排查口诀：“先ping后路由，有去要有回”，能解决80%的网络连通性问题。

---