分割トンネルは、アンインストールしたアプリを今も除外している

古いアプリはなくなったのに、分割トンネルの一覧にはその項目が残っています。目に見えて壊れるものがないため、何か月もそのままになります。やがて誰かが同じフォルダに別のプログラムを入れたり、管理プロフィールが接続のたびにルールを復元したりして、誰も計画していなかった経路に通信が流れ始めます。除外は、その存在理由より長く生き延びました。

この片付けで大事なのは主に身元、つまりルールが今何を指しているのか、そして一覧を誰が所有しているのかということです。

症状：何にも一致しない除外

古い項目は通常の使用では見えません。それが見えるようになるのは三つの場合で、トンネルを通るはずだったアプリが直接出ていく、新しいプログラムが古い例外を引き継ぐ、管理プロフィールに上書きされるためクライアントが編集を保存しない、のいずれかです。どれも別々の不具合に見えますが、実はどれも同じ記録管理の問題です。どれも確認は安く、誤診は高くつきます。

ルールを消すのではなく、読むことから始めましょう。

ルールが何を識別しているかを突き止める

分割トンネルの実装は、除外を実行ファイルのパス、パッケージ名、バンドル識別子、あるいはルートといったさまざまなものに紐づけます。パスに基づくルールは、もう存在しないかもしれないファイル、あるいは今は別のファイルになっているものを指します。パッケージに基づくルールは、新しいインストールが再利用できる身元を指します。同じテキスト欄でも製品によって意味が違うため、見ているフィールドについてはクライアントの文書を読んでください。パッケージに基づく場合は、Android のVpnService ガイドが参考になります。

表示名は項目の中で最も信頼できない部分であり、しかも人が読むのはその部分です。

パスのルールとパッケージのルールは挙動が違う

アンインストールを生き延びたパスのルールは通常は無効になり、それこそが良い結果です。悪い結果はパスが再利用されることで、新しい実行ファイルが例外を黙って引き継いでしまいます。パッケージのルールはさらに別の挙動をし、製品は利用できないパッケージを無視したり、拒否したり、新しい何かがその名前を名乗ったときに名前での照合を続けたりします。

あるクライアントの前提を別のクライアントに持ち込まないでください。存在しない対象に対して自分のクライアントが実際どうするかを、できればテスト機でその状況を意図的に作り、どのプロセスが例外を引き継ぐかを見て確認しましょう。

所有者を通じて削除する

一覧が管理プロフィールから来ている場合、ローカルでの編集は一時的な変更で、次の接続時に元に戻ります。プロフィールを変更するか、所有者に頼み、編集が再接続後も残ることを確認してください。一覧がローカルなら、項目を削除し、クライアントが古い設定をメモリに残さず設定を書き直したかを確認します。

空の一覧が目的ではありません。項目が今も実際の要件に合っている一覧が目的です。

その後、両方向を試す

片付けのあと、除外されたままであるべきアプリと、今はトンネルを通るべきアプリを試します。リゾルバの方針は除外一覧とは別の制御なので、DNS の挙動は別に確認してください。復元されたプロフィールが片付けを静かに無効にする最もよくある原因なので、そのうえで一度再接続して再テストします。

残っている例外それぞれのそばに、一行の目的を書いておきましょう。その一行が一覧を博物館にせず、次の片付けを五分で終わる作業にします。