DPI 如何封锁 VPN

把一套过滤部署想成一连串关卡而不是一堵墙，会有帮助。一条连接先要与地址列表核对，然后其协议被分类，再然后其元数据与规则匹配，之后——可能是几小时以后——它的端点还可能被探测，以确认那里运行过什么。如果下一道关卡会抓住你，那么通过其中一道毫无意义。

这也解释了很多人感到困惑的一种经历：隧道完美运行了几周，然后在你这边什么都没改的情况下停止工作。你的流量没有任何变化。是端点在带外被识别出来，并被加进了某个列表。

最古老也最廉价的方法，是从 VPN 协议自己的握手里认出它。大多数 VPN 协议是在威胁模型还是窃听者而非分类器的年代设计的，它们在线路上明明白白地宣告自己。

对任何自称是 TLS 的东西来说，下一项检查是 Server Name Indication 字段——客户端所请求的主机名，在加密开始之前明文发送。它的存在是为了让一个 IP 地址能够托管许多站点，而实际上几乎每一套运行中的过滤系统都会读取它。

• 黑名单：如果主机名出现在列表中，连接被丢弃。大多数站点级封锁就是这样运作的。
• 白名单：如果主机名不在列表中，连接被丢弃。这激进得多，用于某些企业和国家级网络，而且要绕过它难得多。
• 一致性校验：将主机名与其解析到的地址、或与服务器出示的证书相比对。不一致会被视为可疑。

Encrypted Client Hello 是针对这一点的标准化解决方案：它加密主机名，使观察者无法读取。但它的采用还不完整，依赖于网络同样可能控制的 DNS 记录，而且在几乎无人使用它的网络里，你使用它这件事本身就是一个信号。它改善了状况，但没有关上这道关卡。

如果 TLS 本身看起来就不对，那么把隧道包进 TLS 也没用。客户端的开场消息带着一份有序的密码套件、支持的群组、签名算法和扩展列表。确切的组合因实现而异——Go 程序、OpenSSL 程序和 Chrome 产生的 Client Hello 明显不同——并且可以被哈希成一个简短的指纹。

如果一条连接自称是在与 Web 服务器对话的浏览器，却带着 Go 网络库的 TLS 指纹，仅凭这一处矛盾就足以把它分类出来。这就是为什么严肃的实现不只是「使用 TLS」：它们逐字节复现某个特定浏览器的握手，并且必须随着浏览器的变化持续这样做。

最持久的检测方法根本不对你的流量做分类。系统注意到你连接了一个陌生地址，然后自己去连接那个地址，假装成客户端。回来的东西决定判决。

1. 1

   观察

   一条通往无信誉记录、无相应 DNS 历史、且流量特征异常的地址的流，会被记录下来以备后续处理。

2. 2

   探测

   系统对该地址发起自己的连接，有时重放它从你的会话中捕获的字节，有时发送刻意构造的垃圾数据。

3. 3

   判定

   普通 Web 服务器会返回正常响应或一个 TLS 警报，并且无论收到什么乱七八糟的东西，行为都一致。一个粗糙的代理则回应得不一样——它可能卡住、立即关闭，或者以任何 Web 服务器都不会有的方式作答。

4. 4

   行动

   如果回应异常，该地址进入封锁列表，那个端口对所有使用它的人都不再可用。

防御之道是：对任何没有有效凭据的人——包括在恶意输入之下——服务器都必须真正与普通站点无从区分。这一族协议的做法是把未经认证的连接转发给一台真正的 Web 服务器，并让那台服务器来作答——于是探测者收到的是一个真实站点，因为它确实到达了一个真实站点。

与线路上发生的一切无关，地址本身也带有信誉。知名主机托管商的地址段被广泛标记为数据中心空间，某些网络会默认对其加以限制或额外验证。而公开列表中发布过的地址——由服务商发布、写在应用商店说明里、或者出现在论坛帖子中——根本不需要任何检测就能被封锁。

没有任何协议设计能解决这一点。这是地址的属性，不是流量的属性。端点轮换因此而存在，一个被广泛分享的公开端点之所以比小范围分发的端点寿命更短，原因也在这里。

封锁是显眼的，会招来投诉。放慢流量则不然。一条被分类为「疑似隧道」的流可以被整形到几百 kbps，使即时通讯勉强可用、视频彻底不可能，而看上去与一个拥塞的网络毫无二致。

从客户端一侧看，它的特征是：连接正常建立，以全速传输一小阵，然后稳定在一个低而可疑地平稳的速率上——平稳本身就是破绽，因为真正的拥塞是波动的。确认它的办法，是在同一时刻与一条通往无关目的地的对照连接做对比测量。

诚实的结论是：协议设计能很好地应对前四项，对第五项无能为力，对最后两项只能抬高成本。任何声称某个隧道「无法被检测」的说法，描述的都是一套尚未遇到过意志坚决的运营方的系统。