OpenVPN の /24 が想定より早くクライアントを使い果たす理由

六十台でクライアントの受け付けが止まる /24 のプールは、設計どおりに動いているのであって、ライセンス上限に達しているわけではない。net30 では、クライアントごとに仮想のポイントツーポイントリンクが与えられ、これが四つのアドレスを消費するため、256 アドレスのサブネットが支えられるのはプレフィックスが示す量のおよそ四分の一になる。問題になるのはアドレスの数ではなく割り当ての数である。プレフィックスをクライアント数として読むことが、隠れたユーザー上限を探し回る原因になる。

二つのトポロジー、二つの算術モデルがあり、そのうち片方だけが人が前提とするプレフィックスと一致する。

net30 はクライアントごとに四つのアドレスを使う

net30 は、各セッションが両端にアドレスを持つポイントツーポイントリンクとしてモデル化されるため、クライアントごとに /30 のブロックを割り当てる。そのブロックには四つのアドレスが入り、使えるのは二つだけなので、実効的なクライアント数はサブネットの四分の一になる。/24 では、サーバー自身のブロックや固定割り当てを差し引く前の時点で 64 ブロックが残る。63 前後という報告される上限は、算術がそのまま表に出たものであって、設定された最大値ではない。

サーバー自身にも割り当てが必要であり、静的なクライアントエントリは、そのクライアントが接続するかどうかに関係なくブロックを消費する。どちらも、最初のプレフィックスを変えずに動的範囲を狭める。

プールの境界はプレフィックスより重要である

サーバーディレクティブは、名指ししたサブネットより狭いプールを定義することがあり、ヘルパースクリプトは開いたプロファイルには見えない追加設定へ展開することがある。client-config ディレクトリの固定アドレスはその範囲内にあり、二度払い出すことはできない。プレフィックスが表すのは可能な最大空間にすぎず、実効プールとは稼働中の設定が実際に提供しているものだ。

設定された範囲が小さければトポロジーと同様にその上限を説明できるのだから、容量について結論を出す前に両者を比較すること。

実際にクライアントを拒否した制限を見つける

まずトポロジーと実効プールを読み、そのうえで固定割り当てと予約アドレスを勘定に入れる。アドレス空間のせいにする前に、max-clients と OpenVPN の外側にある入場制御を確認する。最後に、拒否された瞬間のサーバー自身のメッセージをそうした候補と突き合わせる。メッセージは制約を名指しし、数は候補を絞るだけである。

同時接続エラーで返る拒否と割り当てエラーで返る拒否では直し方が異なり、その間で当て推量をすると保守作業の時間枠を無駄にする。

トポロジーを変えればアドレス計画も変わる

サブネットトポロジーへの切り替えにより、各クライアントはブロックではなく一つのアドレスを持つことになり、プレフィックスが本当に小さすぎる場合には正しい判断である。クライアントのアドレスパラメータの意味も変わるため、固定した割り当てとクライアント固有のファイルはすべて、手作業で番号を振り直すのではなく導出し直す必要がある。新しい範囲を計画し、静的なエントリを移行し、それらを参照するルートを更新する。

切り替えは古い設定の別名ではない。独自のレビューを伴うアドレス計画の変更として扱い、少なくとも一台のクライアントが以前の方式のアドレスを持ち続けることを想定しておく。

マスクではなく計画からプールの大きさを決める

同時接続クライアントの数に再接続と試験のための余裕を加えてサイズを決め、選んだトポロジーでそれを収める最小のプレフィックスを選ぶ。六十クライアントの上限を解消するために /16 まで広げるのは、より大きなプライベート範囲はクライアントがすでに到達できる何かと衝突しやすいため、容量の問題をルーティングと重複の問題に置き換えることになる。

トポロジー、プール、固定割り当て、そして結果としてのクライアント上限をまとめて記録する。そうすれば、次の容量の問いは調査ではなく算術になる。