search

klzgrad / naiveproxy

Make a fortune quietly
BSD 3-Clause "New" or "Revised" License
6.52k stars 875 forks source link

naive是不是被攻克了 #633

Closed Angel0726 closed 4 months ago

Angel0726 commented 5 months ago

naive今天突然不能用了。

目前可以知道naive被侦测到了（前几天被dns劫持，但是通过host解决了）；但是不清楚这次侦测是怎么做到的不是劫持 也不是封端口、封IP。

aretsan commented 5 months ago

感觉好像不行了。浏览器可以正常访问网页，但naive挂掉了。

Angel0726 commented 5 months ago

感觉好像不行了。浏览器可以正常访问网页，但naive挂掉了。

你的现象跟我一样吗？那你现在用什么代理

aretsan commented 5 months ago

不太一样，我是可以curl访问域名的，就只是naive不行了。

aretsan commented 5 months ago

可能把你域名封了…你可以试试换个域名

Angel0726 commented 5 months ago

可能把你域名封了…你可以试试换个

不是封域名。ping域名可以，但是curl域名不可以。 curl naive域名:443不可以，但是curl 域名:其他端口可以

Angel0726 commented 5 months ago

基本确定了 封的端口，应该是根据tls、域名操作的。更换端口不适用tls可以，但是如果加入tls立马封锁端口

aretsan commented 5 months ago

实验了一下，确实不是naive被识别了，而是因为

` 免费域名eu.org的TLS连接被阻断

今天，来自论坛的信息显示中国大陆用户无法通过https协议访问使用免费域名eu.org的站点。目前，通过HTTP协议访问畅通，能够ping通。 `

adnmb commented 5 months ago

我也是今天中午一点多连不上了，两台不同地域的服务器的naive和trojan-go都连不上，分别为443端口和其他低位和高位端口，走的都是tls。 进行了一些测试，得出的结论是IP正常(不同机子ABC)，域名正常(ABC机子abcd域名排列组合)，端口不完全正常(80的http顺利、用5201或其他端口跑iperf3可以、而443只测连通性是时通时断)，但443/8443之类的tls不行(暂时没研究是卡tls握手哪一步)，不确定是否其他所有端口走tls都不行。

有个比较重点的操作，在境外vpsA上iperf3跑-s -p 443，境内-c连过去会显示被reset，境外-c连则正常。(与之相比，同时跑过其他tls协议的8443端口暂时没被reset，但也是今天同一时间无法工作的) 而境外vpsB上iperf3做同样的事，其他情况一样，不一样的点是，443没被reset，以及境内还是境外，连接都正常。(似乎此机子暂时还算健康，虽然协议也是今天连不上的，不敢再用此vps的443进行测试了，怕被永久)

以上情况看来，vpsA的443端口可能已经被永久reset，而vpsB的暂时还活着。 而我的vpsA和vpsB的直至今日出事前的协议配置完全是一致的(443及其他所有端口)。

不确定是否个例，我是今天挂的，若有其他人情况类似，那么是套tls的都被识别，还是只是简单封异常tls，是暂时还是永久，尚未可知。

所以我暂时的决策只能保守些，先停用naive/443/甚至是其他tls协议。

aretsan commented 5 months ago

好像是这样：你不能测443，因为不管是iperf3还是curl都是443端口上的可疑流量，所以测这个操作本身会导致443被封。

Angel0726 commented 5 months ago

我也是今天中午一点多连不上了，两台不同地域的服务器的naive和trojan-go都连不上，分别为443端口和其他低位和高位端口，走的都是tls。 进行了一些测试，得出的结论是IP正常(不同机子ABC)，域名正常(ABC机子abcd域名排列组合)，端口不完全正常(80的http顺利、用5201或其他端口跑iperf3可以、而443只测连通性是时通时断)，但443/8443之类的tls不行(暂时没研究是卡tls握手哪一步)，不确定是否其他所有端口走tls都不行。

有个比较重点的操作，在境外vpsA上iperf3跑-s -p 443，境内-c连过去会显示被reset，境外-c连则正常。(与之相比，同时跑过其他tls协议的8443端口暂时没被reset，但也是今天同一时间无法工作的) 而境外vpsB上iperf3做同样的事，其他情况一样，不一样的点是，443没被reset，以及境内还是境外，连接都正常。(似乎此机子暂时还算健康，虽然协议也是今天连不上的，不敢再用此vps的443进行测试了，怕被永久)

以上情况看来，vpsA的443端口可能已经被永久reset，而vpsB的暂时还活着。 而我的vpsA和vpsB的直至今日出事前的协议配置完全是一致的(443及其他所有端口)。

