近日发现 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 阻断(如对 store.steampowered.com )的那套也不同。最明显的是,这套系统没有注入 TCP RST 报文。
楼主尝试使用 TCP 或 TLS records 分片( fragmentation )保护客户端与 clients.plex.tv
的连接免受 middlebox 攻击,但失败了。而这一措施在应对 SNI 阻断时十分好用。这可能说明,这套系统拥有充沛的计算资源来执行流重组。
1
povsister 111 天前
middlebox 常用于描述中间网络的 transparent proxy 、relay 等网络设备。一般来说对用户是不可见的。
你这个就是 gfw ( |
2
loukky 111 天前 via Android
就是被防火墙阻断了
|
3
JensenQian 111 天前 1
这不就是 steam 和 github 的那种间歇性抽风吗
|
4
sldaniel 111 天前 via iPhone
Plex 好像得依赖官方的服务没法完全离线运行吧?
EMBY 可以么? 买了 plex 终身会员,难道得转战 Emby 了 |
6
allplay 111 天前 via Android
聪明点还可以劣化,勉强可以访问,实际用起来极其恶心,给你丢包率极高。
|
8
zololiu 111 天前
最近登录 Plex 越来越费力了,一些页面都要等待加载才能看到图片。
|
10
kaedeair 111 天前
我试了域名套到别的 ip 上并不会触发,只有 ip 和域名一致时才会触发
|
11
Greatshu 110 天前
之前有人测试过,GitHub 干扰时间是 180s
|
13
Greatshu 110 天前
注意到 clients.plex.tv 用了 cloudflare ,那就没啥说的了
|
14
MIMIC 110 天前 via iPhone
版本升级后确实需要下载依赖包和编解码包,现在只能把几个域名分流,不然连海报墙这类信息都匹配不到,好几个朋友裸连一直出错
|
15
iamOldMaster 110 天前
是的,我这里表现出几乎一致的情况。刮削功能时好时坏,上一分钟刮削成功的内容,再一次刮削就无结果
|
16
obeykarma 110 天前
plex 被屏蔽的理由是?真理解不了有什么敏感的
|
17
sheayone 110 天前
用 jellyfin 做个备份好了
|
18
outcastveron 110 天前
@obeykarma 可能有敏感文件的刮削
|
19
AlphaTauriHonda 109 天前 via iPhone
使用特定 SNI 后会让 IP 一段时间内被墙,一般是 TCP 严重丢包。
这套审查系统确实是新的,之前没看到别人提到,我在大概半年前观察到类似现象。 |
20
htfcuddles 108 天前
并不是新系统,之前就有了。分光监听 DPI 后,阻断执行有 2 种方式:1.源自旁路的 TCP RST 报文 2.骨干路由上添加临时路由条目
|