名前空間内で起動した Firefox が URL を既存のインスタンスに渡した

VPN の名前空間の内側でコマンドが実行され、Firefox のウィンドウが現れ、それでもページは通常の接続から出ていきます。ルーティングの設定は、おそらく最初に作り直すものではありません。コマンドが期待したブラウザーのインスタンスを作成したのか、それとも既にどこかで動作していたインスタンスに URL を渡したのかを確認してください。この違いが結果を一手で説明し、nftables の一時間を節約します。

手がかりは、ウィンドウがコールドスタートなしで即座に現れることです。

新しいウィンドウは新しいインスタンスではない

デスクトップアプリケーションは既存のプロセスを日常的に再利用します。受け手は起動の一部ではなかったため、あるネットワーク名前空間の内側のランチャーは、既に動作中の受け手をその名前空間へ移すことはありません。Firefox のリモート制御の挙動はプロファイルに関係し、使用中のプロファイルに対して起動すると引数はその所有者に渡されます。新しいウィンドウは本物ですが、新しいネットワーク経路は本物ではありません。

プライベートブラウジングと新しいウィンドウのオプションは、ネットワーク分離の制御ではありません。

ウィンドウモードだけに影響するコマンドラインのフラグも同様です。プロファイルが使用中なら、要求はそれを所有するプロセスに渡り、そのプロセスは起動時の名前空間を保ちます。

別のプロファイルで別のインスタンスを強制する

ブラウザーが対応するプロファイルのワークフローで作成した専用プロファイルを使い、そのプロファイルを明示して起動します。対応する Firefox のビルドでは、--new-instance は既存インスタンス内のウィンドウではなく新しいインスタンスを要求します。利用できるフラグはバージョンによって異なるため、インストールされたビルド自体のヘルプ出力を確認してください。

同じ使用中のプロファイルを同時に開こうとせず、プロファイルが使用中であるという警告を、ロックファイルを削除する指示として扱わないでください。

ブラウザーは通常の非 root ユーザーでも実行してください。ネットワークの設定には管理者権限が必要なことが多く、同じ実験の一部だからといってブラウザーにも同じ権限を与えたくなります。グラフィカルなブラウザーにそれは不要であり、root で実行するとプロファイルと権限に関する別の種類の問題が生じます。特権とネットワーク経路は二つの独立した判断として保ってください。

どのプロセスが通信を運んでいるかを確認する

Linux では、プロセスのネットワーク名前空間はその名前空間リンクから見えます。要求していると考えるプロセスについてそれを読み、次に実際に要求しているプロセスについて読みます。

readlink /proc/ACTUAL_PID/ns/net

ブラウザーは複数のプロセスを実行するので、同一性が重要です。接続を作るコンテンツプロセスは、最初に調べたプロセスではないかもしれません。リンクを意図した名前空間と比較し、一つのインスタンスに帰属できる新しく無害な要求で確認してください。帰属こそが試験のすべてであり、どのプロセスが接続を作ったのか言えないなら、その名前空間を試験したことにはなりません。

名前空間が本当に間違っている場合

ときにはランチャーが実際に失敗し、新しいインスタンスが誤った名前空間で始まることがあります。ユニットやデスクトップエントリはセッションバス経由で再実行されるときに名前空間を失うことがあるため、それを生み出したサービスやラッパーを確認してください。その後、ブラウザーを責める前に、正しい名前空間の内側のシェルからもう一度試験してください。一度に一つの変数だけを動かすことが、これを診断可能に保つ唯一の方法です。

画面を共有してもリゾルバーは共有されません。

プロセスが正しい名前空間にあり、なお名前解決が失敗するなら、そのリゾルバー環境を別の問題として調べてください。別のルーティング変更では、始まる前に誤ったインスタンスへ渡された要求を移すことはできません。