是否可以通过DNS解析记录来识别 REALITY

[xthz]

首先我是网络专业的小小白. 有些理解可能是不对的.

比如 GFW 要查找青岛地区的用户是否使用了 REALITY, 只需记录跨国企业的域名 (比如 apple.com) 在该地区的 DNS 解析出来的所有合法的 Apple 服务器的 IP 地址. 当青岛用户的 REALITY 流量过防火墙时, 如果 SNI 是 apple.com, 就会去 "合法的 DNS 解析记录字典" 里去查找, 如果 REALITY 的 IP 不在合法字典里, 就会风控不合法的 IP.

从 GFW 的角度, 以上做法是否可行 ?

[chika0801]

这样来不可行。原理群友聊天时说过我记不到链接了，你有兴趣来Xray群问其它人交流看法。

[flowerinsnowdh]

第一个是收集不了所有的解析结果，第二个是不排除有人使用 DOH 这种不怕中间人攻击的 DNS 解析方式，第三个是所以要使用冷门的源服务器

当然对于黑盒不要去猜测有没有这个能力，一切宁可信其有

[nursery01]

如果是用dns-ip匹配是不行的，誤報率會很高，雖然100%識別REALITY

如果是用dns-asn匹配誤報率低，但是會漏掉一些REALITY，這種方法能湊合著用

https://github.com/nursery01/GFW-system/tree/main/TLS/passive%20detection

中國的gfw和伊朗的isp不一樣，gfw考慮的是低誤報率，而伊朗考慮的是接近滴水不漏

[nursery01]

第二个是不排除有人使用 DOH 这种不怕中间人攻击的 DNS 解析方式

即使使用了DoH，gfw還是能拿到sni，除非sni是null

[flowerinsnowdh]

第二个是不排除有人使用 DOH 这种不怕中间人攻击的 DNS 解析方式

即使使用了DoH，gfw還是能拿到sni，除非sni是null

GFW 拿到的 SNI 是 DNS 服务器的 SNI，拿不到解析的域名

这样的话倒无所谓，因为网络层明文是 1.1.1.1，SNI 是不是 1.1.1.1 都无所谓了

[nursery01]

第二个是不排除有人使用 DOH 这种不怕中间人攻击的 DNS 解析方式

即使使用了DoH，gfw還是能拿到sni，除非sni是null

GFW 拿到的 SNI 是 DNS 服务器的 SNI，拿不到解析的域名

sni是可以從client hello裡面獲取的，它是明文的，現階段的標準並沒有完全加密sni，包括下一代技術http3

[flowerinsnowdh]

第二个是不排除有人使用 DOH 这种不怕中间人攻击的 DNS 解析方式

即使使用了DoH，gfw還是能拿到sni，除非sni是null

GFW 拿到的 SNI 是 DNS 服务器的 SNI，拿不到解析的域名

sni是可以從client hello裡面獲取的，它是明文的，現階段的標準並沒有完全加密sni，包括下一代技術http3

在 Client Hello 里的是 DNS 服务器的 SNI，而请求解析的域名是在 Body 里的，是完全加密的；GFW 自然知道我是在进行 DNS 解析，然而它也就只知道我在进行 DNS 解析，却不知道具体内容

[flowerinsnowdh]

sni是可以從client hello裡面獲取的，它是明文的，現階段的標準並沒有完全加密sni，包括下一代技術http3

以及 TLS 1.3 其实已经有加密 SNI 技术了，但是没有广泛应用而已

H3 是 HTTP 协议，而非 TLS 协议，加密是由 TLS 进行的，H3 只是强制使用 TLS 而已

扯远了，确实应该考虑地狱般的伊朗防火墙

[nursery01]

第二个是不排除有人使用 DOH 这种不怕中间人攻击的 DNS 解析方式

即使使用了DoH，gfw還是能拿到sni，除非sni是null

GFW 拿到的 SNI 是 DNS 服务器的 SNI，拿不到解析的域名

sni是可以從client hello裡面獲取的，它是明文的，現階段的標準並沒有完全加密sni，包括下一代技術http3

在 Client Hello 里的是 DNS 服务器的 SNI，而请求解析的域名是在 Body 里的，是完全加密的；GFW 自然知道我是在进行 DNS 解析，然而它也就只知道我在进行 DNS 解析，却不知道具体内容

