マルチサイト VPN のアドレス空間をどう見積もるか

VPN サブネットをどれだけ大きくすべきかは、どのアドレスを数えているかを名指しするまで答えが出ない。ある設計では番号付きトンネルリンクの両端であり、別の設計ではポリシーベースのトンネルの背後のオフィス LAN であり、三つ目の設計では管理されたゲートウェイの予約済みインフラストラクチャである。三つの対象、三つの予算であり、サイジングの誤りの多くは、ある列を別の列の数で埋めることから生じる。

四つの役割、四つの異なる問い

外側のトランスポートはピアが接続するアドレスなので、その大きさはパブリックなアドレス計画かプロバイダーのそれに従い、背後の端末数には従わない。内部トンネルリンクは仮想インターフェースに番号を振る設計にしか存在せず、そこでは数はトポロジーの隣接関係に従う。保護された LAN のプレフィックスは実際のネットワークとその成長計画に従う。プロバイダーが予約するインフラストラクチャは、管理サービスが文書化している内容に従う。

そのうち三つ目だけが、オフィスに何台のノートパソコン があるかと関係している。この一つの混同が議論のほとんどを説明する。

電卓を開く前に、四つの役割をそれぞれ別の列として書き出す。それぞれが独自の割り当て、担当者、成長の前提を持ち、どれも他の大きさを引き継がない。番号付きの内部リンクがない設計では、その列は小さいのではなく空であり、空の列は次のレビュアーのために記録する価値のある事実である。

ブロックを数える: /30 の実際のコスト

ポイントツーポイントのリンクは二つのアドレスを必要とし、プラットフォームに依存する大きさのブロックを消費する。/30 は四つのアドレスを持ち、通常そのうち二つが使用可能なので、十二本のリンクは計画上四十八個のアドレスを消費しながら二十四個の端点を提供する。/31 は二つのアドレスを持ち、両方が使用可能であり、計算を半分にするが、両端がそれを受け入れる場所に限られる。

RFC 3021 は二アドレスモデルを定義しており、対応は両端とサービスの性質であって、善意のものではない。プロバイダーの API は内部トンネルオプションに独自のマスク要件を課すことがあり、一般的な RFC は文書化された制約を無効にしない。予算をまとめる前に、四十八と二十四というアドレス数の違いが計画の予約レンジへの収まりを決めるため、プラットフォームが何を述べているかを確認すべきである。長い一日の終わりに信じるのではなく、実際に計算すること。

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

掛け算はトポロジーが固まってから行う。十二本の個別リンクと十二人の参加者のマルチポイントオーバーレイは、同じ拠点数から大きく異なる合計を生む。

管理ゲートウェイのサブネットはクライアントプールではない

管理サービスはしばしば自身のゲートウェイインフラストラクチャ用にサブネットを予約し、そのサブネットはクライアントに渡されるのではなくサービスが消費する。文書化された大きさがあり、ときに文書化された名前もあり、接続する利用者数とは関係がない。これを遠隔端末のアドレスプールとして扱うと、最初の忙しい朝に枯渇する設計になる。

プロバイダーの要件は、ラックユニットを扱うように固定費として読む。保護されたプレフィックスの予算には含まれない。

同じ読み方は名前にも当てはまる。文書化された目的がゲートウェイインフラストラクチャであるサブネットは、そのサービスでは慣習上インフラストラクチャであり、自前の方式に合わせて改名することは図を改善するどころか配備を壊す。プロバイダーの名前と大きさを保ち、自前の番号計画は自分が制御する部分に使う。

第二の拠点を生き延びるように計画を文書化する

一人の技術者の頭の中に住む計画は、オフィスのプレフィックスと家庭用ルーターの既定レンジが最初に重なった時点で破綻する。割り当てを所有者とともに公開し、各リンクのどちらの端がどのアドレスを割り当てるかを明記する。ルートやセレクターは依然として広告する必要があり、内部リンクに番号を振るだけでは LAN は公開されない。

各ブロックの背後にある成長の前提を記録すべきである、それが後の読み手にとってアドレスだけからは再構成できない部分だからだ。

次に、すでに使っているプレフィックスで現れる拠点、遠端を別の誰かが管理するリンク、プロバイダー要件が最初に文書化したものと異なる地域という厄介な事例で計画を試す。どれかが再設計を強いるなら、手元にあったのは方針ではなく図である。それらを生き延びる計画は、トンネル設定の隣のリポジトリに置けるほど短く、次の担当者はまさにそこを探す。