Cloudflare Boom!
原来这 ❌ 可以出现在中间的哇

#ops
CF验尸报告：

省流：
1. ClickHouse 的权限改动导致非预期的 Bot Management 配置文件增大。
2. Cloudflare 模块因为性能原因是预分配内存的，所以在读到过大的配置文件时……
3. 因为是自己生成的配置文件，所以自然而然的使用了 .unwrap() ，也就自然而然地 panic 了。（群友：无视风险，继续解包）
4. 因为这个 ClickHouse 的改动是逐步部署的，所以大家看到了喜闻乐见的仰卧起坐情况。
5. 部署修复之后，一大堆人同时试着登录以及默认的重试也降低了服务可用性。

CF 打算做的增强：
1. 对自己生成的配置文件也按照用户输入进行读取；
2. 提供全局开关来控制特性启用；
3. Coredumps和其他错误报告不再干死整个系统；
4. 重新检查所有代理模块的失效模型。

编者点评：
这个模块为啥不能是 fail-open 的？
这种更改导致出问题应该是一眼丁真啊，集成测试没看到？
https://blog.cloudflare.com/18-november-2025-outage/

#转发 #WTF

https://github.com/donlon/cloudflare-error-page

笑死，有人做了Cloudflare错误(?)页面生成器

最近写 Linux 201 的时候把 netfilter 这块搞清楚了，然后发现 Wikipedia 这张著名的流程图居然把这两个节点画反了

尽管 table 名字都叫 nat，实际上 OUTPUT / PREROUTING 的类型是 DNAT，而 INPUT / POSTROUTING 的类型是 SNAT，可以看到优先级是 DNAT → FILTER → SNAT，所以在 INPUT 链中，nat 位于 filter 后面

亲自指挥、亲自画图（

写到现在快把我自己搞晕了（
https://201.ustclug.org/ops/network/firewall/

现在怀疑这里也画反了，如果 reroute check 指的是 ip_route_me_harder / ip6_route_me_harder 的话，它应该发生在 mangle/OUTPUT 和 nat/OUTPUT 后面各一次

不严谨地实验了一下，好像它是对的，我可能看错代码片段了

结论：reroute check 在 mangle 和 nat 后面各发生一次是正确的，但 reroute 的结果并不会用于后续的 iptables 匹配（-o 参数仍然匹配最开始的 routing decision 确定的 oif）

草，原来如此：
ip_route_me_harder 改的是 skb->_skb_refdst（用于最终执行路由）
但匹配时用的是 (struct nf_hook_state*) state->out
所以能同时观测到：
- 数据包的路由结果在 mangle/nat 后面各变了一次（经过 ip_route_me_harder 之后）
- 数据包在 filter 表中仍然匹配上了原始的 oif

草，我机器 DNS 挂了一个小时了，刚才实验时加的 ip rule 和 iptables 忘记删了

cd ~/iptables
git checkout -f HEAD
./apply.sh

完工

虽然只是一个不到 800 字的 admonition，却有 6 个 code reference，写着也十分费劲（因为要时不时回去看代码避免写错）

https://201.ustclug.org/ops/network/firewall/#netfilter-chains

也写上了

重大勘误：没有 OUTPUT 直接到 INPUT 的路径，而是先 POSTROUTING 到 lo 出，再从 lo 进到 PREROUTING
晚上更新图片（（（

感谢评论区指出

我发现很多工程师可能不知道 linux 并没有 local -> local 这条网络链路，当我们 curl localhost:8000 的时候本质是走了一次 outbound 链路，然后被 lo 导回来，变成一次 inbound 链路。

所以熟悉 nf 立刻就知道一个 curl localhost 会走哪些 chains 了：
1. outbound: OUTPUT + POSTROUTING
2. inbound: PREROUTING + INPUT

这就是为什么 “网上最容易找到的 iptables 各 table 各 chain 关系的图，怎么都像是画图的人根本不知道还可以同一台机器内 process -> process 一样，只画了 interface -> process, interface -> interface, process -> interface，导致看不出 process -> process 会经过哪些 chain”。

如果自己用过 AF_PACKET + SOCK_RAW 模拟 tcpdump 抓包，会发现 lo 上会抓到双重流量，这就是因为一次 egress 一次 ingress （tcpdump 本身处理得很好所以你看不到 lo 的双重流量）

如果用 pwru 也能看到 lo 上的 rx 路径的软中断，是一次完整的收包链路。

所以，local -> local 的流量，本质是一次 tx + 一次 rx。

201 改了