共有サービスが取得するとアプリ別 VPN の除外設定が壊れる

一つのアプリケーションを VPN から除外しても、必要なダウンロードは失敗し続けるか、さらに悪いことに動き始めて無関係なものが止まります。見えているウィンドウがすべての接続を開くプロセスとは限らず、アプリケーションは処理をヘルパー、バックグラウンド転送サービス、まったく別のパッケージに渡すことがあります。したがってアプリ別のルールには、見慣れたランチャーのファイル名ではなく、プラットフォームの実際の ID モデルが必要です。以下の確認は観測から始まり、実際に要求を出した相手へと遡ります。

こうしたチケットでは通常、間違ったコンポーネントが除外され、その除外が後から絞り込まれることがないという二つの問題が同時に起きます。

ウィンドウではなくプロセスを見つける

失敗した操作を再現し、それが起きている間に接続を所有しているプロセスまたはパッケージを特定します。Windows ではこれはどのウィンドウにフォーカスがあるかとは別の問いです。バックグラウンド転送は独自の ID で動作するサービスが仲介することがある一方、Linux と macOS では同じ分裂がヘルパープロセスやシステムデーモンとして現れます。

三つの詳細（実行ファイルまたはパッケージの ID、接続先、ワークフローの中でそれが起きた時点）を書き留めます。開始時に失敗するダウンロードは、途中で失敗するダウンロードとは別のコンポーネントによるメタデータ取得であることがよくあります。その違いだけで、ルールに触れる前に正しい ID を選べる通常は十分です。ID がアプリではなくサービスだと判明した場合、その一つの事実がルール全体を変えるので、まずそれを確定してください。

操作が短すぎてプロセスを観測できない場合は、より大きなペイロードや遅い接続先で繰り返します。目的は再現可能な観測を一つ得ることであり、どのヘルパーが関与しているかという理論ではありません。

DNS は独自の経路として扱う

システムの名前解決は除外したアプリケーションにまったく従わないことがあり、そのため除外したブラウザーがプライベートなホスト名で失敗し続けても、そのトラフィックは正しくトンネルの外にあります。除外されたのはブラウザーであり、リゾルバーではありません。

アプリ別ルールが適用されたときにプラットフォームが DNS をどう扱うかを確認し、HTTP リクエストとは別に確認します。リゾルバーが共有サービスなら、デバイス上のすべてのアプリケーションにサービスを提供するため、検討している除外はテストしたものよりはるかに広い対象に影響します。

どのリゾルバーがどのインターフェース経由で応答したかを記録します。この一つの観測で「アプリは除外されているのに名前が解決されない」という報告の多くが解決するので、チケットと一緒に保管してください。

共有ヘルパーを広げない

共有サービスは複数のアプリケーションのために処理を行うため、一つのワークフローを直すために除外すると無関係なトラフィックも変わります。Windows の Background Intelligent Transfer Service はこの形の好例で、多くのアプリケーションが使えるインフラであり、その ID は転送を要求したアプリの ID ではありません。

その例外を追加する前に、クライアントがサポートするルールモデルと組織の要件を確認します。コンポーネントを他に何が使っているか、これから書くルールを共有プロセスではなく接続先に対して表現できるかを尋ねてください。

要件をアプリケーションの境界としてまったく表現できない場合、接続先ベースのポリシーや別の承認された設計のほうが、増え続けるヘルパー例外の一覧より理解しやすく安全なことがあります。

失敗した手順ではなくワークフロー全体をテストする

サポートされた変更の後、意図したタスクを新しいリクエストで最初から最後まで実行し、次に共有コンポーネントを使う別のワークフローを一つ実行します。広いバイパスはそこで自らを明らかにするからです。一つ目を直して二つ目を静かに壊す修正は修正ではありません。両方の結果をチケットに残し、二つ目のワークフローを明示的に名付けて、レビュー担当者が再現できるようにします。

テストは、同じ接続先、同じアカウント、同じ条件という形で小さく再現可能に保ちます。二つ目のワークフローが文書化されていない場合は、変更が安全だと判断する前に、その所有者に何に依存しているかを尋ねてください。

名前の一覧ではなく理由を残す

コンポーネント、それが提供するワークフロー、除外した理由を文書化します。目的が結びついていないヘルパー名の一覧は、二回のリリースサイクルで維持できなくなり、次のエンジニアが整理のつもりで間違った項目を削除します。

例外ごとに一行で十分です。それがなければ何が壊れるか、そのワークフローの所有者は誰か、最後にいつ検証したかという三つの項目が、謎の一覧を誰かが説明できるポリシーに変えます。