实验发现与 plex 的通信被 middlebox 干扰

V2EX = way to explore

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

现在注册

已注册用户请登录

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

近日发现 plex 的服务不可用。排障过程中，发现了一些有意思的事。

过程

Plex 其中一个受影响域名是 clients.plex.tv。

首先，查询 DNS ，得知此域名解析结果没有被污染。

$ nslookup clients.plex.tv
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   clients.plex.tv
Address: 172.64.151.205
Name:   clients.plex.tv
Address: 104.18.36.51
Name:   clients.plex.tv
Address: 2606:4700:4400::6812:2433
Name:   clients.plex.tv
Address: 2606:4700:4400::ac40:97cd

其次，选取 2606:4700:4400::ac40:97cd 为目标 IP 地址，测试连通性。得知此 IP 地址没有被封锁。

$ ncat -v 2606:4700:4400::ac40:97cd 443
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: Connected to 2606:4700:4400::ac40:97cd:443.

接着，选择 visa.com 为 SNI ，使用 curl 测试服务可用性。重复两次，得到相同结果。

$ curl --silent --output /dev/null \
  --write-out "%{http_code}" \
  --resolve visa.com:443:[2606:4700:4400::ac40:97cd] \
  https://visa.com
301

然后，选择 clients.plex.tv 为 SNI 再次测试服务可用性。观察到 curl 卡住，遂手工终止程序。

$ curl --silent --output /dev/null \
  --write-out "%{http_code}" \
  --resolve clients.plex.tv:443:[2606:4700:4400::ac40:97cd] \
  https://clients.plex.tv
^C

此时，再次使用 ncat 测试 IP 地址连通性。发现此 IP 地址已被封锁。

$ nc -v 2606:4700:4400::ac40:97cd 443
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: Connection timed out.

最后，使用 mtr 探测问题发生位置。命令：

$ mtr --tcp --port 443 --interval 1 --timeout 3 --no-dns 2606:4700:4400::ac40:97cd

发现最后一跳不在输出中显示。

约 5 分钟后，第三次使用 ncat 测试 IP 地址连通性。发现恢复。

$ ncat -v 2606:4700:4400::ac40:97cd 443
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: Connected to 2606:4700:4400::ac40:97cd:443.

此时，第二次使用 mtr 追踪路由。发现最后一跳已能够在输出中显示。

变换网络环境为蜂窝网，重复上述实验。结果相同。

使用 wireshark 抓包，重复上述实验。发现若 clients.plex.tv 为 SNI ，客户端在服务器 ServerHelloDone 后的一段时间内，不再能收到服务器的任何报文。这一过程中，客户端没有收到过 TCP RST 。

猜想

Plex 的一些域名已被 middlebox 干扰。

这一审查使用了非常聪明的机制，不同于以往封锁 IP 地址在骨干网丢弃出站报文，表现得更像是源自服务器的故障。

根据已知事实，楼主的猜想如下：

审查通过 SNI 触发
触发后，middlebox 会添加二元组条件的临时过滤规则来丢弃报文
规则在入站方向生效（依据 mtr 的输出结果猜测）
临时规则有效时间约为 5 分钟

此外，楼主猜测执行这套审查机制的是一套新颖的系统，与执行 SNI 阻断（如对 store.steampowered.com ）的那套也不同。最明显的是，这套系统没有注入 TCP RST 报文。

楼主尝试使用 TCP 或 TLS records 分片（ fragmentation ）保护客户端与 clients.plex.tv 的连接免受 middlebox 攻击，但失败了。而这一措施在应对 SNI 阻断时十分好用。这可能说明，这套系统拥有充沛的计算资源来执行流重组。

middlebox

SNI

干扰

20 条回复 • 2024-09-10 12:39:38 +08:00

povsister

2024-09-07 16:59:52 +08:00

middlebox 常用于描述中间网络的 transparent proxy 、relay 等网络设备。一般来说对用户是不可见的。

你这个就是 gfw （

loukky

2024-09-07 17:18:26 +08:00 via Android

就是被防火墙阻断了

JensenQian

2024-09-07 17:28:53 +08:00

这不就是 steam 和 github 的那种间歇性抽风吗

ApIEfuse

2024-09-07 17:51:09 +08:00 via iPhone

Plex 好像得依赖官方的服务没法完全离线运行吧？

EMBY 可以么？

买了 plex 终身会员，难道得转战 Emby 了

whjlinyi

2024-09-07 18:37:57 +08:00 via iPhone

@sldaniel 可以离线运行的。设置-网络-无需身份验证即可获得允许的 IP 地址和网络列表

allplay

2024-09-07 19:13:38 +08:00 via Android

聪明点还可以劣化，勉强可以访问，实际用起来极其恶心，给你丢包率极高。

ApIEfuse

2024-09-07 19:54:12 +08:00

@whjlinyi
试了下配置之后所有的权限都没有了
像是个默认 guest 帐号,设置页面也和登录的不太一样,只能说能用.
最好还是得套有本地帐户系统..

zololiu

2024-09-07 19:57:28 +08:00

最近登录 Plex 越来越费力了，一些页面都要等待加载才能看到图片。

whjlinyi

2024-09-07 20:24:00 +08:00 via iPhone

@sldaniel 那只能换别的了。

kaedeair

2024-09-07 21:46:42 +08:00

我试了域名套到别的 ip 上并不会触发，只有 ip 和域名一致时才会触发

Greatshu

2024-09-07 23:06:47 +08:00

之前有人测试过，GitHub 干扰时间是 180s

Greatshu

2024-09-07 23:07:21 +08:00

https://github.com/XIU2/CloudflareSpeedTest/issues/217

Greatshu

2024-09-07 23:09:51 +08:00

注意到 clients.plex.tv 用了 cloudflare ，那就没啥说的了

MIMIC

2024-09-08 01:07:12 +08:00 via iPhone

版本升级后确实需要下载依赖包和编解码包，现在只能把几个域名分流，不然连海报墙这类信息都匹配不到，好几个朋友裸连一直出错

iamOldMaster

2024-09-08 11:56:14 +08:00

是的，我这里表现出几乎一致的情况。刮削功能时好时坏，上一分钟刮削成功的内容，再一次刮削就无结果

obeykarma

2024-09-08 13:56:18 +08:00

plex 被屏蔽的理由是？真理解不了有什么敏感的

sheayone

2024-09-08 15:58:13 +08:00

用 jellyfin 做个备份好了

outcastveron

2024-09-08 21:31:29 +08:00

@obeykarma 可能有敏感文件的刮削

AlphaTauriHonda

2024-09-09 19:34:41 +08:00 via iPhone

使用特定 SNI 后会让 IP 一段时间内被墙，一般是 TCP 严重丢包。
这套审查系统确实是新的，之前没看到别人提到，我在大概半年前观察到类似现象。

htfcuddles

2024-09-10 12:39:38 +08:00

并不是新系统，之前就有了。分光监听 DPI 后，阻断执行有 2 种方式：1.源自旁路的 TCP RST 报文 2.骨干路由上添加临时路由条目