共有の出口も専用の出口も同じ書き換えを通り、ゲートウェイは送信元アドレスをプール内の公開アドレスに置き換えてポートを選びます。違いは、そのプールがどう作られているか、そしてあなたのバインディングがどれだけ生き残るかにあります。これは割り当ての判断であり、暗号化の強化ではありません。

この捉え方なら、実務的な疑問のほとんどに一度で答えられます。許可リストが気にするのはバインディングの安定性、サイトの不正検出が気にするのはアドレスの履歴であり、どちらもプランの名前には関心がありません。

どちらの選択肢も一つのアドレス上のポートマッピング

クライアントが出口を通じて接続を開くと、ゲートウェイは送信元アドレスをプールが渡す公開アドレスに書き換え、そのアドレスの空き範囲から送信元ポートを選びます。同じ出口の二人の加入者は、一つの IPv4 アドレス上の二つのポートブロックになります。遠隔のサーバーには多数の同時接続を持つ一つのホストに見え、ペイロードにはどのブロックが誰のものかという情報は一切ありません。このポートマッピングこそ、アドレスの共有をそもそも可能にする仕組みです。

専用の割り当ては、形を変えずにその話を短くします。プールはあなたのアカウント用に一つのメンバーを保持し、事業者はあなたを輪の中で回す代わりにそれを固定し、ポートはあなた自身のセッション間で共有されたままで、アドレスもデバイスにルーティングされるのではなく出口で変換されます。

つまり回線上の挙動は同一で、違うのは帳簿付けだけです。

PropertyShared poolPinned assignment
Address selected at connectAny free member of the poolThe one address bound to the account
Other subscribers on itPresent, unknown to youUsually none, though the operator may oversubscribe
Stability across reconnectsDepends on pool size and rotation policyHolds until the operator changes the assignment

許可リストが追うのはバインディングであってラベルではない

業務サービスにおける IP ベースのアクセス規則は、パケットヘッダーの一つのフィールドを確認します。そのフィールドが固定値と一致しなければならないなら、アドレスをいくつ持っていても、回転するプールは間違った道具です。固定された割り当ては、保守がアドレスを移すまで規則を満たすので、保守ポリシーは機能一覧と同じ会話に入ります。

curl -4 -s https://api.ipify.org; echo
curl -6 -s https://ifconfig.co; echo

トンネルを有効にしたまま両方の行を実行してください。一つ目は許可リストが見る IPv4 の出口を確認し、二つ目は IPv4 がトンネルを通る間に IPv6 の通信が事業者から出ていくデュアルスタックの漏れを捕まえます。両方のファミリーを受け入れるサービスは、IPv4 の結果では決して見えない理由で許可リストの確認に失敗することがあります。

次に、許可リストを必要とするアプリケーションがトンネルを使っているかを確認してください。分割トンネル、除外されたルート、プロキシ設定があればブラウザーのテストが正しく見えてもそのアプリは直接外へ出てしまい、トンネルが切れたときに通信を遮断するキルスイッチは自宅のアドレスへ静かに戻るより優れていて、許可リストを使うワークフローはまさにこうして逆方向に壊れます。

評判はアドレスとともに移動する

共有の出口は、それを使った全員の蓄積された行動を背負うため、宛先側のスコアリング、レート制限、チャレンジページはその履歴に反応します。すると通常の閲覧が、見えない理由で追加の検証に遭遇することがあります。固定されたアドレスは、寄与する人の集合をあなたのアカウントだけに狭めます。それでも、固定アドレスは再利用され、データセンターの範囲は今誰が持っていても住宅用の範囲とは違う扱いを受けることがあるため、きれいな状態で届くわけではありません。

アカウント、Cookie、ブラウザーのフィンガープリントが、今もそれらの判断の大半を左右します。

評判はプラン名に貼られた数字ではなく、経路全体の性質として扱ってください。同じ事業者の二人の顧客でも、サブネット、宛先自身のポリシー、リクエストの背後にあるアカウントによって扱いが変わります。

どちらでも変わらないこと

トンネルの暗号化は同じです。WireGuard は今も同じ鍵でハンドシェイクし、OpenVPN は今も同じ暗号スイートを交渉し、出口アドレスがその交渉に入ることはありません。固定アドレスに払うのは割り当ての挙動であり、より強い転送ではありません。

事業者からの可視性も同じままです。送信元の接続、タイムスタンプ、アカウント識別子はどちらの構成でも出口で観測可能なままで、見知らぬ人とアドレスを共有してもログ記録の方針が生まれるわけではありません。固定アドレスはセッションをまたぐより安定した識別子として働くことさえあり、専用ならより私的だという前提と矛盾します。

宛先が安定した送信元を要求するとき、ワークフローが回転を許さないとき、共有の履歴が正当な通信を何度も妨げるときは、固定を選んでください。唯一の要件が別の出口で、回転に何のコストもかからないなら、プールのままでよいでしょう。どちらの前提を信じる前に、上の二つのコマンドで結果を確認してください。自分があると思う出口とサーバーが見る出口は、間に何も書き換えるものがないときにだけ同じフィールドです。

関連記事