共有 PC での 一つの VPN ログイン：ルートはほかに誰が得るのか

VPN ログインが認証するのは 1 人であり、導入されるルートは別の範囲である。共有マシンでホスト全体・ユーザー単位・アプリ単位のトンネルを比較する。

ワークステーションを共有すると、一人がトンネルを認証したあとにほかに誰がそれを使えるのかという、単独利用のノート PC が答える必要のない問いが生じる。ログインが特定するのは主体であり、導入されるルートが表すのは範囲であり、この二つは同じ対象ではない。その間には OS、クライアントの設定、そしてプライベートサービスが独自に要求するものがある。適用点を比較することだけが、推測せずにこの問いに答える方法である。

一つのログイン、複数の範囲

認証が答えるのは誰が入れたかである。ルートが答えるのはどのパケットがトンネルから出られるかである。認可が答えるのはどのサービスが結果の接続を受け入れるかであり、三つのどれも次を意味しない。

ホスト全体のトンネルは一般的な既定であり、その隙間を明らかにする。ルートはカーネルの表に載るため、VPN のダイアログを一度も見ていない利用者が起動したプロセスも含め、その表を使うあらゆるプロセスがプライベートネットワークに到達できる。これはトンネルの欠陥ではなく、システム全体のルートとはそういう意味である。プライベートサービスは接続を拒否できるままであり、だからこそ 到達可能性と許可は別々の答えを必要とする。

テストの前に四つの問いを書き出しておけば、レビューがその一つに崩れるのを防げる。

境界は実際どこにあるのか

四つの構成がほとんどのマシンを覆う：ホスト全体のトンネル、ユーザー単位の接続、アプリ単位の許可リスト、そして別個のネットワーク名前空間または仮想マシンである。

どれも適用点を別の場所に置き、違いはラベルよりも重要である。ユーザー単位の接続はデスクトップのログイン画面ではなく、プロファイルの権限で適用される。アプリ単位の許可リストはクライアントの内部で適用され、何を運ぶかをクライアントが決める。名前空間や VM はインターフェースの境界で適用するため、内側のプロセスはホストのルートをまったく見られない。マシン上のログイン画面の数は、どれについても何も語らない。

ArrangementEnforced byWho can use the path
Host-wide tunnelThe routing tableAny local process using that table
Per-user connectionProfile permission listOnly the listed accounts
Per-app allowlistThe VPN client itselfOnly the selected applications
Namespace or VMThe interface boundaryOnly processes inside it

表を行ごとに読むと、本当の問いは分離があるかどうかではなく、どこで実装されているかであると分かる。

四つの適用点を比較する

Linux では、ホスト全体のトンネルはそこに現れて名前空間は現れないため、ルート表が最初に見るべきものである。二人目の利用者として検索を実行するのが人々が飛ばす手順であり、答えは本人として得たものと違い、それが報告を説明する。

次の二つの確認はルーティングではなくポリシーを見る。UID に一致するファイアウォール規則はローカルで生成された通信に適用されるため、両者がルートを共有していても同じホスト上の二人の利用者を分けられる。明示的な許可リストを持つ接続プロファイルは、有効化の際にネットワークマネージャーが適用する。どちらの確認もトンネルの変更を必要としないため、何かを再設計する前にやっておく価値がある。

ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuid

二度目の検索がトンネルのルートを示すなら、境界は設計が想定した場所にはない。

同時セッションの規則は別の制御である

ゲートウェイは 一つのアカウントが保持できるセッション数をしばしば制限し、その制限はローカルの利用者とは何の関係もない。制限されるのはアカウントであり、同じ資格情報でサインインした二人目が一人目のトンネルを終了させうる。

ローカルの分離問題と決めつける前に失敗を読む。セッション制限はゲートウェイでの切断を生み、範囲の問題は動作するが相手の通信を運ばないトンネルを生む。この二つの症状はまったく異なる修正に導く。通常は規則名が書かれているので、クライアントの正確なメッセージを残す。制限を回避するのではなく、プロファイルの所有者に承認済みの手順を尋ねる。

仮想マシンはその規則から誰も免除せず、独自のネットワークと資格情報の設計を加える。

重要な文脈でテストする

想定した利用者とアプリを試し、次に拒否されるべき文脈を試す。元のパスワードが動くことだけを示すレビューは、認証を試しただけでほかは何も試していない。

sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'

各結果のそばに適用点を記録する：ルート表、UID 規則、プロファイルの権限、ゲートウェイのセッションポリシーのいずれかである。その記録が次の変更をレビュー可能にする。また、誰かが二つ目のログイン画面に気づくたびに同じ問いが開き直されるのを止める。到達可能性は認可ではなく、どちらも分離ではない。

関連記事