Mac VPN On Demand：SSID 匹配究竟能证明什么？
SSID 匹配只是规则条件，不是信任的证据。搭好 On Demand 规则，选好未知网络的默认值，并把阻断单独留着。
除了办公室 Wi-Fi 之外到处都连 VPN，听起来只是两行策略，而真正的难点从来不是认出网络名称。难点在于决定一个匹配的名称被允许证明什么。任何接入点都能广播一个熟悉的 SSID，而对某个地址 ping 成功，只能证明一次探测得到了回应。这两种观察都无法证明这台 Mac 处在经过认证的内部网络上。
名称不是身份
SSID 是无线电发射的标签。它不是密钥、不是证书，也不是关于硬件归谁所有的声明，而一个活动场地或隔壁办公室可以在毫无协调的情况下广播同一个字符串。把标签当成关闭保护的指令，就等于把决定权交给配置了最近接入点的人。
ping 测试失败的原因更微妙：它回答的是可达性问题，而不是成员关系问题。一个会响应的目标也许从哪里都能到达，也许只能通过你正想判断的那条隧道到达，也许只是一个返回了看似应答之物的强制门户。可达性是有用的事实，却是糟糕的信任边界。
On Demand 如何评估一组规则
Apple 的 On Demand 模型把动作与可选的网络条件配对，规则按顺序评估：第一个所有条件都匹配的规则提供该动作，其余规则不再被考虑。这个顺序就是策略本身，所以「以防万一」追加的一条规则，可能悄悄改写了本来正常的行为。
SSID 条件指的是当前的主连接网络，而不是扫描中可见的每一个名称。这会带来三种不同的状态，而把它们并成两种，就是常见的配置错误：
| State | What the rule sees | What it must not be taken to mean |
|---|---|---|
| No SSID criterion applied | Nothing to compare | That the network is unknown or unsafe |
| Unknown network | Connected, name does not match | That no rule below applies |
| Recognized network | Primary network matches | That the network is trusted |
在策略所在之处配置它
经批准的 VPN 客户端或管理工作流才是这条规则该待的地方，而不同提供方暴露的可用控件子集并不相同。因此那个面板里缺少某个选项，只说明客户端没有提供它，并不说明平台无法表达它。
自动激活还需要一种无需人工就能完成的认证安排，例如证书或其他受支持的方法。保存的一次性验证码不是这种安排，而在认证无法完成时触发规则，只会产生一次在后台悄悄失败的连接尝试。
两个值得写进 runbook 的模式
第一个是仿冒名称。会议场地、酒店或同一栋楼里的租户广播了你的规则视为「内部」的字符串，保护恰恰在最不希望它关闭的地方关闭了。名称没有说谎，是规则问了一个它答不出的问题。
第二个是自我挫败的探测。脚本 ping 一个私有地址，通过隧道看到回应，就断定自己已经在内网，于是断开连接。随后探测失败，脚本重新连接并重复，隧道来回震荡，而每一步单独看都正确。结果依赖隧道的测试，无法同时决定隧道是否应当存在。
先决定默认值，再单独强制执行
未知网络的情况和有线连接的情况需要明确答案，而不是继承来的默认值。如果系统仍在判断网络类别或正在建立隧道时，受保护的流量必须保持阻断，那就需要它自己受支持的强制执行控件；On Demand 触发器提供的是连接行为，而不是阻断保证。
写对了的管理员规则会写明获批的例外、支持该例外的证据，以及证据缺失时的有意回退。认出 Wi-Fi 名称是这项决定的合法输入。它不是决定的理由，也绝不该是规则里唯一的一行。