你說的這個技術是DoH-ECH技術，然而上文我說過了，它並沒有被完全加密，我抓過包親手驗證過，並且ECH標準協定裡寫了它發了兩條，有一條是加密的，一條是沒有加密的用於退回，那條退回的請求是包含sni的

你如果想知道自己可以去抓包驗證，"我不信，我不聽，我不管"這種話就不要說了

[flowerinsnowdh]

但是我确实抓过，包括刚刚我也试了一遍

我是将 DNS 解析交给 Xray 来进行的

{
    "dns": {
        "servers": [
            {
                "address": "https://[2606:4700:4700::1111]/dns-query"
            }
        ]
    }

确实没有发现相关 SNI 内容

对于没有自信的内容我其实是不敢直接说出来的

证有不证无，麻烦把抓包信息给我看一下，可能我们聊得不是同一个东西

[nursery01]

但是我确实抓过，包括刚刚我也试了一遍

我是将 DNS 解析交给 Xray 来进行的

{
    "dns": {
        "servers": [
            {
                "address": "https://[2606:4700:4700::1111]/dns-query"
            }
        ]
    }

确实没有发现相关 SNI 内容

对于没有自信的内容我其实是不敢直接说出来的

证有不证无，麻烦把抓包信息给我看一下，可能我们聊得不是同一个东西

你要驗證肯定不是這樣驗證，但是你最初的問題問的是

第二个是不排除有人使用 DOH 这种不怕中间人攻击的 DNS 解析方式

然後我的回答是

即使使用了DoH，gfw還是能拿到sni，除非sni是null

但是你現在的回答是挂了代理你在某一層面沒有截取到sni(如果你是匹配出口REALITY ip截取)，這部分回答可能沒有問題，但是REALITY的sni還是能截取到，它是明文的

你還說了

可能我们聊得不是同一个东西

我看到這裏我終於懂你的意思了，你當初是想說(挂了代理)啓用doh的話，不怕中間人，但是我的回答也是沒有問題的，REALITY的sni還是能拿得到，除非是空sni，因爲這個討論的標題是關於REALITY的識別問題，所以根據標題和你的回答這一層面我當初的回答沒有產生誤解這種情況

你想驗證應該在瀏覽器啓用DoH和ECH，然後打開https://crypto.cloudflare.com/cdn-cgi/trace/來驗證，來驗證DoH-ECH這種技術是否真的加密了sni

我是4月在v2ray社區討論過這個問題，當時我對ECH很自信，認爲有了它以後不挂代理GFW也拿不到sni了，但是後來抓包發現sni還是明文的

[flowerinsnowdh]

但是我确实抓过，包括刚刚我也试了一遍
我是将 DNS 解析交给 Xray 来进行的

{
    "dns": {
        "servers": [
            {
                "address": "https://[2606:4700:4700::1111]/dns-query"
            }
        ]
    }

确实没有发现相关 SNI 内容
对于没有自信的内容我其实是不敢直接说出来的
证有不证无，麻烦把抓包信息给我看一下，可能我们聊得不是同一个东西

你要驗證肯定不是這樣驗證，但是你最初的問題問的是

第二个是不排除有人使用 DOH 这种不怕中间人攻击的 DNS 解析方式

然後我的回答是

即使使用了DoH，gfw還是能拿到sni，除非sni是null

但是你現在的回答是挂了代理你在某一層面沒有截取到sni(如果你是匹配出口REALITY ip截取)，這部分回答可能沒有問題，但是REALITY的sni還是能截取到，它是明文的

你還說了

可能我们聊得不是同一个东西

我看到這裏我終於懂你的意思了，你當初是想說(挂了代理)啓用doh的話，不怕中間人，但是我的回答也是沒有問題的，REALITY的sni還是能拿得到，除非是空sni，因爲這個討論的標題是關於REALITY的識別問題，所以根據標題和你的回答這一層面我當初的回答沒有產生誤解這種情況

你想驗證應該在瀏覽器啓用DoH和ECH，然後打開https://crypto.cloudflare.com/cdn-cgi/trace/來驗證，來驗證DoH-ECH這種技術是否真的加密了sni

我是4月在v2ray社區討論過這個問題，當時我對ECH很自信，認爲有了它以後不挂代理GFW也拿不到sni了，但是後來抓包發現sni還是明文的

我明白了，你说的是访问源服务器的 SNI，而我说的是请求 DNS 时的内容；

我想表达的意思是”中间人是看不到 DNS 解析结果的”，而你的意思是“中间人能看到访问源站的 SNI“

---

我是针对

第一个是收集不了所有的解析结果

这句话的，意思就是说中间人收集不到完整的结果

[RPRX]

日经问题，简单来说这种方式要么高误伤，要么高遗漏。

@nursery01 的测试方法仍是不完善的，没有换加密 DNS、运营商、位置 #2161 (reply in thread) 。不仅是 GFW 在哪的问题，现实中人会带着手机电脑到处跑，会出现带着上一个运营商、位置的 DNS 缓存的情况，而若算入多个 ASN，则会造成更高的遗漏率。

还有，我就说会有人引用、参考吧，结果你自己先引了，你应当在仓库里加上相关讨论的链接，比如那里和这里。

我觉得更有意义且简单的是仅测可以直连的境外域名（有数据库？），在多个完全不同的环境、时间查 DNS，对比一下 IP、ASN。

---

从封锁的角度出发，如果没有 SNI 白名单，则区分 REALITY 和 TLS 的意义不大，因为注册一个域名又不难，改偷自己不就好了。

如果已有 SNI 白名单，再匹配 IP 那就是 IP 白名单，连地狱模式的伊朗也只是试行了一段时间的 IP 白名单，中国就更加遥远。

[RPRX]

话说回来，参考伊朗的情况可以看到，REALITY 基本上是最后一道防线了，如果 REALITY 都不能用了，那可能就没什么能用的了。

所以与其天天担心这个问题，不如让自己活得开心一些，这种东西真来了就是全面封锁，一个都逃不掉，共勉。虽然我还有魔法。

[nursery01]

@RPRX 已經更新

[RPRX]

魔法参考：#2059 (comment) ，这里 REALITY 及其公私钥设计的好处就在于：

1. 路由上任何一点都能帮忙（而不必拥有目标网站），TLSv1.3 x25519 的网站都能拿来用
2. 公开公钥，谁都能用，即使 GFW 明知线路上会有鬼，拿着公钥也验证不了哪个请求是 REALITY，是一种阳谋，只有私钥可解

[RPRX]

https://t.me/projectXtls/105

若有相关资源，请私聊 @yuhan6665。如果所有线路上都有一点点 REALITY，那么 GFW 即使上“协议+SNI+IP”白名单也不好使了。

[nursery01]

是，如果能拿到一些私料，比如美國銀行的線路倒是可以，這種一般不會封，就是在ip白名單內，問題是普通人弄不到

[Phoenix-999]

话说回来，参考伊朗的情况可以看到，REALITY 基本上是最后一道防线了，如果 REALITY 都不能用了，那可能就没什么能用的了。

所以与其天天担心这个问题，不如让自己活得开心一些，这种东西真来了就是全面封锁，一个都逃不掉，共勉。虽然我还有魔法。

@RPRX

"Everything that has a beginning has an end. I see the end coming, I see the darkness spreading. I see death... and you are all that stands in his way. And if you can't find the answer, then I'm afraid there may be no tomorrow for any of us."

[RPRX]

我有一个大胆的想法：

可以参考 REALITY 的原理设计一个加密 IP 的标准，把真正的目标 IP 加密后放 Session ID，对于占 16 字节的 IPv6 空间也刚好够。

它解决了“目标 IP 没加密”的痛点，与现有的 middle-box 完全兼容且具有 欺骗性，只有手握私钥的路由节点才知道真正的目标 IP。

应该推动这个标准进 IETF，各地路由节点公开其公钥，你想让哪个节点知道，使用它的公钥即可。SNI 欺骗则由新 REALITY 负责。

[Fangliding]

世界五大秘密
维纳斯的短臂
还差5分钟算出的42的解释
先辈的真实身份
梁家河大队借阅室的藏书量
R主席口中的魔法

[Fangliding]

我有一个大胆的想法：

可以参考 REALITY 的原理设计一个加密 IP 的标准，把真正的目标 IP 加密后放 Session ID，对于占 16 字节的 IPv6 空间也刚好够。

它解决了“目标 IP 没加密”的痛点，与现有的 middle-box 完全兼容且具有 欺骗性，只有手握私钥的路由节点才知道真正的目标 IP。

应该推动这个标准进 IETF，各地路由节点公开其公钥，你想让哪个节点知道，使用它的公钥即可。SNI 欺骗则由新 REALITY 负责。

IETF有过推进IP层面安全的尝试(IPsec) 但是阻力非常巨大 从要求变成了可选

[RPRX]

我就知道会有人提 IPsec，这个东西好像是加密数据用的，没加密 IP 地址吧？而且它比较复杂，而且直接改 IP 协议当然很难推广。

所以基于 TCP 的 TLS 用得最广泛，所以 QUIC 选择了基于 UDP。同理，上述标准基于现有的 TLSv1.3，而且非常简单，易推广。

若上述标准推广开，与之配合的新 REALITY 都不用防主动探测了，反正始终藏在假 IP 后面。哪怕 GFW 找到了真 IP，也没有关系。

[chika0801]

安排上，后年出 💏

[nursery01]

我有一个大胆的想法：

可以参考 REALITY 的原理设计一个加密 IP 的标准，把真正的目标 IP 加密后放 Session ID，对于占 16 字节的 IPv6 空间也刚好够。

它解决了“目标 IP 没加密”的痛点，与现有的 middle-box 完全兼容且具有 欺骗性，只有手握私钥的路由节点才知道真正的目标 IP。

应该推动这个标准进 IETF，各地路由节点公开其公钥，你想让哪个节点知道，使用它的公钥即可。SNI 欺骗则由新 REALITY 负责。

即使設計加密IP，目標ip在某一層肯定是要明文的，否則就會出口丟失

[RPRX]

即使設計加密IP，目標ip在某一層肯定是要明文的，否則就會出口丟失

再理解下中间那行

[nursery01]

即使設計加密IP，目標ip在某一層肯定是要明文的，否則就會出口丟失

再理解下中间那行

只從IT理論邏輯角度考慮行不行的話

你家裡的路由器開始發包給本地isp的交換機它就能拿私鑰解密了

如果你的意思是直接把包發給美國，然後由美國isp解密，中國的isp公司不參與解密，那麽你發了一個包，進過本地isp的交換機，那台交換機在不知道ip的情況下要把包發給誰呢？北京？美國？非洲？

那假如在包裡帶個類似於ip的明文的地址，寫著台灣台北市中華電信A號交換機，這樣ip加密也知道發向哪了，那反過來說它就能審查了

而且還有回包解密問題

而且ip是網路基礎"粒子"，加密的話會引來各種複雜的問題

[Fangliding]

@ccckfg 这

[nursery01]

魔法参考：#2059 (comment) ，这里 REALITY 及其公私钥设计的好处就在于：

1. 路由上任何一点都能帮忙（而不必拥有目标网站），TLSv1.3 x25519 的网站都能拿来用

2. 公开公钥，谁都能用，即使 GFW 明知线路上会有鬼，拿着公钥也验证不了哪个请求是 REALITY，是一种阳谋，只有私钥可解

其實理論上來說，即使你讓企業分流，gfw還是能從中識別並抽取REALITY，TLS代理和正常的網站頻率上還是有差異，你用了代理就會產生這種差異，你沒用代理就不會產生，技術上難以消除頻率問題

至於怎麼從企業線路中檢測，用wireshark的文法來說就是 ip.src==user ip && ip.dst==enterprise ip

檢測出來就可以ip.src to ban

但是實際上企業線路是白名單不會去檢測

[bcegkmqs23]

推进这种IP加密听上去还是比较看海外ISP脸色了，不清楚它们对这类东西态度怎么样。

[Remustarded]

一是怎么确保白名单 IP 的路由一定会经过有私钥的节点，难道买通骨干路由吗（，

倒过来想: 我不能确保某个白名单IP会经过私钥节点, 但我只需要确保某个私钥节点上存在白名单IP

二是如果 GFW 也用公钥加密后发一个“测试包”，是不是就可以暴露路径上夹带私货的节点？

如果我的理解正确的话, GFW顶多知道这个节点支持这个技术. 所以最理想的情况是这个技术是广泛部署的标准.

如果成为了IETF标准并且你能确定每个节点的转发行为, 你甚至可以玩IP套娃, 什么洋葱路由

[Fangliding]

只是说的玩的为什么有那么多人感兴趣（）

[ZqinKing]

第二个是不排除有人使用 DOH 这种不怕中间人攻击的 DNS 解析方式

即使使用了DoH，gfw還是能拿到sni，除非sni是null

GFW 拿到的 SNI 是 DNS 服务器的 SNI，拿不到解析的域名

sni是可以從client hello裡面獲取的，它是明文的，現階段的標準並沒有完全加密sni，包括下一代技術http3

在 Client Hello 里的是 DNS 服务器的 SNI，而请求解析的域名是在 Body 里的，是完全加密的；GFW 自然知道我是在进行 DNS 解析，然而它也就只知道我在进行 DNS 解析，却不知道具体内容

这是不是理解错了？楼主的意思是对比SNI中域名的真实解析IP与流量中的目标IP，来判断是否是reality。而不是DNS解析查询的过程。

[ZqinKing]

回复一下群里一些小白疑问：

这是什么想法 加密 IP?
地址都给加密了 物流怎么送件
超乎我认知了

外表上是白名单内的目标 IP 地址，到了国外的某一处路由时，才能解密出真正的目标 IP 地址。

加密ip？ipv6当年"强制"的ipsec都凉凉了
想太多系列
不如推进ech靠谱

IPsec 评价过了：#2230 (comment)

ECH 解决的是明文 TLS Client Hello 的问题，而上述标准解决的是明文 IP 地址的问题，不是一回事。

而且 ECH 特征明显，还不是强制性的，GFW 肯定会拦截，还不如用 TLS 类代理。而上述标准是隐写术，GFW 无法针对性拦截。

到时候gfw还是会有全国所有路由器的私钥吧

它拿不到国外路由节点的私钥就行，况且国内确实不会批这个东西，更不会有私钥了。

这个是不是有点难。。。

[KanakoMikami]

由于代理服务器的 ASN 是可知的，有没有可能针对 ASN 建立域名黑名单，或针对域名建立 ASN 黑名单甚至白名单？比如微软不会使用 linode 的 ASN 这样的假设，应该并不会误伤。又或者某公司的 ASN 全是已知的。

这种规则不容易做到多高的覆盖率，但能检测到集中配置为几个域名的用户，并且使以后不容易找可用的域名。

@RPRX

[bcegkmqs23]

由于代理服务器的 ASN 是可知的，有没有可能针对 ASN 建立域名黑名单，或针对域名建立 ASN 黑名单甚至白名单？比如微软不会使用 linode 的 ASN 这样的假设，应该并不会误伤。又或者某公司的 ASN 全是已知的。

这种规则不容易做到多高的覆盖率，但能检测到集中配置为几个域名的用户，并且使以后不容易找可用的域名。

现在似乎确实已在建议不要乱偷了，我记得群里好像有人报告问题，讨论怀疑是ASN的问题。

[RPRX]

由于代理服务器的 ASN 是可知的，有没有可能针对 ASN 建立域名黑名单，或针对域名建立 ASN 黑名单甚至白名单？比如微软不会使用 linode 的 ASN 这样的假设，应该并不会误伤。又或者某公司的 ASN 全是已知的。

这种规则不容易做到多高的覆盖率，但能检测到集中配置为几个域名的用户，并且使以后不容易找可用的域名。

@RPRX

net4people/bbs#254 (comment)
net4people/bbs#257 (comment)
#2256 (comment)
#2281 (comment)

当然你提到的“干净 IP 来自不太知名的提供商”会被限速，我觉得即使 GFW 没有能力实时同步所有域名的所有 IP，GFW 至少有能力查出你这个小众 IP 段不可能有某个知名网站，这个事情我也不是第一次说了

[chika0801]

防丢联动：关于通过源ip特征和主动访问识别reality的可能性

[zypfff]

这样来不可行。原理和朋友聊天时说了我记不到链接了，你有兴趣来Xray群询问其他人交流看法。

我可以进群吗

[chika0801]

这样来不可行。原理和朋友聊天时说了我记不到链接了，你有兴趣来Xray群询问其他人交流看法。

我可以进群吗

自己注册tg再去加群就是了，群地址在readme里面写了的。

[testcaoy7]

我就知道会有人提 IPsec，这个东西好像是加密数据用的，没加密 IP 地址吧？而且它比较复杂，而且直接改 IP 协议当然很难推广。

所以基于 TCP 的 TLS 用得最广泛，所以 QUIC 选择了基于 UDP。同理，上述标准基于现有的 TLSv1.3，而且非常简单，易推广。

若上述标准推广开，与之配合的新 REALITY 都不用防主动探测了，反正始终藏在假 IP 后面。哪怕 GFW 找到了真 IP，也没有关系。

IPsec当然加密了IP地址……
IPv6的那个不是IPsec是Cryptographic Routing

IPsec没有什么不能推广的，如果双端都是公网IP那么，IPsec（50号IP协议）可以直接连通
如果有一端工作在NAT后面，就需要UDP Encapsulation
IPsec有两个阶段，IKE需要500/UDP，ESP如果使用了UDP Encapsulation则需要4500/UDP端口
而且不能变，是强制标准
所以一封一个准

不过话虽然这么说，我的strongSwan服务器好几年了一直没封……

[RPRX]

@testcaoy7

没用过 IPsec，如果它把 IP 地址 完全 加密了，怎么做路由
听你的说法它可能是类似隧道的东西，把内容的 IP 地址给加密了，自身的 IP 地址还是会暴露，没有欺骗性

[testcaoy7]

@RPRX 是的。我就是这个意思，IPsec其实是一种Policy Based VPN（意味着它不会创建类似于TUN/TAP这种VTI设备）
IPsec和加密路由完全不是一回事，但是由于IPsec被企业和许多云计算服务商用来做Site-to-Site，因此GFW如果一刀切误伤会相当可观。

[testcaoy7]

@RPRX
既然谈到了隧道，不妨说说一个有趣的现象，Linux内核支持许多虚拟隧道设备（GRE、VXLAN、FOU、Geneve等等），它们都需要双端公网IP才能正常工作
随着IPv6的普及，许多家庭宽带下面的设备都能拥有一个v6公网，然后我做实验尝试了FOU和Geneve隧道，发现甚至在隧道内容完全没有加密（隧道本身不提供加密）的情况下，跑“敏感”流量也不会触发封锁。

[testcaoy7]

另一个观察到的现象是，目前封锁似乎集中于TCP和UDP
然而IP协议上层不止有TCP和UDP
不妨试试双端公网v6跑GRE over IPsec

[RPRX]

误伤的话，参考 TLS 的福建 SNI 白名单和河南 SNI 黑名单，用的人少才不会吸引火力，把 GFW 逼急了它啥事都干得出来

目前我们想做的是用白名单协议（TLS 类）加白名单 SNI 加白名单 IP 来骗 GFW，由于 QUIC 少一次握手，其实它更适合干这件事

再加上 符合目标网站的白名单流量特征，总之除了隐写真实 IP 目标这种操作需要推动标准进 IETF，其它的都不是大问题

[us254]

the ECH protocol involves two ClientHello messages:

the ClientHelloOuter, which is sent in the clear,
and the ClientHelloInner, which is encrypted and sent as an extension of the ClientHelloOuter.

The server completes the handshake with just one of these ClientHellos. If decryption succeeds, it proceeds with the ClientHelloInner; otherwise, it proceeds with the ClientHelloOuter.

This means that while there is an unencrypted message (ClientHelloOuter) in ECH, it is used as a fallback option if decryption fails.

However, it's important to note that the actual handshake parameters, including the sensitive values like the SNI and ALPN list, are encapsulated within the encrypted ClientHelloInner. The ClientHelloOuter is not used for establishing the intended connection but rather signals to the client that decryption failed and prompts it to retry the handshake with the public key provided by the server.

https://blog.cloudflare.com/encrypted-client-hello/

[hawshemi]

@RPRX

Let's encourage each other.Although I still have magic.**

Iranian people need that magic now...
All of the TLS-based servers are blocked by all operators in Iran now...
The hell mode is occurring in Iran.

[2GetApp]

第一个是收集不了所有的解析结果，第二个是不排除有人使用 DOH 这种不怕中间人攻击的 DNS 解析方式，第三个是所以要使用冷门的源服务器

当然对于黑盒不要去猜测有没有这个能力，一切宁可信其有

如果是用dns-ip匹配是不行的，誤報率會很高，雖然100%識別REALITY

如果是用dns-asn匹配誤報率低，但是會漏掉一些REALITY，這種方法能湊合著用

https://github.com/nursery01/GFW-system/tree/main/TLS/passive%20detection

中國的gfw和伊朗的isp不一樣，gfw考慮的是低誤報率，而伊朗考慮的是接近滴水不漏

那么如果GFW使用的方式不是封禁IP或者端口的方式，而是把疑似reality的连接，给转发到已知的真正服务器，从而进行干扰呢？

比如GFW观测到一个发向www.microsoft.com的连接，其目的IP和GFW已知的www.microsfot.com的真实IP都不匹配，GFW就把这个请求转发到真正的www.microsoft.com的IP上（即DNAT），从而这种方案不会影响真正www.microsoft.com请求。因为真正的请求也必定会被转发到真正的IP上，因此误伤造成的影响几乎是0。

[2GetApp]

那么如果GFW使用的方式不是封禁IP或者端口的方式，而是把疑似reality的连接，给转发到已知的真正服务器，从而进行干扰呢？

这要看这大清的国情来确定，因为修改域名解析的ip也是常见的服务提供方式，依赖DNS解析到不同ip来工作的服务或许就会失灵但共产党可以试试看这番折腾它还能不能活

依赖DNS解析到不同ip来工作的服务不会失灵，因为GFW只需要根据该IP是不是已知的真实服务器IP来决定是否转发就行，而不是转发所有请求。

GFW可以把全国各地DNS解析得到的IP作为真实服务器IP列表。GFW只把目的地址不是这个列表里的请求转发到这个真实服务器IP列表中的之一（比如根据就近转发原则来选择）。这样不会影响依赖DNS解析到不同ip来工作的服务，因为GFW不会去转发这类请求。即使GFW收集的真实服务器IP不全，转发也顶多造成延迟不一样这种后果，但是对于reality却是完全起到了封禁的作用。

[SodaWithoutSparkles]

对于楼主这样的想法我有三个问题：

1. 对于类似于cloudflare这样的返代该如何处理？虽然cloudflare可能不能兼容reality，但是假设有某个类似的服务是可以的，那么该如何处理？
2. 假设在搭建reality的伺服器上同时搭建一个网站，两者共用同一个IP，还能够拦截吗？
3. 如果某个网站经常更换IP，例如在IPv6的一个/64里面不停更换，或者动态IPv4之类，那么墙内用户将有一段时间不能访问该网站。

[AsenHu]

但是假设有某个类似的服务是可以的

reality 的流量只能在 L4 处理，因为它不是标准的 TLS 流量。而一般情况下，会用到 L4 转发的都是那种负载均衡，并且是并发很高的场景，不然 L7 的负载均衡就够用了。这种产品一般它后面只有那个企业的一个业务。

两者共用同一个IP，还能够拦截吗？

通常来说，翻墙建站二合一的网站，访客都很少，防火墙大概是两个一起墙了。

如果某个网站经常更换IP

那么这个网站的 DNS 记录在缓存失效前，且更换 IP 后这段时间，本来就是有用户无法访问的。当网络运营商的递归解析器缓存失效得到新的 IP 后，及时向防火墙添加记录放行，就能解决此问题。

[Xyncgas]

中共如果它有这个本事让它来试试再说
与此同时我们也要为这种情况想一下解决办法
解放军战略支援部队为以后要走的路做准备，确保要锁得更严一点的时候有能力去做，DNS redirect to white list 这种做法的副作用到时候肯定有，因为时代不允许它跟Cloudflare坐下来吃个饭它就认了，所以误杀它也不管，最后要是去搞个白名单拔网线就完了，我们搞翻墙的研究，就是知道它投鼠忌器，我们技术能保证它付出很多后人们还是能够翻墙它还是要牺牲