移动和电信，帮忙测试下 quic

2021-07-28 16:05:47 +08:00
 v2clay
起因：

老账号 guanyin8cnq12，昨天死活登录不上，提示密码错误，通过邮件修改密码，提示用户名不存在。多次提交后提示，登录受限，ip 为 91.240.163.158 ，我 vps 和 移动宽带地址，根本就不是这个地址。怀疑中间有攻击，于是各种找原因。

1.vps ，删除后重建，问题依旧。排除 vps 问题
2.重装 chrome，问题依旧，排除 chrome
3.用 ie 或 edge，正常。
4.用 wireguard，全局代理，问题消失。因为我的代理是 ss，只代理 tcp，怀疑是 udp 问题。
5.打开 v，按 f2，显示协议是 quic，v 站开始支持 quic 了。
6.chrome 默认开启了 quic，解释了 2，3 的原因。

求助：
请移动，电信，联通的 v 友们，帮忙测试下。
用 chrome，开启 quic （ chrome://flags/ 把 quic enable，新版默认是开启），访问 v，修改邮箱，然后会发一份邮件到自己的邮箱，邮箱里会有 ip，麻烦比对下 ip 是不是自己的运营商的 ip 。

我在 v 的反馈里，开了一个帖子，里面有更详细的内容。
v2ex.com/t/792168
4900 次点击
所在节点    宽带症候群
27 条回复
cwbsw
2021-07-28 16:48:27 +08:00
V2 不是被墙了吗，这个 IP 就是 GFW 伪造的用来中断连接的源地址吧。
不过浏览器应该是 TCP 443 连接成功之后才会尝试连接 UDP 443 的，这里面或许有什么别的机制导致了楼主的结果。
v2clay
2021-07-28 16:52:37 +08:00
@cwbsw v 做了 cloudflare，qiang 的只是 dns 解析。我 ss 只代理了 tcp，dns 解析能获取到真正的 v 地址。
titanium98118
2021-07-28 17:07:09 +08:00
v 站是被 sni 阻断了吧
v2clay
2021-07-28 17:38:06 +08:00
@titanium98118 给你们三个 v 的地址

address=/v2ex.com/104.20.10.218
address=/v2ex.com/104.20.9.218
address=/v2ex.com/172.67.3.188

你会发现，不扶墙，也可以访问。
cwbsw
2021-07-28 17:46:54 +08:00
@guanyin8cn
我这里不行，SNI 阻断了。
你不要直连，关不关 QUIC 都不影响的。Google 全系开启 QUIC 很多年了，不管 UDP 有没有墙都不影响正常访问。
v2clay
2021-07-28 21:44:55 +08:00
@cwbsw
@learningman
你这么说提醒了我，刚看了下 v 的证书，用的是 cloudflare 的免费证书。如果 qiang 拿到了 cloudflare ca 的权限，完全有能力解密客户端到 cf 的流量（目前这种大环境下，cf 也不得不低头）。另一方面，udp 又是无状态的，更容易实施中间人攻击。
除此，我想不到还有哪种可能。
Laitinlok
2021-07-29 03:03:01 +08:00
@guanyin8cn QUIC 好像是 TCP over UDP,的
LnTrx
2021-07-29 04:34:24 +08:00
@guanyin8cn
Cloudflare 的私钥如果泄露那绝对是大新闻，即使有也不太可能用在你身上
看 Cloudflare 识别到的是哪个 IP 地址，可以直接访问 https://www.v2ex.com/cdn-cgi/trace
v2clay
2021-07-29 05:15:29 +08:00
@LnTrx 感谢，结果在第三条附言，请帮忙分析分析。
Rocketer
2021-07-29 06:36:27 +08:00
CF 为什么要低头？又不像微软之类的还要在中国赚钱，爱封不封。
v2clay
2021-07-29 06:49:42 +08:00
@cwbsw #5 今天试了下，确实不行，被阻断了。要扶墙。
sky96111
2021-07-29 09:09:37 +08:00
@guanyin8cn 我这边 SNI 阻断已经几个月了
v2clay
2021-07-29 12:11:08 +08:00
@LnTrx
@cwbsw
@learningman
@titanium98118

经过不懈努力，终于搞清楚了。
通过 ss 在 jp vps 上解析的三个 v 地址，
v2clay
2021-07-29 12:11:50 +08:00
104.20.10.218
104.20.9.218
172.67.3.188
v2clay
2021-07-29 12:12:25 +08:00
@LnTrx
@cwbsw
@learningman
@titanium98118

经过不懈努力，终于搞清楚了。
通过 ss 在 jp vps 上解析的三个 v 站地址，

104.20.10.218
104.20.9.218
172.67.3.188

可能是跟某云合作的 ip
v2clay
2021-07-29 12:13:27 +08:00
指向 new 节点

104.18.93.225
104.18.94.225

查看访问的 ip 都正常了。
v2clay
2021-07-29 12:15:55 +08:00
没办法，新账号限制多，不知道那个词触碰到规则，只能拆开来分多条发。
v2clay
2021-07-29 12:20:41 +08:00
指向 h g 的 cf 节点的 ip 后，感觉访问 v 的速度都上来了。
LnTrx
2021-07-29 12:30:22 +08:00
@guanyin8cn 如果 traceroute 到国外的话，那大概率是 cf 自己的节点
一个猜想，你以 UDP 访问 V2EX 是不走代理的，而运营商恰巧对特定 IP 、特定协议有流量穿透，结果导致访问 cf 的源 IP 变成运营商穿透的出口地址。
titanium98118
2021-07-29 12:32:47 +08:00
@guanyin8cn #15 无一例外 ERR_CONNECTION_RESET

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/792300

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX