二つ目のブラウザを開いても二つ目のVPN経路はできない

ブラウザが二つ、ウィンドウが二つ、一つは仕事のアカウント、もう一つは個人のアカウントで、これで別々の経路を通るはずだという前提がある。そうはならない。プロファイルの分離はCookieを別々に保つが、経路の決定はブラウザより下で行われ、どのプロファイルが要求したかを知らない。二つ目の経路にはそれを選ぶルールが必要で、そのルールが置ける場所はごく限られている。

状態の分離は経路の分離ではない

ブラウザのプロファイルが隔離するのは保存領域である：Cookie、履歴、拡張機能、ときに資格情報が含まれる。その隔離は一つのプロセスツリーの内部で強制されるもので、どのインターフェースがパケットを運ぶかについては何も言えない。

プライベートウィンドウは見た目では先に進むが、経路では一歩も進まない。ブラウザが送るものは、ソケットとネットワークの間で何かが変えない限り、いまもOSが選んだ経路から出ていく。保存領域の隔離とネットワークの隔離を混同すると、どのブラウザベンダーも約束しておらず、どのテストでも満たせない期待が生まれる。

実際に経路を選ぶもの

別の経路を選べるものは四つある：実行ファイルやパッケージに一致するアプリ単位のVPNルール、ブラウザまたはシステムの内部に設定したプロキシ、ネットワーク名前空間またはコンテナ、そして二台目の物理デバイスだ。どれも現実の何かを変え、どれにもコストがある。

アプリ単位のルールは、VPNサービスがパッケージ一覧を受け取るモバイル環境ではよくある答えだ。デスクトップではクライアント次第で、実行ファイルに一致するルールはそのファイルが開くすべてのプロファイルを覆う。二つのプロファイルに本当に別の経路が必要なら、通常は二つのタブではなく、異なる識別子を持つ二つのプロセスが要る。だから共有のブラウザ導入がプロファイル単位の設計の境界になることは決してない。

アプリ層のプロキシはさらにもう一つの仲介者を足す

ブラウザのプロキシ設定は確かに別の経路を作るが、プロキシを運用する相手との別の信頼関係も同時に作る。一つのプロファイルにとっては正当な取り決めであり、デバイス全体の保護と同等ではない。

プロキシは意図して選ぶべきだ：同じホスト上のSOCKSリスナー、トンネル内部の認証付きプロキシ、あるいは遠隔のサービスである。プロキシをフルトンネルVPNと混ぜると、障害の種類が掛け算になる入れ子の経路ができる。

各ブラウザの実際の要求を確かめる

同じ要求を各ブラウザから送り、設定画面を比べるのではなく、観測された出口アドレスを比べる。設定したプロキシが黙って接続に失敗するのは、既定の経路に戻ってしまう非常によくある形だ。

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --proxy socks5h://127.0.0.1:1080 https://api.ipify.org
dig +short example.com

次に、プロキシを強制した状態とトンネルを落とした状態で同じ要求を繰り返し、どの層が実際に通信を運んでいるかを見る。DNSの応答も記録しておく、独自の暗号化リゾルバを持つブラウザは、システムの経路を完全に迂回しても期待したページを表示できてしまうからだ。

意図した対応を二行で書き留める：どのプロセスがどの経路を使い、それぞれを誰が所有するのか。アカウントの身元も視野に入れておく、二つの経路があっても、同じログインが両方の宛先に提示されることは止まらないからだ。次のブラウザ更新のあとに再試験する、プロキシ設定は失われやすく、気づきにくいからだ。