VPNのアドレス空間は割り当てで選び、隠蔽性で選ばない
ベンチマーク用、共有用、ドキュメント用の範囲には、それぞれ所有者と目的があります。VPN 空間はレジストリから選び、その後、取り除けない重複を計画します。
異例に見えるプレフィックスは、家庭とオフィスのアドレス衝突からの逃げ道のように感じられますが、たいていはそうではありません。IPv4 の特殊用途レジストリの各ブロックには所有者と目的、存在する理由があり、静かに見えるからといって一つを借りると、衝突は取り除かれず移動するだけです。これを順序として実行します。割り当てを読み、すでに重複しているものを棚卸しし、そのうえで初めて、再番号付けするのか、変換するのか、新しい空間を生成するのかを決めます。最初の二つが見つけたものに第三の手順が依存するため、順序が重要です。
範囲を借りる前に割り当てを読む
IANA の 特殊用途レジストリは、再利用可能なプライベート空間である範囲と、特定の技術的目的だけに使う範囲を分けています。プライベート利用、共有アドレス空間、ベンチマーク、ドキュメント用ブロックは表計算では同じに見えますが、ルーティングされた時点でまったく違う振る舞いをします。
| Range | Category | What it means for a VPN plan |
|---|---|---|
| 172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8 | RFC 1918 private use | Reusable by any network, so remote sites may already use the same numbers |
| 100.64.0.0/10 | Shared address space | Intended for provider-side carrier-grade NAT arrangements, not a second private pool |
| 198.18.0.0/15 | Benchmarking | Reserved for test traffic measurement; not spare production space |
| 203.0.113.0/24, 198.51.100.0/24, 192.0.2.0/24 | Documentation (RFC 5737) | Illustration only; a guide that uses them is not assigning them to you |
| 169.254.0.0/16, 240.0.0.0/4 | Link-local, reserved | Never a routed site subnet, whatever the prefix length suggests |
第二オクテットだけが異なる二つのプレフィックスは同じブロックではありません。198.18.0.0/15 はベンチマーク用の予約を伴いますが、192.18.0.0/16 はそのようなものを伴いません。予約範囲に似ているだけの番号は、その意味を受け継ぎません。この混同はよくあるため、ファイアウォール規則に届く前に二度見する価値があります。
製品が調整されたオーバーレイの中で意図的に特殊な範囲を使うことがあり、それは文書化すべき設計です。だからといって、同じ範囲が無関係な LAN の空き空間になるわけではありません。パブリック空間も隠れ場所ではありません。他人に属するアドレスへのプライベート経路は、本来の正当な宛先に向かう通信をそらします。
すでにある重複を棚卸しする
プレフィックスを選ぶ前に、トンネルから到達可能になるすべてのネットワークを列挙します。サイト、クライアントプール、クラウド VPC、パートナー接続がすべて該当し、最初の接続試行が失敗するまで人々が忘れるのはパートナー接続です。
ip -4 route show table all ip -6 route show ip -br addr ip route get 192.168.1.10
結果を一つの表にまとめ、各範囲の所有者を横に並べます。所有者を挙げられない範囲は、後で再番号付けできない範囲であり、この棚卸しが「異例な」プレフィックスについての議論を具体的な番号についての決定に変えます。避けようとしている衝突が現実か想像かを教えてくれもします。
遠隔勤務者の家庭ネットワークがオフィスの LAN と同じプレフィックスを使っている場合、その衝突は棚卸しで見え、明示的に扱えます。それはベンチマーク用ブロックが賢い選択だという証拠ではなく、そう扱うことが次の衝突を生む方法です。
プレフィックスをコピーするのではなく、一意な ULA を生成する
IPv6 は再利用の問題を、より美しい番号ではなく別の仕組みで解決します。RFC 4193 は、疑似ランダムな 40-bit のグローバル識別子を持つローカル割り当ての一意なローカルアドレスを定義し、他の誰かと衝突する可能性が非常に低いサイト用の /48 を与えます。確率は高いものの絶対ではなく、ULA プレフィックスは依然としてインターネット到達性を提供しません。
openssl rand -hex 5
十六進数の十桁は四十ビットです。先頭に fd を付け、/48 にまとめます。3f9c1a7b02 の出力は fd3f:9c1a:7b02::/48 になります。展開ごとに同じ便利な fd00::/48 を貼り付けるのではなく、サイトごとに一つ生成して記録します。
次に、経路全体が本当に IPv6 を話すことを確認します。クライアント、ゲートウェイ、ルート、プライベート DNS、サービスポリシーのすべてが一致する必要があり、トンネルにプレフィックスを割り当てても、IPv4 専用のアプリケーションがそれを使うようにはなりません。
取り除けない重複を計画する
一部の重複は恒久的で、ふつうはパートナーが再番号付けに応じず、強制もできないためです。そのときに、対応済みの仕組みを意識的に選びます。自陣での再番号付け、分離されたルーティングコンテキスト、境界での明示的な変換のいずれかです。意識的に選ぶとは、どれを選び、なぜ他の二つを退けたかを書き留めることです。そのメモこそ、将来の変更レビューが実際に読むものです。
変換は戻り経路を保たなければならず、つまり元のプレフィックスと提示するプレフィックスの両方を記録し、それらに解決するプライベート DNS 名と対応付けます。マップされた別名は一つの接続を曖昧でなくできますが、元のアドレスを世界規模で一意にはせず、二度目のマッピングなしには二人目の重複パートナーに耐えられません。
割り当てを例外とともに書き留める
各プレフィックス、その分類、所有者、選定理由を列挙した文書で締めくくります。例外は、その変換または再番号付けの規則と、誰かが承認した日付とともに加えます。インシデントの最中に誰も開かないウィキではなく、それを実装するファイアウォール規則の隣に置きます。成果物は文書そのものであり、その要約ではありません。
その記録が、次の技術者がより奇妙に見える番号を探すのを止め、この問題が数年ごとに新しい名前で再発見される理由でもあります。また、変更レビューに、プレフィックスについての意見ではなく承認できる具体物を与えます。割り当ての最後に、理由がまだ目の前にあるうちに一度だけ書きます。