 eli
|
37db75413d
|
fix(cdn-list): 换用上游仓库自带的合并版，并补上一直缺失的 Akamai IPv6
两件事，都是之前搞错的。
一、v4 清单的源头找错了处理方式
实际数据源是 SecOps-Institute/Akamai-ASN-and-IPs-List（按 40 个 ASN 从 RADb 拉 BGP
宣告，每小时更新）。内嵌的那份是拿它的 akamai_ip_list.lst 手工合并、且是一两年前的
快照。复核发现：
- 该仓库本来就提供合并好的 akamai_ip_cidr_blocks.lst（235 条，与原始 9462 行
collapse 后完全等价），根本不用自己合；
- 旧快照已漂移：265 段 / 209,106 地址 Akamai 已不再宣告（白绕），
49 段 / 13,504 地址是新宣告的（没绕 → 一直在按 $0.08/GiB 计费）。
换成 235 条后，v4 总数 402 → 269。
二、Akamai 的 IPv6 一直是空的
之前写"没有官方来源所以故意不收"——前提就错了：同一个仓库有 akamai_ipv6_list.lst
（3849 行，未合并，需要自己 collapse 成 183 条）。也就是说在此之前所有走 v6 的
Akamai 边缘流量都没被绕行，一直在按 CDN 计费。现已补上：v6 从 10 条 → 193 条
（CF 7 + Fastly 3 + Akamai 183）。
配套改动：
- 脚本头部写清【怎么更新这份清单】+ CDN_LIST_AUDIT_DATE，超过 180 天打告警；
- 测试断言从"单一区间"改成三层：总数 269±10%、CF 15 条逐条核对、Fastly 抽样；
v6 侧补 Akamai 主段与条数下限，防止再次被删空；
- docs/cdn-list-audit.md 重写，记录依据（GCP 按目的地网络自动判定、Akamai 无官方
公开清单的穷举证据）、20 万地址漂移、以及 5 万条集合的实测无差异。
线上已同步：两台主机渲染结果 md5 一致（c8f16ac8…）；两个 GCP 项目的 egress 拒绝规则
都改成同一份 269 段（原来是 gcoregon 旧 368 段、gcoregon-2 中间版 402 段，两边还不一致）。
真实 Akamai 边缘地址抽验命中：www.akamai.com / www.microsoft.com 的 AAAA 都落在
2600:1400::/24 内。
|
2026-11-08 11:17:55 +08:00 |
|
|
eli
|
bb27fb24dc
|
feat(cdn-list): v4 清单 188 → 402 条，覆盖面上补到 GCP 那份的规模
现网 188 条（CF 15 + Fastly 19 + Akamai/Linode 154）是 2026-09 审计的产物；
GCP 项目里的 egress 拒绝规则用的是更完整的一份（Akamai 368 条）。这次把主机侧
对齐到同一份，两边从此一致——不一致会导致"漏绕（按 CDN 计费）"或"误丢包"。
实测结论（写进 docs/cdn-list-audit.md）：
- nft 是"一个集合一次查找"，netlink 字节码里只有一条 lookup，不是几百条 cmp；
- 集合 188 条 vs 40 条端到端无差异，扩到 50,188 条仍然测不出差异；
- 所以"精简到几十条"没有任何性能收益，只会把无辜地址丢给上游 Oracle。
顺带证伪了两个之前的口头推测：
- GCP 单条防火墙规则没有 256 个 destinationRanges 上限（实测 3000 个也能建）；
- 精确挖掉 Linode 反而使条数从 368 涨到 381（减法切碎片），故不挖。
测试断言从单一区间 [180,200] 换成三层保护：总数 402±10%、Cloudflare 15 条逐条核对、
Fastly 抽样核对——CF/Fastly 是官方权威值，不该漂移；Akamai 是 BGP 派生的浮动值。
两台机器已重跑并验证：CDN 出口走 Oracle，非 CDN 仍走 GCP 自己。
|
2026-11-08 10:38:45 +08:00 |
|