不确定是否个例，我是今天挂的，若有其他人情况类似，那么是套tls的都被识别，还是只是简单封异常tls，是暂时还是永久，尚未可知。

所以我暂时的决策只能保守些，先停用naive/443/甚至是其他tls协议。

跟你一样也是今天早上起来被封的。不套tls端口可以访问，套了立马被封。过一会又能访问。不过443端口可能被永久封了。 测试过10443、18443等都一样http可以套了tls就不行。不翻墙，单纯网站也被封

Angel0726 commented 5 months ago

好像是这样：你不能测443，因为不管是iperf3还是curl都是443端口上的可疑流量，所以测这个操作本身会导致443被封。

试过不用curl iperf3。单纯靠浏览器访问网站，本来可以访问，但是套了tls网站立马被封

Angel0726 commented 5 months ago

实验了一下，确实不是naive被识别了，而是因为

` 免费域名eu.org的TLS连接被阻断

今天，来自论坛的信息显示中国大陆用户无法通过https协议访问使用免费域名eu.org的站点。目前，通过HTTP协议访问畅通，能够ping通。 `

这个消息准吗，我确实是eu.org域名。但是naive用的是a..b.eu.org，翻墙失败，不能访问；但是指向vercel的b.eu.org，却可以访问

adnmb commented 5 months ago

实验了一下，确实不是naive被识别了，而是因为

` 免费域名eu.org的TLS连接被阻断

今天，来自论坛的信息显示中国大陆用户无法通过https协议访问使用免费域名eu.org的站点。目前，通过HTTP协议访问畅通，能够ping通。 `

@Angel0726 大概率是准确的 因为我的abcd四个域名中的abc即常用域名都是eu.org的 而d不是

尽管我在测试中有考虑是eu.org的问题 防止此变量而使用的d 但很可能是在abc高强度不停测试的前提下 443已经被3分钟(或类似的短时间封禁) 导致简单尝试了域名d发现也是不通的 所以得出了“域名正常”这个结论

但是刚刚 @aretsan 这位朋友提到eu.org的问题后 我临时买了个新域名试了一下 是通的 虽然无法直接判定上述消息的准确 但感觉相关性不小 我的vpsA和vpsB都是日常用的eu.org域名 vercel.app被ban之后也用的eu.org 一直没事 所以才妄断而没有花更多时间测域名出问题的可能性(甚至认为可能是服务器运营商及地域的问题而测试了vpsC)

如果vps的443端口比较要紧 那么可以等我试试用非eu.org的付费域名关掉其他协议只在443跑naive一段时间试试 如果到4月1日我依然没有详述后续 那么大概率navie依然还是可用的 并且是eu.org的域名的tls问题(非tls目前不影响)

届时各位应该可以尝试随便搞个其他域名来测一下高位443的tls了 没问题后或稳定后 再回到443用naive

What a tough day : )

Angel0726 commented 5 months ago

reality、vision以及Hysteria2协议怎么样

myrust commented 5 months ago

垃圾域名被阻断了，与协议无关

Angel0726 commented 5 months ago

那还有个问题，俩个域名

Chilledheart commented 5 months ago

TLS协议在握手时候域名（SNI）是明文可见的

adnmb commented 5 months ago

经过5天测试 已基本确认 naive协议本身并没任何问题 只是 *.eu.org的tls被禁 了 换个正常域名继续使用naive 即可


reality、vision以及Hysteria2协议怎么样

