这是一个创建于 1205 天前的主题，其中的信息可能已经有所发展或是发生改变。
起因：
老账号 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
老账号 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
第 1 条附言 · 2021-07-28 20:07:48 +08:00
第 2 条附言 · 2021-07-28 20:56:49 +08:00
第 3 条附言 · 2021-07-29 05:14:54 +08:00
第 4 条附言 · 2021-07-29 05:17:33 +08:00
请大家用下面地址检测下。感谢 #8
www.v2ex.com/cdn-cgi/trace
www.v2ex.com/cdn-cgi/trace
第 5 条附言 · 2021-07-29 05:42:32 +08:00
在路由器里加一条 drop udp 443
iptables -I FORWARD -p udp --dport 443 -j REJECT
结果自动切换到我的 vps 上。
imgur.com/a/KGFmzV0
iptables -I FORWARD -p udp --dport 443 -j REJECT
结果自动切换到我的 vps 上。
imgur.com/a/KGFmzV0
第 6 条附言 · 2021-07-29 06:06:13 +08:00
我用移动 v6，直接去访问，显示的是 v6 地址，地区为 cn
imgur.com/a/kdQAify
imgur.com/a/kdQAify
第 7 条附言 · 2021-07-29 06:56:06 +08:00
第 8 条附言 · 2021-07-29 12:14:31 +08:00
经过不懈努力，终于搞清楚了。
通过 ss 在 jp vps 上解析的三个 v 站地址，
104.20.10.218
104.20.9.218
172.67.3.188
可能是跟某云合作的 ip
指向新的节点。
104.18.93.225
104.18.94.225
通过 trace 查看访问的 ip 都正常了。
通过 ss 在 jp vps 上解析的三个 v 站地址，
104.20.10.218
104.20.9.218
172.67.3.188
可能是跟某云合作的 ip
指向新的节点。
104.18.93.225
104.18.94.225
通过 trace 查看访问的 ip 都正常了。
第 9 条附言 · 2021-07-29 12:14:46 +08:00
第 10 条附言 · 2021-07-30 07:33:44 +08:00
 |
1
cwbsw 2021-07-28 16:48:27 +08:00  2
V2 不是被墙了吗，这个 IP 就是 GFW 伪造的用来中断连接的源地址吧。
不过浏览器应该是 TCP 443 连接成功之后才会尝试连接 UDP 443 的，这里面或许有什么别的机制导致了楼主的结果。 |
 |
2
v2clay OP @cwbsw v 做了 cloudflare，qiang 的只是 dns 解析。我 ss 只代理了 tcp，dns 解析能获取到真正的 v 地址。
|
 |
3
titanium98118 2021-07-28 17:07:09 +08:00
v 站是被 sni 阻断了吧
|
|
4
v2clay OP @titanium98118 给你们三个 v 的地址
address=/v2ex.com/104.20.10.218 address=/v2ex.com/104.20.9.218 address=/v2ex.com/172.67.3.188 你会发现，不扶墙，也可以访问。 |
|
5
cwbsw 2021-07-28 17:46:54 +08:00
|
|
6
v2clay OP @cwbsw
@learningman 你这么说提醒了我，刚看了下 v 的证书，用的是 cloudflare 的免费证书。如果 qiang 拿到了 cloudflare ca 的权限，完全有能力解密客户端到 cf 的流量（目前这种大环境下，cf 也不得不低头）。另一方面，udp 又是无状态的，更容易实施中间人攻击。 除此，我想不到还有哪种可能。 |
 |
7
Laitinlok 2021-07-29 03:03:01 +08:00 via Android
@guanyin8cn QUIC 好像是 TCP over UDP,的
|
 |
8
LnTrx 2021-07-29 04:34:24 +08:00 5
@guanyin8cn
Cloudflare 的私钥如果泄露那绝对是大新闻，即使有也不太可能用在你身上 看 Cloudflare 识别到的是哪个 IP 地址，可以直接访问 https://www.v2ex.com/cdn-cgi/trace |
 |
