スプリットトンネリングがアプリの更新をカバーしない理由

アプリをスプリットトンネリングの除外リストに追加し、アプリはインターネットに直接到達しているのに、更新は失敗したままか、相変わらずトンネル経由でのろのろと進んでいる。除外は機能した。ただ、ダウンロードを行っているプロセスとは別のプロセスをカバーしていただけであり、現代の更新プログラムはアプリのウィンドウと同じ実行ファイルであることはまれだからだ。

誤解：アプリを除外すればその通信も除外される

アプリ単位のスプリットトンネリングは、プラットフォームに応じてプロセス、パッケージ、またはアプリのパスを照合する。ブランドや機能、ユーザーの意図を照合するのではない。アプリがダウンロードをヘルパー、共有プラットフォームサービス、またはブラウザのコンポーネントに渡すと、そのヘルパーには独自の識別子があり、トンネルを通る独自の経路がある。除外リストは、二つのプロセスが同じ製品に属していることを知らない。あなたが名前を挙げたのがどちらかだけを知っている。

つまりルールは言われたとおりに動いている。転送の所有者が誰かという前提が間違っていたのであり、修正は除外を増やすことではなく、その所有者を特定することから始まる。

転送の所有者を特定する

Android では、除外したアプリのパッケージではなく共有サービスのパッケージが更新を取得することがあり、アプリ単位の VPN ルールはソケットを開くパッケージに適用される。Windows では、更新サービスがアプリとは別の実行パスで動作することがあるため、アプリのパスに一致するルールでは取りこぼす。macOS では、特権ヘルパーやシステム更新のデーモンが転送を行い、アプリはそれを要求するだけのことがある。

証拠から所有者を特定するには、プラットフォームのネットワークアクティビティ表示、プロセスで絞り込んだパケットキャプチャ、更新コンポーネントを名指ししたベンダーのドキュメントを使う。プロセス名から推測すると、よく似た二つのバイナリを取り違え、間違った方を除外してしまう。

更新システムは作業を分割することも多い。小さなメタデータ要求でバージョンを確認し、はるかに大きなパッケージのダウンロードはコンテンツ配信ホストや別のドメインへ向かう。メタデータの確認はトンネル経由で成功しても、パッケージの転送はトンネルが別経路でルーティングするホストで止まることがある。この分割が、更新は検出されるのに決してインストールされないという不可解な報告の原因だ。アプリが開くかどうかを試すのではなく、同じ端末と同じネットワークからパッケージのダウンロードそのものをテストする。

検証は経路変更に耐える

経路を変えても TLS、発行者の識別情報、パッケージ署名の検証は置き換わらない。説明のつかない証明書警告をクリックで通過した後にだけダウンロードが成功するからといって、これらのチェックを切ってはいけない。除外した経路でだけ現れる警告は障害ではなく発見だ。迂回を広げる前に調査する。

管理された端末では、システムサービスごとに広いルールを追加するのではなく、サポートされた例外を申請する。一つの更新プログラムを直すためにすべての共有サービスを除外するルールは、元の要求をはるかに超えて迂回を広げてしまう。

更新をテストし、その後で所有者を記録する

変更後に再接続して、適用されたルールをもう一度確認するのは、トンネルが再接続するとルーティングを再構築するクライアントがあるからだ。更新サイクルを一度完全に実行する（確認、ダウンロード、検証、インストール）。確認が成功しても、経路のごく一部を証明するにすぎない。

転送の所有者、宛先ホスト、意図した経路を、スプリットトンネリングのルールと同じ場所に記録する。そうしなければ、次に更新の仕組みが変わったときに例外は静かに無効になり、引き継いだ人はそのルールがどのプロセスのために書かれたのかを知る手段がなくなる。