为什么 VPN 规则拦不住一次文件上传

一个小团队要求远程访问公司的工作系统，同时又要求某些附件不再流出公司。这两个诉求听起来像一次 VPN 变更。其实是两个执行点不同的需求，满足前者的规则对后者毫无作用。先给动作和数据命名，再选择真正能看到它们的组件。

一个诉求，两个需求

第一个需求关乎可达性：哪些用户和设备可以连接到哪个服务。第二个关乎连接建立之后的行为：哪些文档可以附加、粘贴或上传。隧道只作用于前者，从设计上对后者视而不见。

IP 层控制转发数据包。它不解析分段上传，不检查 PDF，也不判断表格里有没有账号数字。指望它做这些不是配置错误，而是范畴错误。

在寻找产品之前，先用这种句式把需求说清楚。“用户可以访问文件门户”和“用户不得把客户名单上传到文件门户”是两句话，只有第二句描述了内容策略。

选择能看到文件的组件

执行必须发生在文件可读的地方。对邮件而言，通常是邮件平台或网关，它们已经在处理附件，并能在投递前评估。对浏览器向已批准服务的上传，应用本身可能就是唯一能看到内容的一方。对受管笔记本向可移动介质复制文件，终端代理看得到这个操作。

一些商业远程访问套件会把终端代理、Web 控制和数据防泄漏模块打包在一起。这些组件确实能执行内容策略，但这种能力属于模块，而不属于隧道。在承诺结果之前，先读清楚套件到底包含什么。

一个有价值的对照模型是 Microsoft 的 Purview 数据丢失防护概览 ：它用敏感信息类型、位置和活动来描述策略。这套词汇讲的是内容和行为，而不是 IP 前缀。

TLS 会穿过隧道，所以要提前规划

应用加密在客户端与服务之间协商，VPN 隧道只是原样转发这些字节。因此路径上的网关不会自动获得分类附件的能力，无论它拥有这段路由的多大一部分。

要检查传输中的内容，需要一个用受信证书终结 TLS 的组件，这是一个重大的架构决策，自带隐私与运维后果。它不是 VPN 配置里的一个勾选项。客户端必须信任检查证书，做证书固定的应用会失效，运营方则获得了读取原本读不到的流量的能力。正因如此，这个决定属于安全负责人，而不是运行隧道的人。

所以对“VPN 能不能拦住这次上传”的诚实回答通常是不能，然后给出具体替代方案。替代方案可以是应用层限制、邮件规则或终端策略，每一项都有能改动它的负责人。

先写验收测试，再写规则

内容规则需要两个例子而不是一个：一个必须继续放行的允许动作，和一个必须被拦下的禁止动作。要在范围内的应用和设备上分别测试，因为只在某一个浏览器里生效的策略，不是任何人要的策略。

curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload
curl -sS -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://files.plant.example/upload

第一个请求应当被拥有该规则的组件拒绝，第二个请求应当成功。如果两个都成功，说明控制根本不在路径上。如果两个都失败，说明你把服务弄坏了而不是保护了它，这是没写允许示例的规则更常见的结果。

提前决定用户看到什么、谁能批准例外、管理员事后在哪里确认决定。被拦下却没有任何提示的上传会变成支持工单，没人能审计的规则会变成争吵。只要在策略上线之前写好一句话的说明文档，这两件事都能避免。

最后，把两个需求放在两张不同的工单里，交给不同的负责人。把它们捆在“VPN”名下，等于保证网络团队会被要求解决一个内容问题，并且保证隧道一连通，内容问题就被宣布解决了。