OpenVPN サーバーの nopool：明示的なプール範囲を宣言する

サーバーのヘルパーはサブネットを構成し、そのうえで独自に選んだ動的プールでそれを埋めます。この既定値は、固定割り当てのために予約する場合も将来のセグメントのために取り置く場合も、一部のアドレスを割り当てから外す必要が生じるまでは便利です。自動プールを抑止して範囲を自分で宣言するのに必要なのは、二行と、どのアドレスを割り当てに使わないかという一つの意識的な判断だけです。残りは運用上の規律であり、棚卸し、適用、検証、切り戻しです。

これは稼働中のサービスへの変更なので、運用作業として扱い、まず棚卸し、通常のライフサイクルでの適用、新しいクライアントでの検証、そして切り戻しの準備をしてください。

すでにあるサブネットから始める

現在のサーバー設定と、クライアントが実際に保持しているアドレスを読みます。プールの変更はその基準線に対してのみ意味を持ち、管理製品や設定ジェネレーターが読んでいるファイルの所有者である可能性があるため、基準線はファイルが示すとおりとは限りません。

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

有効なトポロジーを確認してください。サブネットトポロジーでは各クライアントがプールから一つのアドレスを取り、古い net30 のレイアウトはクライアントごとに小さなブロックを割り当てるので、計算はまったく異なります。サーバーがまだ net30 なら、このページは誤った移行ガイドであり、プールの数値は期待した意味を持ちません。どこかからアドレスの計算を写す前に、その行を確認してください。

サーバー自身のアドレス、クライアント設定ディレクトリ内のすべての固定割り当て、そしてルートやアクセス規則が依存するすべてのアドレスを書き出します。動的範囲の外に残すべきなのは、まさにこれらのアドレスです。先に書き出すことが、範囲を推測ではなく判断にします。切り戻しにも復元すべき具体物を与えます。

nopool を加えて範囲を宣言する

ヘルパーのキーワード nopool は、OpenVPN 2.6 のマニュアルが説明するとおり、サブネット設定を保ったまま自動の動的プールを抑止します。次に明示的な ifconfig-pool の行が、意図した両端を含む範囲を与え、そのネットマスクはサブネットと一致します。サブネットを持たないプールには意味がないので、両方の行は同じサーバーブロックに入ります。両者の順序は、サービス開始時にヘルパーがこの組を展開するため、可読性のためだけに意味を持ちます。

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

両端を含むので、例では七十一のアドレスを提供します。サーバーのアドレスとすべての固定割り当てをその範囲の外に保ち、動的範囲の内側に入る固定割り当ては接続順序に依存する衝突を生むので、これはデバッグするのに最悪の種類です。固定割り当てが増えそうなら、予約集合と範囲の間に余裕を残してください。

範囲の大きさと同時接続数は別々の制限です。max-clients が別のことを言うなら、百のアドレスは百の同時クライアントを意味しませんし、同時接続の制限より大きいプールは無駄ではなく普通のことです。大事なのは、二つの制限が既定値の継承ではなく意識的に選ばれることです。

固定割り当てを動的範囲の外に保つ

クライアント固有の ifconfig-push はプール割り当てとは別の仕組みであり、有効なトポロジーに合ったパラメーターを使わなければなりません。サブネットモードでは一つのアドレスとネットマスクであり、古い例に出てきたからという理由で net30 の組を持ち込むのはよくある誤りです。

割り当ての履歴は手がかりであって、権威ではありません。persist ファイルはどのクライアントがどのアドレスを持っていたかを覚えているので、再接続するクライアントは同じアドレスを受け取りがちですが、それはアドレスを予約せず、解放せず、固定割り当てを置き換えもしません。特定の機器が常に特定のアドレスを持つ必要があるなら、persist ファイルに頼らず固定割り当てを使ってください。

次に、アドレスに依存する経路を確認します。クライアントに押し出されるルート、サブネットを許可するファイアウォール規則、特定のホストを期待する監視チェックは、いずれも古い範囲を前提にしている可能性があります。それらを読まずにプールを変えると、無関係に見える場所へ障害が移ります。

ライフサイクルを通して適用し、それから検証する

変更は、直接ファイルを編集して再起動する場合も、ファイルを再生成する管理レイヤーを使う場合も、サービスが通常設定を受け取る方法で適用します。生成されたファイルへの手作業の編集は、次の生成までしか持ちません。次の運用者が同じ変更をどこに入れるべきか分かるように、どの仕組みがファイルを所有しているかを記録してください。その後一度再起動し、クライアントを招く前にログを読んでください。

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

これまで接続したことのないクライアントを接続し、アドレスが宣言した範囲の内側で予約集合の外側にあることを確認します。次に戻りの経路を確認し、クライアントがポリシーが許すものに到達してそれ以上には到達しないことを確かめます。計画に合っていても機能するルートがないアドレスは、成功した変更ではありません。

古い範囲のアドレスを保持していたクライアントを再接続します。新しい範囲のアドレスを受け取るはずで、古いアドレスに結びついたセッション単位の状態は消えているはずです。古いアドレスを持ち続けるなら、何か別のものが割り当てており、プールはあなたが思う所有者ではありません。

範囲変更の切り戻し

変更記録には、直前のファイルだけでなく直前の三行を残してください。それらを復元して再起動すれば割り当ては古い挙動に戻り、その後に再接続するクライアントはそこからアドレスを受け取ります。

記録には二つの注意書きが要ります。切り戻しの時点ですでに接続しているクライアントは再接続するまで現在のアドレスを保持するので、切り戻しは全台で即時ではありません。また古い範囲が固定割り当てと重なっていたなら復元は衝突も復元し、その重なりこそが変更の理由であるため、切り戻しとは別の修正が必要です。

プールの変更が完了するのは、新しいクライアントが範囲内のアドレスを受け取り、予約されたアドレスが決して配られず、それらのアドレスを使うルートと規則が意図どおりに振る舞い続けるときです。それに満たない場合は、三つのうちどれが成り立っていないかを次の人に探させることになります。