使用受管 VPN 的标准 Mac 用户：IT 必须承担什么

标准 macOS 账户可以整天运行企业 VPN，而 IT 保留所有特权操作。做到这一步是交付决策，而不是权限之争：选定谁安装客户端、谁创建连接，以及用户被允许改动什么。三条路线几乎覆盖所有情况，而它们的失败方式各不相同。根据设备归属和凭据类型选择路线，然后以标准用户而不是你自己的身份去验证。

三条交付路线各自决定了什么

第一条路线是由组织设备管理下发的受管配置描述文件。VPN 载荷携带网关、认证方式、路由和 DNS，并根据 Mac 的注册方式通过设备或用户通道安装。第二条路线是自助安装器：用户运行一个已批准的安装包，由它放置客户端并代为写入连接。当没有管理注册、但组织仍希望配置可重复且可审查时，这条路线可行。第三条路线是用户在系统设置中按已公布的值手工创建连接。它起步最便宜、支持最昂贵，因为客户端侧的每个错误都会变成一次求助台电话，每次变更都会变成一份备忘。

scutil --nc list
sudo profiles show -type configuration
system_profiler SPConfigurationProfileDataType

读第一份清单，看清存在哪些连接、归谁所有；读另外两份，看清作为策略安装了什么。两份清单里都没有的描述文件就是没到位，无论用户被告知了什么。

按设备归属决定，而不是按资历

组织拥有的 Mac 通常足以支撑第一条路线，因为下发 VPN 的同一条通道也能移除它，用户无法悄悄修改连接。当隧道必须在任何用户登录之前就存在时选设备通道，当连接属于个人时选用户通道。个人拥有却使用企业服务的 Mac 通常指向第二条路线。组织无法管理设备，所以安装器必须足够小、可逆，并有充分文档，使用户能够撤销。

对配置稳定的一小批技术用户，以及对在推广前测试网关的人来说，第三条路线仍然合理。低于这个规模，它就变成一套无人能盘点的、手工输入的设置。

把描述文件与账户分开

本地连接描述文件说明如何到达网关。在网关获授权的账户说明呼叫方能否进入。两者由不同的人配置、因不同的原因吊销，所以绝不要把描述文件当作授权。证书处在两者之间。随描述文件下发的证书认证设备或用户；在网关上吊销它，即使描述文件仍留在磁盘上，访问也会结束。只靠密码的设计转而依赖账户生命周期，因此交接说明必须写清两者中哪一个在起作用。

还要决定客户端是系统级 VPN 还是按应用隧道。按应用设计只路由选定的应用，并取决于客户端在当前 macOS 版本上是否支持该模式，所以在试验机上验证，而不是假定该设置会随行。

在没有管理员密码的情况下交接

用户需要启动连接、登录，并在密码变更后恢复。这些都不需要管理员账户，也都不足以成为把凭据嵌进脚本、Automator 操作或已签名安装包安装后步骤的理由。

scutil --nc start "Acme VPN"
scutil --nc status "Acme VPN"
log show --predicate 'subsystem == "com.apple.networkextension"' --last 10m

前两条命令是用户级操作，求助台可以带着人一步步执行。第三条在连接失败时读取最近的隧道活动，这才是应当索取的证据，而不是错误对话框的截图。

如果某一步仍然要求管理员批准，那就是交付缺陷：把确切的提示退回给描述文件所有者，而不是发放一个权限超过任务需要的账户。

以标准用户身份登录，然后写下退出路径

用标准账户登录、连接、到达预期的内部主机，让 Mac 睡眠、唤醒，并确认重新连接。密码变更后再重复一次，因为一半的此类部署恰恰在这里真正失败。在第一个用户需要之前写下恢复路径：描述文件缺失时怎么办、证书过期时怎么办、网关拒绝一次本来有效的登录时怎么办。把这三个答案放在求助台找得到的地方。

最后，规划移除。无法在一次操作中从离任用户的 Mac 上卸下的 VPN，就是一次即将发生的访问审查发现。