VPN出口アドレス台帳は実際に何を記録すべきか

出口台帳は一覧のように聞こえるが、一覧は難しい部分ではない。難しいのは、各項目が何を主張し、誰が公開でき、その主張が真でなくなったときに何が起こるかを決めることだ。これらの提案では三つの異なるアドレスの役割が混同されており、それらを混ぜ合わせた台帳はどの問いにも確実に答えられない。一つの項目を公開から撤回までたどれば、設計要件はおのずと現れる。

一覧ではなく記録から始める

最初の問いは、いくつのアドレスを含めるかではなく、一行が何を意味するかである。クライアントがどこに接続するのか、宛先がどの送信元を見られるのか、それとも誰が台帳の割り当てを保持するのか。これらは三つの主張であり、三つの所有者と三つの故障モードがある。どれを記録するのかを示さない台帳は、検証も修正も失効もできない。意味を正しく定めることが設計作業であり、一覧は単なる出力にすぎない。

スキーマを書く前に、行の定義を書く。定義に「および」という語が必要なら、それはおそらく二つの記録が一つを装っているのだ。

似て見える三つのアドレスの役割

役割は、一つの配備が三つすべてを同時に使うことがあり、実際にしばしばそうなるため、混同しやすい。サービスは一方のアドレスで接続を終端し、もう一方のアドレスから通信を転送できるが、台帳はまったく別の第三の事実を記録する。

ホスティングブロックにはVPN出口と無関係なワークロードが並んで存在しうるので、台帳の一致は、あるアドレスがある時点で何をしているかを何も語らない。役割を名指ししない項目は、何かの証拠にはならない。役割を名指しすることこそが、記録を反証可能にする。アドレスファミリーも示すべきだ、IPv4だけを黙って対象にする台帳は、そうでないと想定する誰をも誤らせるからである。

一つの項目を公開から撤回までたどる

仮の出口を一つ取り上げて追ってみる。運用者は宣言された発効時刻にプレフィックスとその役割を公開し、利用者はそれを取得し、やがてそのアドレスは出口として機能しなくなる。各段階には規則が要る：誰が公開できるのか、プレフィックスは実際に何を対象とするのか、項目はいつ発効するのか、そしてどう撤回されるのか。撤回の経路がないフィードは、誰も最新の主張と区別できない古い主張を蓄積する。

公開する権限とラベルの正確さを分ける。組織とリソースを結びつける台帳の記録は割り当てを証明するのであって現在の利用を証明するのではなく、両者は異なる証拠を持つ異なる主張である。利用者は二つのうちどちらを信頼しているのかを知る必要がある。

訂正も定義する。顧客に再割り当てされたアドレスや、誤ったラベルで捉えられた無関係なサービスには、チケットキューの議論ではなく、修正への文書化された経路が必要だ。撤回の引き金は公開の規則と同じ文書に属する。

公開されたフィードが支えられることと支えられないこと

公開されたプレフィックス属性は定着したパターンであり、既存の例は振る舞いではなく地理や所有を記述している。VPNフィードには独自の意味論、独自の証拠規則、独自のレビュー過程が必要であり、国の一覧の名前を変えてもそのどれも得られない。ARINの台帳ガイドは、割り当ての記録が何を主張し何を主張しないかを示しており、新しいフィードは自らの主張について同じ明快さを勝ち取らねばならない。それは仕様の作業であり、再ラベルの作業ではない。

そうしたフィードが支えられるのは、ネットワーク送信元についての分類判断である。できないのは、共有アドレスの背後にいる個人を特定すること、そのアドレスからのすべての通信がトンネルを通ると証明すること、あるいは特定の要求が濫用かどうかを決めることだ。これらは三つの別々の問いであり、三つの別々の証拠要件がある。

法的な問いは仕様の外に置く

技術仕様は、提案された登録要件が合法か、比例しているか、賢明かを決着できない。その評価には実際の立法文書、影響を受ける権利、管轄、そしてデータ形式では供給できない法的分析が必要だ。形式はよく設計されていても、悪い政策を支えることがある。

仕様にできるのは、議論を具体的にすることだ。提案されたデータ、その限界、その故障モードをまず定義すれば、政策論は、参加者ごとに異なる想像をされる未定義の一覧ではなく、実際の仕組みについての議論になる。技術文書が法的な問いに貢献できるのは、せいぜいそこまでだ。