VPN 辅助连接只属于一个 Wi-Fi 配置文件，而非全部

把 VPN 配置为家庭 Wi-Fi 连接的辅助连接后，一切正常，直到笔记本接入另一个接入点，隧道就一直处于断开状态。新连接是一个独立的配置对象，拥有自己的 UUID，它没有任何理由知道你为前一个连接建立的绑定。什么都没有出故障；这种关联根本从未存在过。

NetworkManager 的连接参考文档把辅助连接定义为与某个特定基础连接一同激活的 UUID。文档还指出，普通 VPN 配置文件不像基础连接那样实现自动激活。两句话指向同一个结论：关联是按配置文件建立的，每新增一个配置文件，都需要有人创建它。

辅助连接究竟是什么

基础连接有身份、UUID 和辅助连接列表。它激活时，管理器也会按顺序激活这些辅助连接，VPN 就是这样在无需手动点击的情况下跟随一个 Wi-Fi 网络的。关系存放在基础连接上，写成 UUID 字符串而不是名称。这一表示方式的选择并非偶然；正是它让关联在改名后依然有效。

关于名称的这个细节比看上去更重要。重命名 VPN 配置文件不会改动其 UUID，因此已有的关联继续有效。删除旧配置文件再导入新的，会产生新的 UUID，所有指向旧 UUID 的关联如今都指向空。

追加之前先检查现有列表。一个只带一个辅助连接的家庭配置文件不是适用于所有 SSID 的规则；它只是某个对象里的一行，切换到另一个基础连接时不会被查询。

把关联放在创建配置文件的地方

在个人电脑上，把挂接目标辅助连接变成添加每个被允许的 Wi-Fi 配置文件的一部分。这是习惯而不是功能，但这个习惯能产生一致的状态，每个网络只需一条命令或两次对话框访问。简短记下哪些网络应当承载隧道，因为这份列表就是策略。

在受管设备上，让预配流程在同一步中创建 Wi-Fi 条目及其 VPN 关联，并对已经存在的被允许配置文件施加同样的处理。单独分发 VPN 配置文件会让基础关系处于未指定状态，半个机群的笔记本用不上隧道就是这么来的。

在用户仍可在受管路径之外创建配置文件的地方，明确决定这些条目会怎样。假定它们会继承关联并不是策略；那是一种附带支持成本的期望。

为 VPN 身份变化做好规划

预配来源需要目标 VPN 的 UUID，而不是某人猜出来的显示名称。当维护用刚导入的对象替换该 VPN 时，要在同一次变更中更新预配模板和受影响的现有关联。改名不是替换，把两者当作等价，正是一个本来可用的推广在一周后失效的原因。

把 UUID 和它存在的原因放在一起。未来的工程师若在辅助连接列表里看到孤零零的 UUID，无法判断它是否仍有效，很可能在整理时把它删掉。

激活不等于强制

辅助连接请求发生在激活时刻。它不会在认证完成之前的间隙里封锁应用，也不会在隧道失败后阻断流量。这些是由不同机制提供的不同属性，把它们混为一谈，会做出一个在配置文件里看似严格、实际上却宽松的设计。

封锁直连流量是另一项功能，有自己的配置和自己的失效模式，而且必须考虑在任何隧道存在之前就必须到达网络的流量：强制门户、登录页面、端点本身。一项无法在认证前得到满足的封锁策略，会把机器锁在它恰好需要的网络之外。

把这一区分写进用户真正会读的说明里。新的 Wi-Fi 网络可以请求隧道；强制则决定连不上时是否允许任何流量外出。只被告知前半句的用户会报告设计出了问题。

用真正全新的配置文件测试

使用经过批准的测试网络和新建的基础配置文件，而不是已经可用的家庭条目。依次观察基础激活、请求的辅助 UUID 以及任何认证提示，并记录卡住时停在哪一步。在桌面登录之后才可用的密钥代理并非在每个启动上下文中都自动存在，所以重启也应纳入测试计划。然后检查目标资源与失败路径：隧道是否在应用需要之前就建立，认证失败时那个应用会怎样？

然后检查目标资源与失败路径：隧道是否在应用需要之前就建立，隧道无法认证时那个应用会怎样？这两项观察就是验收标准，而它们在配置文件本身里都看不到。