V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
v2clay
V2EX  ›  宽带症候群

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

  •  
  •   v2clay · 2021-07-28 16:05:47 +08:00 · 4629 次点击
    这是一个创建于 974 天前的主题,其中的信息可能已经有所发展或是发生改变。
    起因:

    老账号 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
    用 cloudflare,开启 quic,开启 js 质询,测试了下,显示地址来自运营商的地址。

    imgur.com/a/gFtgan5
    第 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
    第 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
    第 6 条附言  ·  2021-07-29 06:06:13 +08:00
    我用移动 v6,直接去访问,显示的是 v6 地址,地区为 cn
    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 都正常了。
    第 9 条附言  ·  2021-07-29 12:14:46 +08:00
    第 10 条附言  ·  2021-07-30 07:33:44 +08:00
    27 条回复    2021-07-30 16:56:40 +08:00
    cwbsw
        1
    cwbsw  
       2021-07-28 16:48:27 +08:00   ❤️ 2
    V2 不是被墙了吗,这个 IP 就是 GFW 伪造的用来中断连接的源地址吧。
    不过浏览器应该是 TCP 443 连接成功之后才会尝试连接 UDP 443 的,这里面或许有什么别的机制导致了楼主的结果。
    v2clay
        2
    v2clay  
    OP
       2021-07-28 16:52:37 +08:00
    @cwbsw v 做了 cloudflare,qiang 的只是 dns 解析。我 ss 只代理了 tcp,dns 解析能获取到真正的 v 地址。
    titanium98118
        3
    titanium98118  
       2021-07-28 17:07:09 +08:00
    v 站是被 sni 阻断了吧
    v2clay
        4
    v2clay  
    OP
       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
        5
    cwbsw  
       2021-07-28 17:46:54 +08:00
    @guanyin8cn
    我这里不行,SNI 阻断了。
    你不要直连,关不关 QUIC 都不影响的。Google 全系开启 QUIC 很多年了,不管 UDP 有没有墙都不影响正常访问。
    v2clay
        6
    v2clay  
    OP
       2021-07-28 21:44:55 +08:00
    @cwbsw
    @learningman
    你这么说提醒了我,刚看了下 v 的证书,用的是 cloudflare 的免费证书。如果 qiang 拿到了 cloudflare ca 的权限,完全有能力解密客户端到 cf 的流量(目前这种大环境下,cf 也不得不低头)。另一方面,udp 又是无状态的,更容易实施中间人攻击。
    除此,我想不到还有哪种可能。
    Laitinlok
        7
    Laitinlok  
       2021-07-29 03:03:01 +08:00 via Android
    @guanyin8cn QUIC 好像是 TCP over UDP,的
    LnTrx
        8
    LnTrx  
       2021-07-29 04:34:24 +08:00   ❤️ 5
    @guanyin8cn
    Cloudflare 的私钥如果泄露那绝对是大新闻,即使有也不太可能用在你身上
    看 Cloudflare 识别到的是哪个 IP 地址,可以直接访问 https://www.v2ex.com/cdn-cgi/trace
    v2clay
        9
    v2clay  
    OP
       2021-07-29 05:15:29 +08:00
    @LnTrx 感谢,结果在第三条附言,请帮忙分析分析。
    Rocketer
        10
    Rocketer  
       2021-07-29 06:36:27 +08:00 via iPhone
    CF 为什么要低头?又不像微软之类的还要在中国赚钱,爱封不封。
    v2clay
        11
    v2clay  
    OP
       2021-07-29 06:49:42 +08:00
    @cwbsw #5 今天试了下,确实不行,被阻断了。要扶墙。
    sky96111
        12
    sky96111  
       2021-07-29 09:09:37 +08:00 via Android
    @guanyin8cn 我这边 SNI 阻断已经几个月了
    v2clay
        13
    v2clay  
    OP
       2021-07-29 12:11:08 +08:00
    @LnTrx
    @cwbsw
    @learningman
    @titanium98118

    经过不懈努力,终于搞清楚了。
    通过 ss 在 jp vps 上解析的三个 v 地址,
    v2clay
        14
    v2clay  
    OP
       2021-07-29 12:11:50 +08:00
    104.20.10.218
    104.20.9.218
    172.67.3.188
    v2clay
        15
    v2clay  
    OP
       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
        16
    v2clay  
    OP
       2021-07-29 12:13:27 +08:00
    指向 new 节点

    104.18.93.225
    104.18.94.225

    查看访问的 ip 都正常了。
    v2clay
        17
    v2clay  
    OP
       2021-07-29 12:15:55 +08:00
    没办法,新账号限制多,不知道那个词触碰到规则,只能拆开来分多条发。
    v2clay
        18
    v2clay  
    OP
       2021-07-29 12:20:41 +08:00
    指向 h g 的 cf 节点的 ip 后,感觉访问 v 的速度都上来了。
    LnTrx
        19
    LnTrx  
       2021-07-29 12:30:22 +08:00
    @guanyin8cn 如果 traceroute 到国外的话,那大概率是 cf 自己的节点
    一个猜想,你以 UDP 访问 V2EX 是不走代理的,而运营商恰巧对特定 IP 、特定协议有流量穿透,结果导致访问 cf 的源 IP 变成运营商穿透的出口地址。
    titanium98118
        20
    titanium98118  
       2021-07-29 12:32:47 +08:00
    @guanyin8cn #15 无一例外 ERR_CONNECTION_RESET
    v2clay
        21
    v2clay  
    OP
       2021-07-29 12:40:46 +08:00 via Android
    @LnTrx 这个穿透的 nat 位于美帝,有点不可思议
    v2clay
        22
    v2clay  
    OP
       2021-07-29 13:38:47 +08:00
    @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
        23
    v2clay  
    OP
       2021-07-29 18:17:59 +08:00
    @titanium98118 #20
    @sky96111 #12
    @cwbsw #5

    实测,关闭 ss 代理,把 v 的解析写入 hosts, 通过 quic 可以直连 v,无 sni 阻断。sni 阻断只针对 tcp 连接。
    v2clay
        24
    v2clay  
    OP
       2021-07-29 18:46:32 +08:00
    貌似 quic 有些 bug,第一次连接需要 http2 支持,即 tcp 支持。当第一次链接成功后,第二次再刷新,就变成了 http3.
    也没有搜索到相关的资料。
    cwbsw
        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"
    }
    ]
    v2clay
        26
    v2clay  
    OP
       2021-07-30 07:33:01 +08:00
    @LnTrx #19
    我把 我自己的一个域名,指向 104.20.10.218 ,发现确实有针对特定 i p 和特定协议有流量穿透。不过这流量穿透到美帝有点不可思议啊。会不会是 cf 自己搞的流量穿透?
    LnTrx
        27
    LnTrx  
       2021-07-30 16:56:40 +08:00
    @v2clay 流量穿透应该是运营商的行为,穿透的出口应该是香港,只不过这几跳可能被隐藏了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   977 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 20:28 · PVG 04:28 · LAX 13:28 · JFK 16:28
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.