Tasker：打开私有 URL 前先连接 VPN

打开私有 URL 并指望隧道先建立起来，这是一场赛跑，而浏览器通常是赢家。对已经开始加载的页面作出反应的快捷方式，已经错过了 DNS 查询，往往也错过了第一次连接，而这恰恰是最需要 VPN 的部分。工作流程必须拥有这个顺序，而不是观察它。有三项条件决定这个流程是否应该放在 Tasker 里。

应让唯一入口拥有整个顺序

给私有服务一个经批准的入口，并让这个入口按顺序执行步骤。校验目的地、选择目标配置、请求连接、带着等待上限去等待就绪结果，然后才打开 URL。任何一步失败都要停下并说明，而不是继续落回直接打开。

人们跳过的正是最后这条。超时后仍然打开 URL 的流程，比没有自动化更糟，因为它产生的请求看起来像 VPN 失败，但实际上从未用过 VPN。

1. validate destination against the approved list
2. select the intended VPN profile
3. request connection through the client's supported interface
4. wait for readiness, maximum 20 seconds
5. open the URL only if readiness succeeded
6. on timeout, stop and report

上面的编号清单是契约，不是导出的配置。每个客户端的控制面实现都不同，有些需要插件、显式的控制权限，或一次性的用户同意，任何自动化都无法代劳。

已连接不等于已就绪

一个声称隧道已启动的状态只能证明客户端接受了请求。不能证明解析器现在返回私有地址，也不能证明目标服务可达。这些是彼此独立的结果，而它们之间的空隙，正是过早打开的快捷方式悄然失败的地方。客户端报告的是自身状态，而不是 URL 将要走的路径的状态。

就绪条件要定义在工作流程可观察的东西上。可以是客户端给出的连接状态、从预期范围内解析出的地址，或对特定服务的可达性探测，前提是该探测不会回落到普通网络路径。经由正常路由成功的探测什么也说明不了。

给等待设上限。没有超时的就绪条件会把损坏的配置变成一直挂起的快捷方式，用户会把它报告成手机卡死，而不是 VPN 问题。

Tasker 能做什么、不能做什么

Tasker 提供的是胶水：一个触发器、一份有序的动作列表、条件和一个 URL 动作。它的打开 URL 动作只执行打开这一步，别的什么都不做。连接这一步必须来自 VPN 客户端，通过插件、intent 或客户端记录并允许的公开服务。

例如，OpenVPN for Android 记录了基于 AIDL 和 intent 的远程控制接口。那是该客户端的能力，而不是设备上任何任务都可以驱动它的许可。只把控制权交给你指定的应用，因为能连接和断开隧道的自动化层，是值得保护的控制面。

如果已安装的客户端没有公开任何受支持的控制机制，诚实的答案是：这个流程无法建立在该客户端上。旧的功能对比页面并不是手机上那个版本的能力说明。

何时边界必须是强制的

自动化是便利，而便利无法强制执行安全边界。如果要求是被覆盖的应用绝不脱离 VPN 通信，请使用平台的始终开启 VPN 与拦截设置，或等效的托管配置。导航开始之后才触发的浏览器事件，无论任务安排得多仔细，都不能替代这种强制。

先决定你在做哪一种。先连接再打开的快捷方式有用，但不是保证。启用拦截的受管设备是保证，而且根本不需要 Tasker 序列。

测三种结果，而不是一种

让流程分别面对成功连接、故意超时，以及隧道断开后的正常重连。超时这一种才能揭示顺序是否真的停下，而重连这一种能揭示就绪是被检查了，还是仅仅从前一次成功里假定。先测超时，因为忽略失败的流程不值得为成功再做测试。

只允许清单内的目的地；任何来自外部的链接都要在打开前检查。接受任意链接的任务会变成启动意外 scheme 的途径，而以这种方式到达的私有管理页面，比失败的快捷方式更糟。

把配置、就绪条件和超时写在任务旁边。下一位改动 VPN 客户端的人三样都需要，而它们都无法从快捷方式图标上看出来。