v2ex 支持 quic 协议，存在中间人攻击

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1248 天前的主题，其中的信息可能已经有所发展或是发生改变。

如题

提示登录受限。地址来自 91.240.163.158 ，我 vps 根本就不是这个地址

imgur.com/a/xGewYpt

我的另一个账号 guanyin8cnq12，重置密码显示用户名不存在。害的我昨天重新注册了一个。

排查了 vps，格杀后，重新装了系统，问题依旧
vultr cloudsigma 都试了。

用 wireguard 全局模式，正常。
难道 V2EX 部分链接走 udp ？
还是最近比较流行的 quic 协议？

真是见鬼了

第 1 条附言 · 2021-07-28 08:28:46 +08:00

v2ex.com/signin/cooldown

关闭 chrome quic 似乎有效果。

chrome://flags/ 把 quic 禁用

第 2 条附言 · 2021-07-28 08:34:24 +08:00

禁用 quic 后，测试了下修改邮箱地址，发送的邮件里显示的是 vps 的真实 ip 。

想了想，可能 V2EX 依托的是 cloudflare 的 quic 。
怪不得昨天在 chrome 里死活提示我登录受限。在 ie 和 edge 里正常。真是个大坑啊

害的我走了好多弯路。

quic 不适合国内环境。

第 3 条附言 · 2021-07-28 13:52:12 +08:00

imgur.com/a/kZsdPqK

第 4 条附言 · 2021-07-28 20:06:51 +08:00

imgur.com/a/gFtgan5

V2EX

中间人

攻击

19 条回复 • 2023-01-13 22:08:09 +08:00

v2clay

2021-07-28 10:27:24 +08:00

@Livid 请站长帮忙确认下两个问题。
1. V2EX 是否开启 quic，从我目前的测试来看是开了，或者是 cloudflare 开的。
2.我的账号 guanyin8cnq12，是因为什么原因不能重置密码？降权还是拉黑了，谢谢。

learningman

2021-07-28 10:49:38 +08:00

考虑流量穿透的可能？
你密码被改是你账号被封禁了，v2ex 的封禁就是改账号密码

learningman

2021-07-28 10:51:03 +08:00

哦还有一种可能，你的代理软件不支持 UDP，考虑到你说的”用 wireguard 全局模式，正常。“，应该就是这个问题。
TCP 的流量走了你的代理，但是 UDP 因为不支持，所以直接从你本地的 IP 地址发出。而你本地的 IP 被拉黑了。

v2clay

2021-07-28 11:06:11 +08:00

@learningman 对，我只代理了 tcp，用 tls1.3 包装了下。国内的环境，你知道的，udp 根本跑不动。
udp 走的是移动运营商的，v2ex 给我反馈的 ip 是 91.240.163.158 ，这个肯定是有问题的。难道 qiang 可以做到任意修改 quic 数据包 ip，搞中间人攻击？ udp 是无状态的，是否更有利于刺探？

v2clay

2021-07-28 11:07:07 +08:00

@learningman 我修改密码，填写用户名，提示我，用户名不存在，无法修改。

learningman

2021-07-28 11:10:58 +08:00

@guanyin8cn #4 我不明白你在说什么，你需要再去看下 quic 的定义。
quic 基于 UDP，你没代理 UDP，那这个 IP 就是你自己本地的啊。

v2clay

2021-07-28 11:17:13 +08:00

@learningman 我本地的 ip 不是这个 91.240.163.158 ，这个 ip 来自美国，我的 ip 是国内移动的 ip 地址。如果是我运营商的 ip，我也不用这样问。
用 ip.sb 查询这个 ip 来自美国。

learningman

2021-07-28 11:20:06 +08:00

@guanyin8cn #7 那就考虑流量穿透吧

v2clay

2021-07-28 11:26:47 +08:00

@learningman 按照这个理解，移动用电信或联通的线路做了 udp 流量穿透？等等我测试下移动访问 cloudflare 的 tcp 流量显示的什么地址。

v2clay

2021-07-28 11:32:22 +08:00

@learningman 不好理解，移动宽带的 ip 从国际线路出去的 tcp 流量，的 ip 均是本 ip，不是经过流量穿透显示的 nat ip 的地址。

v2clay

2021-07-28 13:56:31 +08:00

@Livid 问题一已经确定。麻烦看看问题 2 是怎么回事，谢谢。

@learningman 经过确认，联通宽带没有问题。移动宽带针对 quic 流量有 nat 操作。目前不能确定是否对所有 quic 流量都有 nat，还是只针对 cloudflare 有。不能确定是否对所有 udp 都有 nat 操作。需要进一步确认。

v2clay

2021-07-28 14:10:53 +08:00

@learningman 我用 vps 的 dnsmasq 开启 querylog 做的实验，真实显示我的 query ip 为当前移动 ip，没有做 nat 。

我需要再搭建一个支持 quic 的 nginx 通过访问日志才能确定，是否只对 cloudflare 做 nat 。
如果答案是否，那说明 qiang 有意针对 quic 做了一些工作。

learningman

2021-07-28 14:13:06 +08:00

@guanyin8cn #12 tls 是数学安全的，能做啥工作。。。

v2clay

2021-07-28 14:21:18 +08:00

@learningman tls1.3 是绝对安全的，底层的承载 udp

v2clay

2021-07-28 14:22:58 +08:00

@learningman 明明可以 ip 直连，非要搞一个 nat，不知道要做什么。

Cipool

2021-07-28 19:06:02 +08:00

移动就喜欢搞一些奇怪的流量穿透，之前有南方移动用户报告某些 Google 和 Cloudlfare 的 IP 被移动流量穿透到香港，一度还被人拿来当伪“IPLC"叫卖。

v2clay

2021-07-28 20:06:36 +08:00

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

v2clay

2021-07-28 20:10:50 +08:00

@Cipool
@learningman
@Livid

用 cloudflare，开启 quic，开启 js 质询，测试了下，显示地址来自运营商的地址。
见我第四条附言。所以，结论是移动通过 quic 访问 cloudflare，穿墙前根本没有做 nat （流量穿透），问题出在 cloudflare 到 v2 真实 ip 之间？

c398425861

2023-01-13 22:08:09 +08:00

用了 warp 吗，之前试过 quic 的 ip 和 tcp 的不同的