有什么奇怪的，防火墙识别流量是内网还是外网主动发起的访问来做策略是基本要求吧，像移动的 4G/5G 核心网 IPv6 地址就是全部屏蔽来自外网的主动访问（包括 Ping ）

看了文件，感觉最离谱的是移动和联通拿的 ipv6 /32 段的数量加起来还没教育网拿的多，怪不得家宽前缀不按标准的/56 分配而要分配/60 甚至/64 了

@7897894 貌似 deb.debian.org 用的是 fastly 的 CDN 吧？除了中国大陆和非洲应该不存在访问慢的问题自然基本不会有人去做镜像
fastly 的 pop 在全球覆盖范围： https://www.jsdelivr.com/network
同时国内镜像源建议用北京外国语大学的镜像（就是清华 TUNA 协会维护）来缓解清华源的压力 https://mirrors.bfsu.edu.cn/help/debian/

封号倒不至于，只是会限速到基本不可用的状态，大佬 @XIU2 就因为搭建测速服务遇到过
https://github.com/XIU2/CloudflareSpeedTest/issues/168

广东移动是 7 天强制下线重拨，IPv4 和 IPv6 都会变但都稳定在一个段内

@szzys 怪不得广东移动 IPv4 还有一大堆单向绕路的段反而先把 IPv6 的广州双向出口调通，看来目前的策略都是优先保障 IPv6 了

最关键是里面有没有涉及到 AS9808 （中国移动内地段）？如果涉及到了搞出这些东西不也很正常，毕竟看看联通电信的策略只要不买亚洲区的天价 transit 涉及中国大陆的流量统统绕美

@xusp onedns 应该是限制了白名单域名只对国内域名开启 ECS ，且 DNS 缓存策略存在严重问题居然是按来源 IP 缓存而不是按提交的 ECS 缓存，基本可以划进不支持的范畴

dig @117.50.11.11 o-o.myaddr.l.google.com txt +subnet=111.28.0.0/24
;; BADCOOKIE, retrying.

; <<>> DiG 9.16.23-RH <<>> @117.50.11.11 o-o.myaddr.l.google.com txt +subnet=111.28.0.0/24
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40138
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 32ab13ed74df629e0100000064df3c805b5e806dc81e6943 (good)
; CLIENT-SUBNET: 111.28.0.0/24/0
;; QUESTION SECTION:
;o-o.myaddr.l.google.com. IN TXT

;; ANSWER SECTION:
o-o.myaddr.l.google.com. 40 IN TXT "117.50.11.11"

;; Query time: 43 msec
;; SERVER: 117.50.11.11#53(117.50.11.11)
解析谷歌域名不支持 ECS

今天一测大部分 cloudflare IPv6 切回美西，不过无所谓只要还有到香港的段就可以”优化“
同时 WARP 已恢复

好消息：广东移动到 cloudflare IPv6 都直连香港了延迟 10ms+速度大概有 20-30M （普通家宽）好过到美西经常只有 10M 以下
坏消息：IPv6 的 WARP 被彻底封禁（疑似 2606:4700:d0::/48 、2606:4700:d1::/48 这两个段的全部 UDP 端口被封，TCP 正常)

@zenghx 不是说了只要后端递归服务器在国内就不可能没有污染，但只会有墙的污染不会有运营商加的料（即不会像其他帖子里运营商 DNS 把 cloudflare 和 github 解析到 127.0.0.1 的情况），海外情况我暂时没能力测试

@JAYDEN96 移动现在貌似只会在多次请求失败的情况下才会劫持 DNS 应答”保障用户体验“，而且 ipv6 完全没有劫持情况，加密 DNS 出现之后再搞大范围劫持也没什么意义了

@872517414 dnspod 不是无法正确返回而是它不会直接向权威提交 ipv6 的 ECS 而是转为提交和 IPv6 同运营商同地区的 ipv4 地址，这样可以减小缓存 IP 段的数量节约成本

阿里只是在三大运营商网内的后端不支持 ECS （即不会向权威提交 ECS 地址解析准确度全靠后端在国内覆盖地区的数量）但入口是支持的，假如你提交的 IP 不属于三大运营商阿里就会转发到支持 ECS 后端进行查询

dig @2400:3200::1 txt o-o.myaddr.l.google.com +subnet=101.6.6.0/24

