2台のデバイス、1つのWi-Fi、異なるVPN出口：何が決めるのか

同じ家庭用ルーターにつながった二台のノートPCが、それぞれ別のVPN出口からインターネットに出ることはあります。共有のWi-Fiはそれに何も関与していません。結果を決めるのは、トンネルがどこで動いているかと、各リクエストの経路をどのポリシーが選ぶかです。逆の思い込みも同じくらい一般的で、同じくらい誤りです。別々のプロファイルを持つ二台のデバイスが、自動的に二つの公開アドレスになるわけではありません。どちらの誤りも、一つのアドレスを三つかのように扱うことから来ています。

三つのアドレス、そのうち外に出るのは一つだけ

ノートPCにはローカルセグメントで自分を識別する自宅LANのアドレスがあり、VPNの内部で割り当てられたトンネルアドレスを持つこともあります。どちらも遠隔のサービスからは見えません。そのサービスが記録するのは、途中の変換を経たうえで最終的にパケットを送り出すデバイスの公開出口アドレスです。

ここでの混乱の大半を説明する区別を、RFC 3022 が示しています。従来の NAT は内部アドレスを公開アドレスに対応づけますが、ポート変換を使えば多数の内部アドレスが同時に一つの公開アドレスを共有できます。一つの公開アドレスと複数のデバイスを持つ家庭は後者のケースで、これはほとんどどこでも既定です。

数えるべきはプロファイルではなく公開アドレスです。トンネルアドレスが異なっても出口ポリシーが同じ二つのクライアントは、観測されるアドレスが一つになります。逆に、経路の異なる出口を持つ一つのクライアントが別のアドレスを生むこともあります。この一回の比較がテストのすべてです。それ以外は遠い側についての推測にすぎません。

二つの出口が本当に別になる条件

インターネットに出る直前の最後のデバイスが、その通信に別の公開アドレスを使っていれば、出口は別です。VPN が別の場所で終端している、出口プールが別のアドレスを割り当てている、プロバイダーが別の出口経由でルーティングしている、のいずれでも起こります。三つとも遠い側で決まるポリシーの判断であり、家庭用ルーターからはどれも見えません。

同じプロファイルでそれぞれ自分のクライアントを動かす二台のデバイスは、たいてい同じプールに入り、同じセッションでは同じ出口を受け取ることがよくあります。これは不具合ではなく、共有プールの正常な挙動です。別々の出口を得るには、クライアントを二回設定するのではなく、サービスに別々の割り当てを求めるのが普通です。

保証を前提に設計する前に、同時接続に関するサービス条件を読んでください。二回目のログインは接続の許可であって、専用アドレスの約束ではありません。条件に何も書かれていなければ、勝手に決めずにプロバイダーに尋ねてください。この答えは、どのクライアント設定よりも設計を大きく変えます。

別々のプロファイルが別々の出口にならない理由

プロファイルが示すのは VPN への到達方法と認証方法であり、その後に何が起きるかはほとんど語りません。出口を選ぶのは遠い側で、ルーティング、アドレスプール、変換ポリシーはそこにあります。プロファイルを二台目に複製しても、複製されるのはクライアント設定であって、サーバーの判断ではありません。

逆も成り立ちます。ルーティングと変換ポリシーがそう作られていれば、一台の VPN サーバーが複数の公開出口を提示できますし、別々のサーバーが一つの下流出口につながることもあります。つまり設定内のサーバー名の数は、アドレスの数について何も語りません。だからこそ、この答えを設定の中に探すのは間違いなのです。

信頼できる答えは、使うつもりの構成を通したリクエストからしか得られません。それ以外は推論です。

分離をどこに置くか

ルーターのトンネルは家庭全体を覆うので便利で、その背後のすべてのデバイスに共有出口をちょうど一つ作ります。各デバイスにクライアントを置けばデバイスごとに制御できますが、すべてのデバイスを用意し、用意された状態に保つ必要があります。ポリシー対応ルーターはその中間に位置し、デバイスごとに経路を選びますが、再接続や DHCP の変化をまたいでデバイスを確実に識別できて初めて機能します。

ルーターにもう一つプライベートな DHCP リースを作っても、もう一つ公開アドレスができるわけではありません。変わるのはローカルの見え方だけで、出口はそのままです。分離は出口ポリシーの中にあり、そのポリシーがルーター側でも VPN サービス側でも同じです。

どの形を選ぶにしても、責任の所在を書き留めてください。誰がデバイスを用意し、誰がその資格情報を更新し、誰が意図した経路を使わなくなったことに気づくのか。

実際に得られた出口を確認する

意味のあるアプリケーションから確認し、両方のデバイスで同じアドレスファミリーを比較してください。片方が IPv4、もう片方が IPv6 の結果では、どちらについても何も証明できません。そのうえで再接続後にもう一度確認してください。プールの割り当てはセッション間で変わり得ます。

トンネルポリシーの内側のターミナルから実行し、ポリシーを迂回するデバイスから実行しないでください。間違ったホストは自信たっぷりの間違った答えを返します。

curl -4 -sS https://api.ipify.org; echo
curl -6 -sS https://api64.ipify.org; echo
ip route get 1.1.1.1

両方のデバイスが同じ IPv4 アドレスを表示するなら、トンネルがいくつ上がっていても出口は一つを共有しています。次に、トンネルが落ちたときの挙動を決めてください。直接経路に戻るクライアントは両方のデバイスを自宅のアドレスに戻し、分離はエラーも出さずに消えます。この構成を二つの出口と呼ぶ前に、そのフォールバックの挙動を確認してください。そして、アドレスが違うのはネットワークの結果であって、二つの匿名の身元ではないことを忘れないでください。