Apple MDM 需要 VPN 吗？三种访问需求，一个答案

问题很少是 Apple 设备管理是否需要加密，因为它确实需要。真正的问题是：在 Mac 或 iPad 能够被管理之前，你的设备群是否需要一条通用 VPN；对大多数通过互联网纳管的部署来说，答案是否定的。Apple 让设备按自己的调度去访问管理服务，真正重要的流量是签名过的命令通道，而不是桌面会话。这对你是否可行取决于三个条件，而它们很容易被混为一谈，因为从外面看，三者都像是远程访问。

先给需求命名，再选传输方式

管理命令与配置描述文件是一种需求，交互式屏幕共享是第二种，访问私有内部应用是第三种。它们的归属不同、认证方式不同，可接受的暴露程度往往也大不相同。把它们混在一起，设备群最终就会得到一份没人能为其辩护的公开端口清单。

这三种需求并不共用同一种传输方式：

混乱通常始于一份旧的服务器检查清单。一份历史上的 OS X Server 文档列出了很长的端口集合，于是有人因为在其中某处能找到管理服务，就把它们全部在边界上做了端口转发。那不是管理架构，而且把暴露面扩展到了远超你本想发布的那层控制面。

推送通知究竟做了什么

在 Apple 记录的流程里，管理服务器发送 APNs 通知，告诉设备有任务在等它。随后设备主动连回管理服务器并索取自己的命令。推送是门铃，不是隧道：它不携带任意负载，不承载远程桌面会话，也不传递其他应用的流量。

因此设备必须已登记到预期的服务、信任预期的端点，并且能够同时访问管理服务与该流程依赖的 Apple 服务。Apple 的网络准备指南列出了这些依赖，它们不是该流程中可以协商的部分。只存在于你内网中的管理服务器，依然需要一条设备真正可用的受支持路径。把它叫作 MDM，并不会让一个不可达的端点变得可达。

把允许的路径明确写下来，包括中间的任何代理与 TLS 检查策略。一台破坏了预期证书链的检查设备，看起来会与登记失败一模一样。

什么情况下 VPN 是错的答案

如果你的管理服务以正确的证书发布在互联网上，并且每条连接都由设备发起，那么 VPN 只是多加了一跳，并没有增加任何控制。设备本来就用自己的登记身份进行认证，服务器本来就在决定接受哪些命令。在前面加一层隧道改变的是网络路径，而不是信任判断。

同一个控制面也可以下发 VPN 描述文件本身。这个顺序很重要：受管理的 VPN 配置只是作为又一份负载抵达，所以设备不需要在拿到创建它的描述文件之前就先有那条隧道。

什么情况下 VPN 是对的答案

有些设备群的管理端点本就不该从互联网可达，这是正当的设计，而不是缺乏胆量。受监管的环境、规模较小的内部 IT 团队，以及同时承载其他管理界面的服务器，常常就落在这里。在这种情况下，在管理服务前面放一条受保护的访问路径是有意为之的架构，而不是权宜之计。

屏幕共享和私有应用访问通常也属于这条线的那一侧。两者暴露的都远不止一条命令通道，也都应当拥有自己的认证，而不是搭登记身份的便车。

破坏恢复的引导陷阱

我会针对这样的故障做设计：通往管理服务的唯一路径要经过 VPN，而设备上的 VPN 描述文件或凭据已经过期。设备无法连到服务器取回替换指令，服务器也无法把任何东西推过一条起不来的隧道。此时的恢复就取决于一位可能身在数百英里之外的用户。

保留第二条独立的恢复路径，可以是一条带外管理通道、一名本地管理员，或者一个无需隧道即可访问的管理服务。趁一切正常时测试它，因为事故当中你不会得到一次干净的测试。

然后写下每条路径服务于三种需求中的哪一种，并删掉那些哪一种都不服务的端口转发。一个无需通用隧道即可管理、并且在隧道出问题时仍能修复的设备群，才是值得为之设计的结果。