; <<>> DiG 9.16.23-RH <<>> @2400:3200::1 txt o-o.myaddr.l.google.com +subnet=101.6.6.0/24
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11909
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1408
; CLIENT-SUBNET: 101.6.6.0/24/24
;; QUESTION SECTION:
;o-o.myaddr.l.google.com. IN TXT

;; ANSWER SECTION:
o-o.myaddr.l.google.com. 60 IN TXT "47.106.126.96"
o-o.myaddr.l.google.com. 60 IN TXT "edns0-client-subnet 42.83.199.0/25"

;; Query time: 197 msec
;; SERVER: 2400:3200::1#53(2400:3200::1)

百度和阿里类似但它的后端在任何情况都不会向权威提交 ECS 这点确实考虑的不够好，但百度连教育网都有覆盖后端比阿里覆盖还广人家确实这样做有底气
dig @180.76.76.76 txt o-o.myaddr.l.google.com +subnet=101.6.6.0/24

; <<>> DiG 9.16.23-RH <<>> @180.76.76.76 txt o-o.myaddr.l.google.com +subnet=101.6.6.0/24
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20126
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;o-o.myaddr.l.google.com. IN TXT

;; ANSWER SECTION:
o-o.myaddr.l.google.com. 190 IN TXT "222.199.191.4"

;; Query time: 108 msec
;; SERVER: 180.76.76.76#53(180.76.76.76)

国内彻底不支持 ECS 的公共 dns 有 114 、cnnic dns 、onedns 等，支持但有重大问题的是 360 （学习阿里和百度的做法但它后端递归服务器少且不向权威提交 ECS 导致会出现解析跨省结果，且不支持 IPv6 ECS 如果提交不管哪里的 IPv6 都是解析至河南）

@yyzh 国内的互联网公司也就只有他们两家提供，国内的 NTP 主力还是靠教育网及海外服务器

登录页面就有 https 了，但之前建行还在用 RSA 这种没有前向保密的密钥交换方式我也是服了，刚刚去看了一下终于用上了 ECDHE 这个安全密钥交换方式了，但就是不用 X25519 椭圆曲线还在用 P256 ，不知道这条曲线疑似有 NSA 后门？

是的，Linux 默认都不开启隐私地址默认只使用 EUI64 地址，如需开启隐私地址（ RFC4941 ）可以根据发行版查询对应的开启方式，一般都需要修改配置文件
ROS 的 IPv6 防火墙必须完整匹配，但可以根据 @neroxps 提供的脚本自动更新前缀达到匹配完整地址的目的 https://github.com/neroxps/RouterOS-Script/blob/master/update_wan_ip_to_firwall_address_list.rsc

更新，gcore.jsdelivr.net 解析出的 IP 已变更为指向 CloudFlare ，看来是真的停止合作了

dig @8.8.4.4 aaaa gcore.jsdelivr.net

; <<>> DiG 9.16.27-Debian <<>> @8.8.4.4 aaaa gcore.jsdelivr.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11502
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;gcore.jsdelivr.net. IN AAAA

;; ANSWER SECTION:
gcore.jsdelivr.net. 3340 IN CNAME gcore.jsdelivr.net.cdn.cloudflare.net.
gcore.jsdelivr.net.cdn.cloudflare.net. 300 IN AAAA 2606:4700::6810:5914
gcore.jsdelivr.net.cdn.cloudflare.net. 300 IN AAAA 2606:4700::6810:5614
gcore.jsdelivr.net.cdn.cloudflare.net. 300 IN AAAA 2606:4700::6810:5714
gcore.jsdelivr.net.cdn.cloudflare.net. 300 IN AAAA 2606:4700::6810:5514
gcore.jsdelivr.net.cdn.cloudflare.net. 300 IN AAAA 2606:4700::6810:5814

;; Query time: 72 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Thu Jul 06 16:47:56 CST 2023
;; MSG SIZE rcvd: 235

@aa51513 又不用非常精确，只要把移动 IDC 的 IP 段全放进去把家宽和其他运营商的 IP 段排除不就行了，普通人拿不到这些 IP 段不就没法利用免流漏洞了

安装 chrome 或者更新 webview 都要先装一个对应版本的 trichrome library 静态库再安装本体才能正常使用 64 位（ apkmirror 上面每个版本都有一套静态库+本体 aab 安装包，aab 可以用 SAI 安装），否则只能用 32 位的 chrome/webview ，如果嫌麻烦那只能用 play 安装，但 8G 内存以下的设备 play 也只会安装 32 位版本