search

XTLS / Xray-core

Xray, Penetrates Everything. Also the best v2ray-core, with XTLS support. Fully compatible configuration.
https://t.me/projectXray
Mozilla Public License 2.0
24.96k stars 3.89k forks source link

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

Closed xthz closed 1 year ago

xthz commented 1 year ago

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

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

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

chika0801 commented 1 year ago

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

flowerinsnowdh commented 1 year ago

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

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

nursery01 commented 1 year ago

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

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

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

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

nursery01 commented 1 year ago

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

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

flowerinsnowdh commented 1 year ago

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

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

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

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

nursery01 commented 1 year ago

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

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

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

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

flowerinsnowdh commented 1 year ago

第二个是不排除有人使用 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 commented 1 year ago

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

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

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

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

nursery01 commented 1 year ago

第二个是不排除有人使用 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 commented 1 year ago

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

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

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

确实没有发现相关 SNI 内容

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

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

nursery01 commented 1 year ago

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

我是将 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 commented 1 year ago

但是我确实抓过，包括刚刚我也试了一遍 我是将 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 commented 1 year ago

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

@nursery01 的测试方法仍是不完善的，没有换加密 DNS、运营商、位置 https://github.com/XTLS/Xray-core/discussions/2161#discussioncomment-6056073 。不仅是 GFW 在哪的问题，现实中人会带着手机电脑到处跑，会出现带着上一个运营商、位置的 DNS 缓存的情况，而若算入多个 ASN，则会造成更高的遗漏率。

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

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

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

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

RPRX commented 1 year ago

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

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

nursery01 commented 1 year ago

@RPRX 已經更新

RPRX commented 1 year ago

魔法参考：https://github.com/XTLS/Xray-core/issues/2059#issuecomment-1543724596 ，这里 REALITY 及其公私钥设计的好处就在于：

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

https://t.me/projectXtls/105

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

nursery01 commented 1 year ago

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

Phoenix-999 commented 1 year ago

话说回来，参考伊朗的情况可以看到，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 commented 1 year ago

我有一个大胆的想法：

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

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

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

Fangliding commented 1 year ago

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

Fangliding commented 1 year ago

我有一个大胆的想法：

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

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

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

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

RPRX commented 1 year ago

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

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

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

chika0801 commented 1 year ago

安排上，后年出 :couplekiss:

nursery01 commented 1 year ago

我有一个大胆的想法：

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

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

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

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

RPRX commented 1 year ago

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

再理解下中间那行

nursery01 commented 1 year ago

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

再理解下中间那行

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

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

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

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

而且還有回包解密問題

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

RPRX commented 1 year ago

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

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

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

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

IPsec 评价过了：https://github.com/XTLS/Xray-core/issues/2230#issuecomment-1599080720

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

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

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

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

RPRX commented 1 year ago

@nursery01 想象力还是不够丰富，看一下新的回复

flowerinsnowdh commented 1 year ago

只有手握私钥的路由节点才知道真正的目标 IP。

这又是什么原理，最后还是要在公网中传输吧，公网中的应该我们控制不了吧

RPRX commented 1 year ago

完了，再聊下去又要花很多时间，总之这个东西就是，该说的已经说了，懂的人已经看懂了，不懂的说再多也还是不懂

flowerinsnowdh commented 1 year ago

~完了，再聊下去又要花很多时间，总之这个东西就是，该说的已经说了，懂的人已经看懂了，不懂的说再多也还是不懂~

不打扰了不打扰了，我自己去研究研究吧

nursery01 commented 1 year ago

我知道了，你是希望其它國家的isp公司作弊，你發包是白名單ip，然後裡面帶著加密IP，然後到那個國家的isp公司裡解密把白名單IP替換成真IP

理論上可以，想像力豐富

RPRX commented 1 year ago

我知道了，你是希望其它國家的isp公司作弊，你發包是白名單ip，然後裡面帶著加密IP，然後到那個國家的isp公司裡解密把白名單IP替換成真IP

理論上可以，想像力豐富

是的，它是一个通用的标准，我觉得像这样的方案，才是“加密 IP 地址”的最优解：必须 隐写 真正的目标 IP 地址，否则会被拦截。

（好像是）早在参与开发 v2 之前，我就热衷于研究前沿的隐私方案，当时 ESNI 在中国还能用，只剩 IP 地址对隐私的威胁最大。

RPRX commented 1 year ago

To 群里：还是想评论一下

前面说过的就是”强制推行底层加密有困难“，”有了ech域名白名单就会出问题"

首先这个东西不像 IPsec 那么复杂，且不是加密数据，只是加密了一次 IP 地址，每个连接仅需解密一次，解密开销非常小

其次这个东西不是强制的，而是可选的，有少数支持即可用，对中间设备来说是透明的，感知不到，更不必改造

最后，ECH 特征明显，而不是隐写，故如果不强制推行，肯定会被审查者拦截，拿它来举例也不太合适

ccckfg commented 1 year ago

作为一名小白终于勉强理解了r佬的IP加密设想了，可以预见这个奇妙的设想将会掀起多大的波澜

Fangliding commented 1 year ago

@ccckfg 这

nursery01 commented 1 year ago

魔法参考：https://github.com/XTLS/Xray-core/issues/2059#issuecomment-1543724596 ，这里 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 commented 1 year ago

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

Remustarded commented 1 year ago

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

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

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

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

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

Fangliding commented 1 year ago

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

ZqinKing commented 1 year ago

第二个是不排除有人使用 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 commented 1 year ago

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

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

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

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

IPsec 评价过了：#2230 (comment)

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

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

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

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

这个是不是有点难。。。

KanakoMikami commented 1 year ago

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

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

@RPRX

bcegkmqs23 commented 1 year ago

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

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

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

RPRX commented 1 year ago

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

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

@RPRX

https://github.com/net4people/bbs/issues/254#issuecomment-1565308254 https://github.com/net4people/bbs/issues/257#issuecomment-1575427340 https://github.com/XTLS/Xray-core/discussions/2256#discussioncomment-6295296 https://github.com/XTLS/Xray-core/discussions/2281#discussioncomment-6353098

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

chika0801 commented 1 year ago

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

zypfff commented 1 year ago

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

我可以进群吗

chika0801 commented 1 year ago

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

我可以进群吗

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

testcaoy7 commented 1 year ago

~我就知道会有人提 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服务器好几年了一直没封……