两个 Mac 登录账户不会拆分 VPN 流量

同一 Mac 上的两个登录账户看上去是两个独立的世界，直到网络到来。在一个会话中启动的隧道仍可能改变另一个会话的体验，取决于哪个客户端拥有它以及伴随它的策略。先描述你需要的隔离，再选择实现它的机制。顺序很重要，因为先被选中的机制往往会围绕自身重新定义需求。

三个问题承担了大部分工作：谁的应用需要哪些私有资源、两个会话是否必须同时活跃，以及当隧道不可用时这些应用被允许做什么。

从流量出发，而不是从账户列表出发

切换账户是身份边界，不是路由边界。 macOS 会为拥有配置的账户加载 VPN 配置，但接口、它的路由以及它安装的任何系统级策略都属于这台机器。如果需求是只有一个人的应用进入公司网络，设计就必须用应用和目的地来表述，而不是用谁登录了来表述。否则第二个账户会继承第一个客户端留下的东西。

用一句话写下所需行为：一个用户的邮件和文件访问走受管隧道，另一个用户的浏览留在家庭连接上，两条路径都不继承对方的默认路由。这句话可测试；登录切换的说法通常不可测试。

配置文件通道与流量范围是两回事

Apple 支持按用户或按设备交付的受管 VPN 方案，部署指南会描述这些模型以及依赖供应商的集成。交付通道说明谁接收并拥有配置。它本身并不定义哪些流量被捕获，因为客户端实现和已配置的策略仍然决定这一点。

在已有文档说明的用户感知或应用感知模式能够表达需求的地方，那是最短路径。然后要验证实际的应用和身份，而不是信任名称：同一应用的两份副本不是两条不同的网络路径，列出某个配置文件的清单也不能保证其辅助进程被覆盖。

客户机系统是真实边界，也有真实限制

虚拟机给你一个拥有独立网络栈的独立操作系统，因此客户机可以运行自己的隧道和自有应用，而不碰宿主机的路由。这比第二个登录账户是更强的隔离，维护工作也更多。在提出之前，先判断这笔成本是否买到了你真正需要的边界。

虚拟网络模式仍需审查。客户机是桥接、位于 NAT 之后还是隔离，决定了它能到达什么、什么能到达它，而宿主应用不会因为客户机恰好连上就变成客户机应用。也要检查阻断策略，否则掉线的客户机隧道会以没人预料的方式回落到宿主机路径。

代理比用户账户更窄

一个宿主应用可以访问运行在已批准客户机或容器中的真实代理服务，这覆盖了该应用通过受支持协议实际发送的流量。它不覆盖该 Mac 账户拥有的每个进程，也不覆盖应用在代理协议之外发送的流量。

共享机器上还有一点要当心：绑定到宿主机回环的 TCP 监听器不是用户名检查。把代理限制在本机可以让它远离网络，但并不能在一个已登录的本地用户面前授权另一个用户。如果这个区别重要，就让服务的身份验证保持显式。

用两项测试证明边界

运行两条路径并分别观察。在预期账户下，打开需要私有资源的应用并确认它到达受管服务；在另一个账户下，确认普通浏览保持家庭路径。然后故意切断隧道，检查两侧的回退行为，因为大多数设计正是在这里悄悄失败。也要在同一小时内完成检查，避免变化的网络污染对比。

如果由容器或客户机运行隧道，就加第三项检查：确认其外部的原生 Mac 应用仍按设计运行。选择你能演示其范围的最简单方案，并在做这些测试之前，不要把虚拟机说成普遍必需，也不要把账户切换说成普遍充分。