プライベート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の順序をまったく必要としません。

RequirementMechanism
Open the page after the tunnel is readyOrdered task with a bounded readiness wait
Never allow traffic outside the tunnelAlways-on VPN with blocking, or managed policy
Only some apps use the tunnelPer-app VPN or work-profile scope
Different URL every timeValidate the input before opening it

一つではなく三つの結果を試す

成功する接続、意図的なタイムアウト、トンネル切断後の通常の再接続に対してワークフローを実行します。タイムアウトの場合は順序が本当に止まるかを明らかにし、再接続の場合は準備完了が確認されているのか、以前の成功から単に仮定されているのかを明らかにします。タイムアウトのケースを最初に実行してください。失敗を無視するワークフローは、成功のために試す価値がありません。

承認済みリストの宛先だけを許可し、外部から届いたリンクは開く前に確認します。任意のリンクを受け入れるタスクは、予期しないスキームを起動する手段になり、そうして到達したプライベートな管理ページは、失敗したショートカットより悪い結果です。

プロファイル、準備完了の条件、タイムアウトをタスクのそばに書き留めます。次にVPNクライアントを変更する人は三つすべてを必要とし、そのどれもショートカットのアイコンからは見えません。

関連記事