Apple TV 家庭中枢：在不破坏家居的前提下加装 VPN

多数家庭里的 Apple TV 同时承担两件事：串流播放终端，以及相当常见的、负责响应远程配件请求并运行自动化的家庭中枢。在这台设备前面加一层 VPN 本身没有问题，但视频能正常播放几乎无法证明第二件事。要做的是：记录中枢角色的基线、确认隧道究竟如何到达 tvOS，以及两项彼此独立的验收测试。下面是我采用的顺序。

第 1 步：动手之前先记录生效的中枢

在 iPhone、iPad 或 Mac 上打开「家庭」App，进入「家庭设置」，再进入「家庭中枢与桥接」。当前承担工作的设备列在最上方，Apple 的家庭中枢指南涵盖了前提条件，以及可以固定首选中枢的「自动选择」设置。

在动手改动之前，先把这个名字记下来。

如果家里由 HomePod 提供服务，那么你对 Apple TV 的改动可能毫无意义，之后通过的遥控测试也证明不了隧道的事。如果中枢就是 Apple TV，前提条件与 VPN 一样重要：已开机、已加入家庭网络、已用家庭所用的 Apple Account 登录，并且该账户已启用 iCloud Keychain 和双重认证。半途而废的设置会产生与路由错误相同的症状，而先排除它要便宜得多。

第 2 步：确认 VPN 究竟如何到达 tvOS

tvOS 的设置里没有 VPN 面板。实践中，隧道只有两种方式到达 Apple TV：一是在路由器上终结并覆盖家中每台设备；二是以描述文件的形式由管理工具推送，而这通常意味着设备处于受监管状态。如果两者都不成立，隧道就不会住在 Apple TV 上，这套方案的其余部分应当放到路由器上。

出问题时，这两种形态的表现并不相同。路由器上的隧道会同时改变所有设备的连通性，因此单个配件故障很难归因。描述文件是可以移除的对象，安装日期一目了然，所以回退只需两分钟，而不必恢复整台路由器。请有意识地选择；如果你走路由器这条路线，就把中枢测试安排在可以随时撤回、又不会吵醒全家人的时段。

第 3 步：把本地控制与远程访问分开测

本地测试在家里、在 Wi-Fi 上进行，用「家庭」App 操作一个你真正依赖的配件：打开车库门、改动恒温器的设定值、触发一条自动化。测试的标准不是「家庭」App 把磁贴加载出来，而是配件确实响应。

接着做远程测试，并且让它尽量平淡。把 iPhone 断开 Wi-Fi，确认它走蜂窝网络，然后下发一条低风险指令。不要用门锁、警报器或任何一旦出错就很麻烦的设备来测。

启用 VPN 之后，把两项测试都重做一遍，并在那一刻再次记录生效的中枢。对比期间不要动手机，因为同时在两台设备上改 VPN 设置，会把干净的结果变成一场关于归因的争论。

第 4 步：知道哪一环先出问题

当隧道干扰「家庭」时，三件事会按可预测的顺序出问题。首先是 iCloud 与推送的可达性，表现为在家一切正常、远程访问却失败。其次是 Thread 边界路由器角色，这一点只涉及第三代 Apple TV 4K 和 HomePod mini，所以 Thread 配件掉线应当指向那里，而不是 Wi-Fi。第三是本地发现：HomeKit 依赖局域网上的 Bonjour 与组播，而吞掉组播或强推自有 DNS 的隧道会破坏发现，同时让普通上网流量保持正常。

这个顺序告诉你该往哪里查。只有远程失败，指向推送与 iCloud；本地发现失败，指向局域网路径；Thread 配件消失，指向边界路由器。

这些问题都不能靠开放路由器入站端口、关闭双重认证，或为 Apple 服务添加猜测出来的例外来解决。那些做法只会扩大攻击面，几乎改变不了症状。

在需要之前先准备好回退

把先前的配置保存成一步即可恢复的形式：导出旧的路由器设置，或者让描述文件保持可移除状态。安装之前先搞清楚把描述文件从设备上移除的路径，安装之后再确认「家庭中枢与桥接」显示的生效中枢与第 1 步一致。

如果中枢角色与你的 VPN 策略确实无法共存，那就增加或保留第二个中枢，而不是接受时好时坏的控制。一条大多数时候都能触发的自动化，比一条永远不触发的更糟，因为没有人信它，也没有人修它。