共有VPNアカウント：デバイス上限はクライアント分離ではない

同時接続八台というのはライセンスページに書かれた数字であり、その八台が互いに何をできるかについては何も語らない。共有ログインはセッションごとの鍵と共存できるし、一方のクライアントの通信を平気でもう一方へ転送するゲートウェイとも共存できる。誤りは、アカウントをセキュリティ境界とみなすことだ。代わりに、何を買ったのか、何がトンネルを守るのか、ピア間で何が通ってよいのか、何がローカルリンクを落としうるのかという四つの問いを分けて立てよう。

接続の上限が実際に約束するもの

デバイス上限は、プロバイダーが一つの購読で受け入れるセッション数を数えたものだ。これは商用・運用上の制御であり、身元や分離についての表明ではない。一つのアカウントの下で機器ごとに別の証明書を発行するプロバイダーもあれば、すべての接続で同じ資格情報を使い回すところもある。違いが表れるのは失効のときで、別々の資格情報なら一台だけを切り離せるが、共有の資格情報ではその選択肢が残らない。

鍵の分離について何かを仮定する前に、プロバイダーが資格情報をどう発行するかを読もう。アカウント名そのものは何も明かさない。

ゲートウェイがクライアント間を転送するか確認する

ピア間の到達性はサーバー側の判断だ。OpenVPN では該当するスイッチが設定に現れない限り存在しないが、現代のデータプレーンオフロードは規則が適用される場所を変える。

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

その指示のない設定では、ピア間の通信はホストのファイアウォールに委ねられ、そこが依然として許可している場合がある。オフロードが有効なとき、トンネルインターフェースはユーザー空間のプロセスではなくカーネルが扱うので、ファイルを信じるのではなく規則のカウンターを確認する。トンネルアドレス間で転送される通信を遮断すると、ゲートウェイへのアクセスに触れずにクライアントを分離できる。一方のクライアントから他方のサービスへの検査で、規則の前後の両方を確認する。

ピアより先にセッションを守る

トンネルの保護とピアのアクセスは別の性質であり、強い暗号は分離を意味しない。TLSモードでは各クライアントが自分のセッション鍵を導出するので、ゲートウェイが転送していても、あるクライアントが別のクライアントの通信を読むことはできない。旧来の静的鍵の仕組みでは一つの鍵を全員で共有するため、そこでのログイン使い回しははるかに悪い結果を招く。マーケティングのページではなく設定されたモードを調べ、そのうえでアカウント共有が対象のデータに適うか判断する。

各ホストでのサービスの認証は依然として重要であり、トンネルが証明するのは、クライアントがネットワークに到達したことだけで、特定のデーモンに到達すべきことではないからだ。

ローカルWi-Fiの障害はVPNの侵害ではない

接続が切れたことはローカルリンクが失敗した証明であり、誰かがトンネルを破った証明ではない。干渉、失効したDHCPリース、ローミングの引き継ぎはいずれも、資格情報にも暗号文にも触れずにセッションを終わらせる。切断は可用性の所見として扱い、機密性やピアアクセスの所見とは切り離しておく。ローカルネットワークが信頼できない場所では、トンネルだけに頼らず通信を端から端まで守る。

上限、鍵のモデル、ピアのポリシー、ローカルリンクへの依存という四つの答えを書き留めよう。その記録が、共有アカウントへの漠然とした不安を具体的な統制に変える。