一つのサーバーアドレスからオフィスのプレフィックスを推測しない

与えられたアドレスから始め、それを整然とした何かに広げたくなる衝動をこらえてください。10.22.8.19 のサーバーが一台あるだけでは、オフィスが 10.22.8.0/24 を持つのか、10.22.0.0/16 なのか、散在するいくつかの /28s なのかは何も分かりません。数字が 10 で始まるからという理由で 10.0.0.0/8 を選ぶと、意図していなかった家庭内ネットワーク、コンテナの範囲、パートナーのリンクまで取り込んでしまいます。プレフィックスは取得すべき境界であり、導き出すものではありません。

プレフィックスの長さは、先頭から何ビットが有意かを示すものであり、その範囲を誰が所有するかを示すものではありません。

サーバーアドレスはネットワークではない

サーバー、サブネット、サイトは三つの異なるものです。ひとつのサービスが小さな専用サブネットに収まり、オフィスの残りが別々の範囲を占めることもありますし、意図的に単一アドレスだけを持つサービスにはホストルートがまったく適切なこともあります。サイトが別のホストへリダイレクトする、別のサーバーで認証する、アドレスが変わる、といった場合には適切ではなくなります。それらの依存関係こそが実際の要件であり、プレフィックスを入れる前に確認する価値があります。

サブネット計算機は既知のプレフィックスをマスク、範囲、ホスト一覧に変換します。ひとつのホスト名から組織の境界を推測することはできず、その出力を権威として扱うことが、無関係なネットワークまでルーティングされてしまう原因です。

承認済みのプレフィックスを尋ねる

宛先の範囲は、VPN やネットワークを運用している担当者から入手してください。複数の異なるプレフィックスや、別の場所にあるプライベート DNS サーバーがあることも多く、名前が引けなくなるまで忘れられがちです。例から再構成した範囲ではなく、所有者と日付を添えた承認済みの一覧として記録してください。一覧が長い場合、それはネットワークについての情報であり、より広い何かに要約する招待ではありません。

Mac での読み取り専用のルート照会は、気にしている宛先に向けて、いま使われている経路を示します。それは現在の挙動であり、許可ではありません。

何かを適用する前に重複を確認する

適用する前に、承認済みのプレフィックスを、家庭内 LAN、コンテナのブリッジ、仮想マシンのネットワーク、その他の VPN を含むすべてのローカル範囲と照合してください。同じ範囲がローカルにも存在する場合、オフィスへの正確なルートがあっても、そのアドレスのどの機器を指したのかは、表にそのような概念がないため分かりません。重複はルーティングの誤りというより壊れたサービスのような症状を生み、後から診断するのは困難です。

対応する所有者に、クライアント自身の設定でもサーバーが配布するルートでもかまわないので、プレフィックスを導入してもらい、再接続で復元されるようにして、誰かが一度打ち込んだコマンドに頼らないようにしてください。

ルートはアクセスではない

プレフィックスをトンネルにルーティングしても、その中のサービスへのアクセスは得られません。ゲートウェイが通信を許可し、宛先が受け入れ、戻り経路が存在する必要があり、それぞれがルートとは独立に失敗し得ます。ルートを入れたあとに目的のサービスをひとつ試し、その後で無関係なリソースが依然として拒否されることを確認してください。ファイアウォールに届くルートは、機能する接続とは同じではありません。

プレフィックスの一覧、重複の確認、所有者をまとめて文書化してください。アドレスが変わったとき、次の人に必要なのはその三つです。

プレフィックスは境界についての合意です。そう扱えば、ルートは推測ではなくなります。