我并不认为前者比naive更成熟 而后者看quic的QoS情况可自行测试再考虑 (不太适合在此issue讨论其他协议 想讨论协议间对比 或许应单独开一个新issue

垃圾域名被阻断了，与协议无关

对的 基本已确认 https://*.eu.org 已被gfw给单独处理了 (测试ssl握手 偶尔能成功 但绝大多数情况下都是失败的 直接打开 https://nic.eu.org/ 看能否访问即可)

那还有个问题，俩个域名

  • a.b.eu.org指向naive服务器，不能访问
  • b.eu.org指向vercel服务器，可以访问 墙是怎么识别a.b.eu.org的，会不会naive不安全了，不过也有可能a.b.eu.org的访问流量太大了

我自己的指向vercel服务器的eu.org墙内并不能访问其https(似乎很偶尔的情况下能成功)

墙是怎么识别a.b.eu.org的

就像 @Chilledheart 所提及 没开esni的情况下 sni部分是裸的 也就是gfw是能看到你访问的domain的(a.b.eu.org) 只是不知道tls加密部分的内容

相对于识别tls in tls流量 看sni直接筛域名是个非常省事的办法 .vercel.app都无了 再多一个.eu.org并不会有很大影响 毕竟不是*.org

随便花几块钱弄个.xyz或.top即可 目前封顶级域名(TLD)的概率较低

感觉此issue应该可以close了

helloktity commented 5 months ago

我的一直正常,用的top域名

abc2001x commented 5 months ago

准备从v2ray转用naive, 因为套cf的ws估计都被识别了,可以访问页面,但是ws连接失败. 重新申请新的域名,刚开始第一天可以正常使用.第二天断断续续可以用, 然后就完全不能用和之前一样的情况,.

5l2 commented 5 months ago

目前可以知道naive被侦测到了（前几天被dns劫持，但是通过host解决了）

@Angel0726 你的结论建立在错误的事实和逻辑推理上😄️ 对于解决此类问题，.log 和 .pcap 是必要的，下次注意附带。

@klzgrad 请问是否考虑开启 discussions 栏目供讨论此类非 naiveproxy 的问题？

Angel0726 commented 5 months ago

目前可以知道naive被侦测到了（前几天被dns劫持，但是通过host解决了）

@Angel0726 你的结论建立在错误的事实和逻辑推理上😄️ 对于解决此类问题，.log 和 .pcap 是必要的，下次注意附带。

@klzgrad 请问是否考虑开启 discussions 栏目供讨论此类非 naiveproxy 的问题？

好的，不过哪里可以找到 .log 和 .pcap

Chilledheart commented 5 months ago

目前可以知道naive被侦测到了（前几天被dns劫持，但是通过host解决了）

@Angel0726 你的结论建立在错误的事实和逻辑推理上😄️ 对于解决此类问题，.log 和 .pcap 是必要的，下次注意附带。 @klzgrad 请问是否考虑开启 discussions 栏目供讨论此类非 naiveproxy 的问题？

好的，不过哪里可以找到 .log 和 .pcap

pcap 下载一个wireshark就可以，log 和你启动参数有关

klzgrad commented 5 months ago

是否考虑开启 discussions 栏目供讨论此类非 naiveproxy 的问题

本来也没有太多讨论，可以挂着不动，我也好奇有人汇报白名单区域或者高防机房无法用的检测机制，鼓励讨论

ArcCal commented 5 months ago

北京移动固网环境，使用甲骨文的免费机器上搭建naiveproxy，会很快被阻断。这是可以复现的。

同一个节点，小火箭上用，中国移动5G，却不会被阻断。

aretsan commented 5 months ago

并不能说明naive被识别，有可能是本来访问的节点就有问题，或者是被探针探到了。

需要在确保没有探针或者探针不能探到你的服务器的情况下，正常使用自己的网站一段时间，这段时间一直没有被封锁之后，再用naive才能说明naive被识别。

ArcCal commented 5 months ago

{ http_port 80 https_port 443 order forward_proxy before webdav order forward_proxy before basicauth order forward_proxy before header }

:443, www.example.com { tls { dns cloudflare APIKEY }

basicauth {
    webdav password
    }

root * /var/www/html

@get method GET
route {
    file_server @get {
    hide ._*    .DS*
    browse
    }
webdav
}

forward_proxy {
basic_auth 1111 2222
    hide_ip
    hide_via
    probe_resistance
    }

header {
    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    X-XSS-Protection "1; mode=block"
    X-Content-Type-Options nosniff
    X-Frame-Options DENY
    Referrer-Policy no-referrer-when-downgrade
    }

}

ArcCal commented 5 months ago

{ http_port 80 https_port 443 order forward_proxy before webdav order forward_proxy before basicauth order forward_proxy before header }

:443, www.example.com { tls { dns cloudflare APIKEY }

basicauth {
  webdav password
  }

root * /var/www/html

@get method GET
route {
    file_server @get {
  hide ._*    .DS*
  browse
  }
webdav
}

forward_proxy {
basic_auth 1111 2222
    hide_ip
    hide_via
    probe_resistance
    }

header {
    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    X-XSS-Protection "1; mode=block"
    X-Content-Type-Options nosniff
    X-Frame-Options DENY
    Referrer-Policy no-referrer-when-downgrade
    }

}

这是naiveproxy和webdav服务器二合一的。

即便naive被阻断，webdav服务器通过各种工具在各种网络环境下都可以访问。这应该能部分说明问题。

Angel0726 commented 5 months ago

我就是tls隔断了