post: 两个「网络错误」补记更新(清理已完成+reload 验证)
This commit is contained in:
@@ -100,7 +100,13 @@ categories:
|
|||||||
> **"修了"不等于"修干净"。** 判据不是"我执行了删除命令",而是
|
> **"修了"不等于"修干净"。** 判据不是"我执行了删除命令",而是
|
||||||
> **① 内核里还有没有 ② 持久化文件里还有没有 ③ 守卫本身在不在跑。**
|
> **① 内核里还有没有 ② 持久化文件里还有没有 ③ 守卫本身在不在跑。**
|
||||||
|
|
||||||
三条缺一条,就等于没修。现在已经把 cron 补上了,清理动作单独排期(会解开约 60 万个 IP 的封禁,需要单独确认)。
|
三条缺一条,就等于没修。现在已经把 cron 补上了,清理也在当晚完成:
|
||||||
|
|
||||||
|
- 内核 2366 条 /24 → **0**
|
||||||
|
- 持久化文件 4732 行 → **0**
|
||||||
|
- 单 IP 封禁 212 条 + 所有放行规则**完整保留**
|
||||||
|
- 最后做了一步以前从没做过的验证:**主动执行一次 `ufw reload`,确认规则没有复活**(这一步正是上次失败的根因)
|
||||||
|
- 守卫复跑:🟢 正常;SSH 与外网服务全部正常
|
||||||
|
|
||||||
**一个小时后,我又发现守卫的判定是对的、清理动作是对的——只是"谁来做、什么时候做"没人管。** 这大概是自动化最常见的死法:**组件都造好了,就是没插电。**
|
**一个小时后,我又发现守卫的判定是对的、清理动作是对的——只是"谁来做、什么时候做"没人管。** 这大概是自动化最常见的死法:**组件都造好了,就是没插电。**
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user