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

[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

用 cloudflare，开启 quic，开启 js 质询，测试了下，显示地址来自运营商的地址。

imgur.com/a/gFtgan5

v2
imgur.com/a/kZsdPqK

imgur.com/a/JjNBGT9

请大家用下面地址检测下。感谢 #8
www.v2ex.com/cdn-cgi/trace

在路由器里加一条 drop udp 443
iptables -I FORWARD -p udp --dport 443 -j REJECT

结果自动切换到我的 vps 上。
imgur.com/a/KGFmzV0

我用移动 v6，直接去访问，显示的是 v6 地址，地区为 cn
imgur.com/a/kdQAify

imgur.com/a/5J4ZjzS
太难了

经过不懈努力，终于搞清楚了。
通过 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 都正常了。

imgur.com/a/0nLnt7Y

imgur.com/a/3p42Mtb

[cwbsw]

V2 不是被墙了吗，这个 IP 就是 GFW 伪造的用来中断连接的源地址吧。
不过浏览器应该是 TCP 443 连接成功之后才会尝试连接 UDP 443 的，这里面或许有什么别的机制导致了楼主的结果。

[v2clay]

@cwbsw v 做了 cloudflare，qiang 的只是 dns 解析。我 ss 只代理了 tcp，dns 解析能获取到真正的 v 地址。

[titanium98118]

v 站是被 sni 阻断了吧

[v2clay]

@titanium98118 给你们三个 v 的地址

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

你会发现，不扶墙，也可以访问。

[cwbsw]

@guanyin8cn
我这里不行，SNI 阻断了。
你不要直连，关不关 QUIC 都不影响的。Google 全系开启 QUIC 很多年了，不管 UDP 有没有墙都不影响正常访问。

[v2clay]

@cwbsw
@learningman
你这么说提醒了我，刚看了下 v 的证书，用的是 cloudflare 的免费证书。如果 qiang 拿到了 cloudflare ca 的权限，完全有能力解密客户端到 cf 的流量（目前这种大环境下，cf 也不得不低头）。另一方面，udp 又是无状态的，更容易实施中间人攻击。
除此，我想不到还有哪种可能。

[Laitinlok]

@guanyin8cn QUIC 好像是 TCP over UDP,的

[LnTrx]

@guanyin8cn
Cloudflare 的私钥如果泄露那绝对是大新闻，即使有也不太可能用在你身上
看 Cloudflare 识别到的是哪个 IP 地址，可以直接访问 https://www.v2ex.com/cdn-cgi/trace

[v2clay]

@LnTrx 感谢，结果在第三条附言，请帮忙分析分析。

[Rocketer]

CF 为什么要低头？又不像微软之类的还要在中国赚钱，爱封不封。

[v2clay]

@cwbsw #5 今天试了下，确实不行，被阻断了。要扶墙。

[sky96111]

@guanyin8cn 我这边 SNI 阻断已经几个月了

[v2clay]

@LnTrx
@cwbsw
@learningman
@titanium98118

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

[v2clay]

104.20.10.218
104.20.9.218
172.67.3.188

[v2clay]

@LnTrx
@cwbsw
@learningman
@titanium98118

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

104.20.10.218
104.20.9.218
172.67.3.188

可能是跟某云合作的 ip

[v2clay]

指向 new 节点

104.18.93.225
104.18.94.225

查看访问的 ip 都正常了。

[v2clay]

没办法，新账号限制多，不知道那个词触碰到规则，只能拆开来分多条发。

[v2clay]

指向 h g 的 cf 节点的 ip 后，感觉访问 v 的速度都上来了。

[LnTrx]

@guanyin8cn 如果 traceroute 到国外的话，那大概率是 cf 自己的节点
一个猜想，你以 UDP 访问 V2EX 是不走代理的，而运营商恰巧对特定 IP 、特定协议有流量穿透，结果导致访问 cf 的源 IP 变成运营商穿透的出口地址。

[titanium98118]

@guanyin8cn #15 无一例外 ERR_CONNECTION_RESET

[v2clay]

@LnTrx 这个穿透的 nat 位于美帝，有点不可思议

[v2clay]

@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

[v2clay]

@titanium98118 #20
@sky96111 #12
@cwbsw #5

实测，关闭 ss 代理，把 v 的解析写入 hosts， 通过 quic 可以直连 v，无 sni 阻断。sni 阻断只针对 tcp 连接。

[v2clay]

貌似 quic 有些 bug，第一次连接需要 http2 支持，即 tcp 支持。当第一次链接成功后，第二次再刷新，就变成了 http3.
也没有搜索到相关的资料。

[cwbsw]

@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"
}
]

[v2clay]

@LnTrx #19
我把 我自己的一个域名，指向 104.20.10.218 ，发现确实有针对特定 i p 和特定协议有流量穿透。不过这流量穿透到美帝有点不可思议啊。会不会是 cf 自己搞的流量穿透？

[LnTrx]

@v2clay 流量穿透应该是运营商的行为，穿透的出口应该是香港，只不过这几跳可能被隐藏了