开启互联网共享，其他设备就走上 VPN 了吗？

打开互联网共享并不会把 VPN 扩展到桌面上的所有设备。这两个功能回答的是不同的问题。共享决定哪条连接为 Mac 提供网络、哪些接口把这条连接分发出去，而 VPN 决定 Mac 自身的流量走向哪里。第二台设备能否继承隧道，取决于路由、客户端的策略，以及网关愿意转发什么，这三件事共享面板一概不知道。

误区：共享连接就等于共享隧道

当有人说这样可行时，他们通常观察到的只是 Mac 后面的平板电脑加载出了一个页面。这一观察与好几条不同路径都吻合，其中包括页面直接从物理上行链路发出、而 Mac 的浏览器在走隧道的情况。一次成功加载页面说明不了任何问题。它只能证明某条路径存在。

第二台设备不会继承某个会话。它从 Mac 获取地址，把数据包发给 Mac，再由 Mac 按照自己的路由表和自己的防火墙状态决定如何处理这些数据包。这个决定是按连接做出的，而不是按设备做出的。同一个 Mac 后面的两台设备，在规则不同时可能走不同的路径。

在系统设置中，互联网共享控件要求指定一个源连接，以及其他设备将要使用的接口。源就是 Mac 的上行链路，而 Apple 自己的指南警告说，粗心的共享可能扰乱你所接入的网络。

那个对话框里没有任何一项把 VPN 指定为转发流量的网关。选择以太网作为源，既不意味着隧道被忽略，也不意味着隧道会被使用；它只意味着 Mac 的物理接口被声明为上行链路，而路由表仍然在做决定。

可用的选项还取决于硬件。没有以太网端口的 Mac，或者没有连接扩展坞的 Mac，不会提供某篇教程所假定的那个选项。在围绕它做任何设计之前，先看一看你实际拥有的面板。

下游设备隐藏在 NAT 之后，Mac 在向上游发送任何东西之前会改写它们的地址。如果那一刻隧道拥有默认路由，被改写后的数据包很可能就会走隧道，这正是这套安排在快速测试中看起来可行的原因。

看起来像并不等于策略。桌面 VPN 客户端是围绕 Mac 自身的流量构建的，它的终止开关通常为本地应用程序执行规则，而不是为机器后面的局域网执行规则。当隧道断开时，Mac 可能仍在没有任何阻断规则的情况下为它的访客继续转发。

还有版本的问题。某个在较旧 macOS 版本上记录过共享支持的供应商，此后可能已经改变了行为；而一篇在源列表里显示原生 VPN 条目的教程，描述的可能是你当前客户端根本不会创建的接口。

所以要测试路径，而不是相信设计。从第二台设备发出一个请求，并在两端观察它，因为这是唯一能在客户端更新后依然成立的证据。一个你能在下次更新后重复运行的测试，比一个你只是相信的配置更有价值。

如果第二台设备能运行已批准的客户端，那就是更强的方案。它有自己的配置文件、自己的身份和自己的策略，而 Mac 只提供底层网络。

如果它无法运行客户端，那你就需要 VPN 供应商提供的、有文档的共享功能，或者需要一台获准代表该设备转发的网关。两者都带有责任人和明确的终点，这比一个复选框能提供的东西更多。

雇主往往仍然要求按设备逐个部署的模式，因为用一台机器的会话来代表另外四台，与登记四台设备是不同的信任决定。

检查第二台设备的实际目的地，而不是 Mac 的。私有服务和公共出口是不同的测试，通过其中一个并不能说明另一个如何。

检查两种地址族和名称解析。一个把 IPv4 放进隧道、却把 IPv6 留在物理链路上的配置，会造出一台在浏览器里看起来受保护、在其他一切地方都在泄漏的设备。

然后检查断开状态。关掉隧道，从第二台设备重做测试；如果它仍能上网，那么这套安排共享的是一条连接，而从来不是 VPN——只要没人把它写成另一回事，这就是个好结果。