按应用分流的 VPN 还是 split tunnel？Mac 路由能决定什么

两个应用向同一台办公服务器打开连接，而只应有一个走隧道。路由无法表达这个愿望，因为路由表以目的地为键，根本不包含“哪个进程打开了套接字”这一概念。人们提出的要求和真正的需求常常是两回事。在改动任何配置之前，先把这两者分开。

选择器是目的地，永远不是进程

每个路由决策都从目的地址开始，到接口结束。内核从不询问是哪个二进制程序发出的数据包，在 macOS 上 pf 也不按进程路由，因此防火墙规则无法把某个应用放到另一条路径上。正因如此，同一台服务器无论是被浏览器还是被报表工具访问，都走同一条路。所以应用级的分流必须来自路由之外的东西：拥有套接字的 VPN 插件、代应用接管连接的代理，或者独立的网络栈。这些都不是路由改动。

两个应用访问同一地址，是检验方案最干净的办法。如果两者之间的答案无法不同，那么无论叫什么名字，这个方案都是基于目的地的。

普通的 split tunnel 实际带来什么

split tunnel 为私有前缀安装路由，其余流量留在物理路径上。这通常就是请求的本意：经隧道到达办公服务器，公共浏览保持直连。它很简单，所有主流客户端都支持，并且和其他路由由同一机制强制执行。用 route -n get 检查具体目的地，而不是读默认路由，因为 split tunnel 往往不动默认路由。

手工编辑默认路由并不是转换到什么方案。它会和客户端自身的路由恢复相冲突，在安装了保护策略的客户端上，还可能让机器停留在你和客户端都没预料到的状态。应当改为在客户端支持的设置里配置 split tunnel。

macOS 上的应用级 VPN 需要什么

macOS 上真正的应用级 VPN 是由配置描述文件驱动的 Network Extension 功能。管理负载把选定的应用映射到某个 VPN 配置，系统随后据此为这些应用的流量选路。这是受管部署，意味着需要 MDM、已签名的描述文件，以及同时掌管两者的管理员。

手工安装客户端不会建立那种映射，普通设置面板也无法逐个选择应用。供应商可能公开自己的应用规则，那些规则遵循供应商的文档，而不是通用规则。

没有 MDM 时实现应用级分流的三种办法

在没有管理手段的地方，代理是务实的答案。设置应用自己的代理配置，或者使用只针对该应用、按目的地和协议选择的 PAC 文件。

本地代理终止连接并经由隧道重新发起，因此应用永远不需要路由。第二种选择是独立的网络栈：一台有自己默认路由的虚拟机或容器，应用通过本地地址访问它。第三种是接受基于目的地的路由并放弃这个要求，当两个应用都允许走隧道时，这是诚实的做法。三种都可验证，而且没有一种假装路由了解进程。

把请求写清楚，让答案不留歧义

描述工作流而不是机制：哪个应用需要哪个服务、另一个应用是否必须远离同一服务、隧道中断时应当怎样。这三个答案决定了方案。它们也告诉管理员，这个请求是路由改动还是部署项目。

把被排除的应用这一情形明确写进去。当受保护路径不可用时停止应用的客户端，与允许它回落到物理接口的客户端行为不同，用户立刻就能察觉这种差别。把预期写进工单。然后在真实机器上验证，因为同一产品在 macOS 和 Windows 上常常表现不同，而它的 macOS 文档是唯一可靠的信息来源，说明它的设置到底做了什么。