VPNプールを大きくしてもセッション上限は大きくならない

/22 が保持するのは 1,024 個の IPv4 アドレスであり、この数字は容量と取り違えられやすい。これは範囲が支えられる割り当ての数を示すもので、ゲートウェイが受け入れるセッション数や転送できる通信量を示すものではない。どんな答えの背後にも三つの別々の数え方があり、それぞれ違う形で破綻する。それらを比べることによって、拒否は正しい数え方に結び付けられる。

プール、権利、作業負荷は異なる単位で、異なる担当者によって数えられる。

プールが実際に提供するもの

マスクではなく実効的な境界から始めよう。サブネットのトポロジーがサーバーの配布できるアドレス数を決め、固定割り当てと予約が一部を消費し、ネットワークアドレスとブロードキャストアドレスは使えない。/22 は原理上 1,024 を提供し、実際にはそれより少ない。これだけでも人々が期待する計算は崩れる。クライアントが到達すべきネットワークとの重複があれば、余裕がありそうに見えた範囲も除外されうる。告知する前に、割り当ての仕組みが提案した範囲を支えられることを確認しよう。

大きなプールが取り除く制約はちょうど一つである。受け入れ上限にも、ライセンスにも、転送スループットにも触れない。ルートとアクセス方針を変えずにサブネットを広げれば、誰も到達できない範囲が生まれる。

ライセンスが実際に許すもの

プラットフォームが支える同時接続数と製品の権利はさらにもう二つの数であり、しばしば一致しない。権利は利用者数、端末数、同時セッション数のいずれかを数えることがあり、これらの尺度は互換ではない。ベンダーの注文ガイドはモデルごとの違いの大きさを示しており、古いデータシートのピア数を新しい配備に持ち込むべきではない理由もそこにある。実際に運用しているサービスに適用される契約を読もう。

名前付き利用者を数えるライセンスは、プールに空きがあるというだけではより多くの端末を受け入れない。

ゲートウェイが実際に担えるもの

三つ目の数え方が作業負荷である。これらのセッションが合わせて生む通信を見積もろう。パケットレート、認証の集中、暗号化の費用、そして有効になっている方針機能である。対話的なセッションと一括転送では、同じ機器への負荷の載り方が大きく異なる。アドレスに空きがありライセンス上の受け入れも可能でも、想定した負荷が転送できる量を超えることがある。機能の組み合わせを無視した容量計画は、すべてを切った実験室でしか成り立たない数字を生む。

拒否が起きたときは、ゲートウェイがその試行について何を記録したかを見るべきである。割り当ての事象、受け入れの判断、停止した認証呼び出しのいずれかである。この三つは異なる修正を求めるので、クライアント側からの推測では正しいものを選べることは少ない。

何かを変える前に拒否を帰属させよう

有用な比較は、三つの数と観察された障害の間で行うものである。プールが満杯なら、それを広げ、それを記述するルートと方針を更新する。アドレスが残っているのに受け入れが拒否されるなら、制約は別の場所にある。セッションが受け入れられて性能が崩れるなら、問題は容量であり、二つの上限のどちらでもない。

どの数が尽きたのか、いつ起きたのか、その後何が変わったのかを記録しよう。その記録があれば、次の調査が再びサブネットマスクから始まることはない。

プールを広げるのは一行の変更であり、ルート、方針、再試験という三つの後続作業を伴う。