安定した OpenVPN アドレスは送信元 IP ではなく ID に従うべき

「このノート PC は 10.90.0.10 を取得する」というアドレス計画は、実は ID についての表明です。どの認証済みデバイスがそのアドレスを持てるか、ということです。そのデバイスの現在のパブリック IP はほとんど関係ありません。NAT とローミングが、ユーザーが誰であるかを変えずに IP を変えるからです。送信元アドレスに基づいて計画を立てると、最初のホテルのネットワークで壊れるルールになります。認証済み ID に基づいて立てると、移動に耐える計画になります。

サーバーが検証できるものから始め、そのうえでアドレスが何のためのものかを決めます。

アドレスより先に ID の鍵を選ぶ

デバイスごとに別のクライアント証明書を用意すると、サーバーは各メンバーに対して安定した検証可能な鍵を持てます。これは静的割り当ての最もきれいな基盤です。ユーザー単位の認証を使う配備では、代わりにユーザー名を鍵にできます。ただし構成の選択が同じフィールドに従う場合に限ります。二つのモデルを混ぜると、あるクライアントには証明書、別のクライアントにはユーザー名が一致する割り当てができ、どちらが勝つかを誰も予測できません。予約を一つ書く前に、計画がどの鍵を使うかを決めてください。

duplicate-cn では、複数の同時セッションが同じ共通名を提示できるため、一つの固定アドレスではそれらを個別に識別できません。これは ID モデルの性質であり、より良いアドレス計画で直せるものではありません。

動的範囲の外にアドレスを予約する

10.90.0.0/24 のようなサブネットトポロジーのネットワークでは、低いアドレスを名前付きメンバー用に残し、動的プールを別の範囲に置きます。固定メンバーへの割り当ては、サーバーがその ID のために選ぶファイルの中で ifconfig-push 10.90.0.10 255.255.255.0 のようになります。二番目の引数は net30 では別の意味になるため、この例はトポロジーに中立ではありません。コピーする前にトポロジーを読んでください。

プールの永続化は最近のリースを記録します。同じアドレスを返す傾向がありますが、それは利便性であり予約ではありません。永続化ファイルを所有権の記録にしないでください。ポリシーではなく接続履歴で変わるからです。

割り当ての優先順位が勝者を決める

マニュアルは順序を記しています。client-connect 中に生成された明示的な割り当ては、client-config-dir のエントリより先に有効になり得て、そのエントリは通常のプール割り当てに先行します。この順序が「固定アドレスが適用されなかった」という報告のほとんどを説明します。また、セッションごとに構成を書き込む動的アロケーターが、権威的だと思っていた静的ファイルを黙って上書きできることも意味します。

割り当てを所有する層を一つ選び、ほかの層は読み取り専用にします。どちらも決定権を主張する二つの層は、タイミングに依存する割り当てを生みます。

動的アロケーターにも同じモデルが必要

セッションごとにアドレスを配る client-connect 連携 は、アロケーターにありがちな問題を抱えた小さなアロケーターです。要求元の ID を検証し、アドレスをアトミックに予約し、サポートされた接続ごとの出力だけを出し、切断や失敗時に予約を解放する必要があります。同時要求には読み取り後の書き込みではなく、ロックかデータベース制約が必要です。後片付けをしないと、プールは再起動までアドレスを漏らし続けます。

アロケーターの状態は次の運用者が読める場所に置き、アドレスだけでなく ID からアドレスへの決定を記録します。

アドレスがポリシーか利便性かを決める

ファイアウォール規則やルートが一つのトンネルアドレスからの通信を許可しているなら、そのアドレスはアクセスポリシーに関与し、再割り当てはその許可を引き継ぎます。ID、アドレス、ファイアウォールのライフサイクルを調整するか、再割り当てできないものに規則を結び付けます。安定したアドレス指定は構成を読みやすくしますが、認証の代わりにはなりません。

計画は項目ごとに所有者を持つ台帳として書き、デバイスを廃止するときに見直します。使われていない予約こそが、誤って再利用されるものです。