Skip to content

Commit 6a6a713

Browse files
committed
新增DNS问题导致网络瘫痪
1 parent ebaa818 commit 6a6a713

2 files changed

Lines changed: 85 additions & 0 deletions

File tree

docs/.vitepress/config.mts

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -62,6 +62,10 @@ export default defineConfig({
6262
{
6363
text: '突破限制:用 Termux 和 rsync 实现 Android 文件的真正增量备份',
6464
link: '/life/termux_rsync'
65+
},
66+
{
67+
text: '一次家庭网络故障排查:DNS环路导致的连接数爆表',
68+
link: '/life/dns_question'
6569
}
6670
]
6771
},

docs/life/dns_question.md

Lines changed: 81 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,81 @@
1+
# 一次家庭网络故障排查:DNS 环路导致的连接数爆表
2+
3+
> 一次看似复杂的网络故障,最终发现竟是一个配置上的小疏忽。
4+
5+
## 问题初现
6+
7+
家里的网络最近变得异常不稳定,AP 路由器频繁亮起红灯,设备断连的情况时有发生。作为一名对网络略懂一二的技术爱好者,我决定亲自排查这个问题。
8+
9+
## 逐步排查
10+
11+
### 第一阶段:基础排查
12+
13+
首先,我怀疑是 AP 路由器本身出了问题。于是我用有线连接电脑,直接 ping 主路由的 IP 地址:
14+
15+
```
16+
ping 192.168.1.1
17+
```
18+
19+
结果令人意外——即使直连主路由,仍然出现丢包现象。这排除了 AP 路由器故障的可能性。
20+
21+
### 第二阶段:深入主路由
22+
23+
我将电脑直接连接到主路由器,跳过了所有中间设备,但问题依旧。这让我意识到问题可能出在主路由器本身。
24+
25+
登录主路由器管理界面,查看系统日志,发现了一条关键错误信息:
26+
27+
```
28+
kernel: nf_conntrack: table full (16384), dropping packet
29+
```
30+
31+
这条错误表明连接跟踪表已经满了(共 16384 个条目),导致新的网络连接被丢弃。
32+
33+
### 第三阶段:初步判断与应对
34+
35+
我最初怀疑是遭受了网络攻击,立即开启了主路由器的 SYN Flood 和 DDoS 防护功能。然而,问题并没有解决,错误日志仍在不断出现。
36+
37+
### 第四阶段:实时监控
38+
39+
我决定蹲守下一次连接数激增的时刻,查看到底是什么连接占用了这么多资源。当连接数再次飙升时,我惊讶地发现——大量的连接都是 DNS 查询。
40+
41+
> 主要是主路由配置的 DNS2、DNS3 的公共 DNS
42+
43+
这让我想到了家里的旁路游(旁路由)设备,它负责运行 SmartDNS,为全家提供 DNS 解析服务。
44+
45+
### 第五阶段:真相大白
46+
47+
登录旁路游查看,果然发现了大量的 DNS 连接。尝试重启旁路游后,网络暂时恢复了正常。
48+
49+
但当我停止 SmartDNS 服务时,主路由器的连接数立即飙升。这一现象让我恍然大悟——可能存在 DNS 环路!
50+
51+
经过仔细检查,终于发现了问题所在:
52+
53+
- 旁路游的网络接口 DNS 设置指向了主路由器
54+
- 而主路由器的 DNS1 设置又指向了旁路游
55+
56+
## 问题分析
57+
58+
这就形成了一个 DNS 解析环路:
59+
60+
1. 设备向主路游发起 DNS 查询
61+
2. 主路游将查询转发给 DNS1 旁路由,但是此时旁路由 SmartDNS 已经假死了,DNS 查询经过网络接口又转发到主路由
62+
3. 主路由器又将查询发回旁路游
63+
4. 如此循环,导致连接数不断累积
64+
5. 而主路由收不到 DNS1 的请求反馈,连接超时后将请求转发给 DNS2 或者 DNS3
65+
66+
最终,连接跟踪表被这些循环的 DNS 查询占满,无法处理正常网络连接,导致了全网的频繁断线。
67+
68+
## 解决方案
69+
70+
修复方法很简单:将旁路由器的 DNS 设置更改为公共 DNS 服务器(如 114.114.114.114 或 8.8.8.8),即使 SmartDNS 掉线后也能正常反馈 DNS 查询,打破这个循环。
71+
72+
## 经验总结
73+
74+
这次排查经历让我深刻体会到:
75+
76+
1. **不要忽视基础配置**:看似简单的配置错误可能引发严重问题
77+
2. **日志是最好的朋友**:系统日志往往包含了解决问题的关键线索
78+
3. **排查要有方法论**:从简单到复杂,一步步缩小问题范围
79+
4. **理解系统工作原理**:了解 DNS、NAT 和连接跟踪的基本原理对排查网络问题至关重要
80+
81+
网络问题排查就像侦探破案,需要耐心、细心和对技术细节的关注。这次经历虽然花费了不少时间,但解决问题的成就感和对家庭网络更深入的理解,让一切努力都变得值得。

0 commit comments

Comments
 (0)