10
Rocketer 2021-07-29 06:36:27 +08:00 via iPhone
CF 为什么要低头？又不像微软之类的还要在中国赚钱，爱封不封。
|
 |
12
sky96111 2021-07-29 09:09:37 +08:00 via Android
@guanyin8cn 我这边 SNI 阻断已经几个月了
|
|
13
v2clay OP |
|
14
v2clay OP 104.20.10.218
104.20.9.218 172.67.3.188 |
|
15
v2clay OP @LnTrx
@cwbsw @learningman @titanium98118 经过不懈努力，终于搞清楚了。 通过 ss 在 jp vps 上解析的三个 v 站地址， 104.20.10.218 104.20.9.218 172.67.3.188 可能是跟某云合作的 ip |
|
16
v2clay OP 指向 new 节点
104.18.93.225 104.18.94.225 查看访问的 ip 都正常了。 |
|
17
v2clay OP 没办法，新账号限制多，不知道那个词触碰到规则，只能拆开来分多条发。
|
|
18
v2clay OP 指向 h g 的 cf 节点的 ip 后，感觉访问 v 的速度都上来了。
|
|
19
LnTrx 2021-07-29 12:30:22 +08:00
@guanyin8cn 如果 traceroute 到国外的话，那大概率是 cf 自己的节点
一个猜想，你以 UDP 访问 V2EX 是不走代理的，而运营商恰巧对特定 IP 、特定协议有流量穿透，结果导致访问 cf 的源 IP 变成运营商穿透的出口地址。 |
|
20
titanium98118 2021-07-29 12:32:47 +08:00
@guanyin8cn #15 无一例外 ERR_CONNECTION_RESET
|
|
22
v2clay OP @LnTrx
目标 IP: <a href="172.67.3.188">172.67.3.188</a> 1 172.18.37.209 0 ms 0 ms 0 ms 局域网 * 2 192.168.1.1 3 ms 4 ms 4 ms 局域网 * EchoLife_WAP.lan 3 100.x.x.x 6 ms 9 ms 11 ms 共享地址 * 4 223.x.x.x 4 ms 4 ms 7 ms 中国 江苏 chinamobile.com 移动 5 183.207.x.x 5 ms 5 ms 17 ms 中国 江苏 chinamobile.com 移动 6 183.207.x.x 7 ms 7 ms 7 ms 中国 江苏 chinamobile.com 移动 7 183.207.x.x 21 ms 22 ms 27 ms 中国 江苏 chinamobile.com 移动 8 * * * * 9 * * * * 10 * * * * 11 * * * * 12 * * * * 13 * * * * 14 * * * * 15 172.67.3.188 105 ms 106 ms 108 ms CLOUDFLARE.COM cloudflare.com AS13335 |
|
23
v2clay OP @titanium98118 #20
@sky96111 #12 @cwbsw #5 实测，关闭 ss 代理，把 v 的解析写入 hosts， 通过 quic 可以直连 v，无 sni 阻断。sni 阻断只针对 tcp 连接。 |
|
24
v2clay OP 貌似 quic 有些 bug，第一次连接需要 http2 支持，即 tcp 支持。当第一次链接成功后，第二次再刷新，就变成了 http3.
也没有搜索到相关的资料。 |
|
25
cwbsw 2021-07-29 21:35:31 +08:00
@guanyin8cn
可能和这个东西有关。 Support for HTTPSSVC records in DNS. When enabled, Chrome may query a configured DoH server for HTTPSSVC records. If any HTTPSSVC records are returned, Chrome may upgrade the URL to HTTPS. If the records indicate support for QUIC, Chrome may attempt QUIC on the first connection. – Mac, Windows, Chrome OS, Android #dns-httpssvc "Answer": [ { "name": "v2ex.com.", "type": 65, "TTL": 299, "data": "1 . alpn=h3-29,h3-28,h3-27,h2 ipv4hint=104.20.9.218,104.20.10.218,172.67.3.188 ipv6hint=2606:4700:10::6814:9da,2606:4700:10::6814:ada,2606:4700:10::ac43:3bc" } ] |
Select Language