你的 VPN 代理里还有什么？逐模块审视

把受管 VPN 代理与操作系统自带客户端相比，如果比的是隧道和隧道，一开始就比错了。安装程序通常带来多个组件，其中只有一个承载私有网络流量。其余的可能负责可见性、合规姿态、DNS 策略或终端清单，各有自己的配置与数据流。在比较任何东西之前，先索取已安装组件清单，因为产品名不等于部署。

索取组件清单，而不是产品名

对每个已安装组件，写下五项事实：用途、配置归属人、运行权限、更新方式、移除方式。这五个答案把模糊的担忧变成可审查的清单。它们也会暴露自试点以来没人看过的组件。

把隧道服务与任何独立部署的可见性、DNS 或姿态功能分开。观察流量的模块与路由流量的模块是两回事，即便它们打包在一起。

不要从标志或授权页面推断清单。要从已安装文件、正在运行的服务和真正下发给设备的配置中推断。

三个问题决定是否保留代理

第一，是否有必需的工作流依赖替代方案无法覆盖的模块？姿态检查、分离隧道的 DNS 策略和流量可见性是常见答案，而每一项的替换成本都不同。第二，哪些数据离开设备、发给谁、依据什么策略、保留多久？这个问题关乎模块的配置，而不是它是否存在。

第三，谁来维护？没人更新的模块无论方便与否都是负担。如果答案是以后再说，那么诚实的比较就是受管能力与不受管能力之间的比较。

在比较接口之前先回答这三个问题，因为更小的接口不等于更小的部署。

可见性模块记录了哪些内容，又没有记录哪些

Cisco Secure Client 中的网络可见性模块是一个有用的具体例子。其5.1 版管理指南描述了流上下文的收集，包括终端与应用相关信息，并记录了决定收集范围的收集策略。

这确立的是某一版本中某一个模块的能力。它并不确立你的组织安装过它、启用了每个字段或把结果发往某处。这些是部署事实，只有部署本身能回答。

把厂商文档当作可能性的边界，把设备自身配置当作实际发生情况的边界。

按同样的标准比较原生配置

原生配置可能是已批准且更简单的方案，也可能是丢掉某个没人想到要检查的工作流的隧道。协议兼容性、认证方式、路由与 DNS 策略、故障处理和管理要求是五个比较点，而且必须对双方都作出回答。

不要悄悄移除必需模块。为替代方案取得批准，并记录每项责任转移到哪里，因为无处转移的责任才会变成事故。

开源可得性、熟悉的厂商和更小的窗口是三件不同的事实，它们都不描述已部署配置的隐私。

在设备本身上核查清单

从已安装工件和正在运行的服务出发，而不是从电子表格出发。工件清单很短，是本地的，而且能了结策略文档了结不了的争论。

然后把发现的内容与该设备应当适用的策略对照。

systemextensionsctl list
ls /opt/cisco/secureclient 2>/dev/null
pgrep -fl vpnagentd

在 Windows 上，同样的证据来自服务、进程和厂商注册表键，模块清单通常能在安装目录中看到。收集这三份输出，附到审视中，并请责任人确认哪些组件是有意为之。当每个组件都有用途、责任人和移除路径时，代理与原生配置之间的选择就成了决定，而不是争论。