VPN予約に必要な識別子はどれ？

予約がどの識別子を使うべきかは、アドレスを配布するシステム、そのシステムがレイヤー2フレームを見るかどうか、何をクライアントキーとするかの三つで決まります。DHCPを使う家庭用ルーター、ブリッジVPN、ルーテッドトンネルでは答えが異なります。識別子を選ぶほうが、アダプターが報告するあらゆるMACアドレスを固定しようとするより長持ちします（割り当て側が実際に読むのは識別子そのものだからです）。

割り当て側から始めて逆向きに考えれば、クライアント側の識別子はそのシステムが受け入れるものすべてです。

まず割り当て側に聞く

DHCPサーバーはプールから割り当て、自分が認識する識別子と予約を照合します（プロトコルのバージョンに応じて、ハードウェアアドレス、クライアント識別子の文字列、DUIDのいずれかです）。VPNサーバーは独自のプールから割り当て、設定モデルが公開するもの、多くの場合認証済みのCommon Nameと照合します。ブリッジネットワークは同じ問題を、すでにLANを提供しているDHCPサーバーに渡せます。どれも別の検索であり、一方で有効な予約は他方からは見えません。

何かを設定する前に、サーバーが実際に何を見ているかを確認します。間違った識別子を名指しした予約は静かに失敗し、クライアントはプールのアドレスを受け取るだけで、その誤りはクライアントの問題のように見えます。

MACアドレスがまだ意味を持つ場所

物理的なEthernetまたはWi-Fiリンクでは、ハードウェアアドレスがそのセグメント上のインターフェースを識別します。プライバシー機能はそれを回転させ、仮想アダプターは新しいものを作り、ノートPCはWi-Fiとドックで異なる値を示すことがあります。ルーテッドTUNトンネルはIPパケットを運び、元の無線の身元を遠隔のDHCPサーバーに伝えないため、その経路でのMACベースの予約には照合する相手がありません。 TAPは違います——Ethernetフレームを運び、レイヤー2識別子がまだ重要なブリッジドメインに参加できます。

そこでも、関係するアドレスはそのドメインで使われるものであり、自動的に物理アップリンクのものではありません。

トンネルアドレスとピアキーは独自の空間を持つ

ルーテッドOpenVPNの配備は独自のモデルでアドレスを割り当てます（認証済みの名前でキー付けされたクライアントごとの設定か、明示的なプールです）。LANルーターのDHCP予約を変えてもその割り当ては作られず、トンネルの予約を追加してもLANには影響しません。WireGuardはさらに進んでおり、ピアは公開鍵と許可されたアドレスで識別され、ハードウェア識別子では識別されません。そこでは汎用のEthernet予約がピア設定の代わりになることはありません。

デバイスの資格情報、仮想アダプター、割り当て側の識別子、割り当てられたアドレスの四つを分けて台帳に残します。物理マシン一台が複数のアダプター、アドレス、セッションを持つことがあります。

安定したアドレスは身元ではない

予測可能なアドレスは運用上便利ですが、認証の資格情報ではありません。アドレスに依存するアクセスルールは、そのアドレスが再割り当てされ、共有され、偽装された瞬間に身元確認ではなくなります。ルールがアドレスに依存するなら、再割り当てと失効を身元の所有者と調整し、本当の認証判断は別の場所に置きます。そうすれば、便利さが、どのデバイスが接続したかの唯一の証拠になることはありません。

割り当て側、識別子、割り当てられたアドレスをまとめて記録します。どれかが変わったら、残り二つが確認すべき対象です。

二つのシステムが同じサブネットに対して割り当てると主張するなら、どちらかに予約を追加する前に、どちらがそれを所有するかを決めます。