二つの拠点、一つのサブネット：それぞれにエイリアスビューを作る

二つの顧客拠点はどちらも 192.168.50.0/24 を使用しており、遠隔の技術者はそれぞれの同じアドレスにあるプリンターに到達する必要があります。ルーティングの小細工だけではそのあいまいさは解決しません。各拠点には固有のアドレスビューが必要であり、ゲートウェイは何かを転送する前にそのビューから拠点を選ばなければなりません。

計画は四つの部分、つまりエイリアスプレフィックス、双方向の変換、オーバーレイポリシー、そして名前からなります。それぞれが他と整合していなければなりません。

拠点ごとに一つのエイリアスプレフィックスを選ぶ

各拠点に、環境内の誰にも属さない完全なエイリアスプレフィックスを割り当てます。二拠点の計画では、拠点Aの 192.168.50.0/24 を 172.21.10.0/24 に、拠点Bの同一のLANを 172.21.20.0/24 に対応付けられます。候補は、クラウドVPCや他のVPNプールを含む参加するすべてのネットワークに対して確認します。プライベートアドレス空間はどの組織も共有しているため、範囲がRFC 1918であることは、ここで空いていることを何も意味しません。

遠隔ユーザーには、元のサブネットではなくエイリアスを公開します。元の範囲はローカルの事実のままです。

双方向に変換する

双方向に変換します。宛先マッピングは、エイリアスアドレスを所有拠点の元のアドレスに書き換えます。送信元マッピングは、遠隔の呼び出し元を他の拠点が区別できるエイリアスに書き換えます。

静的な一対一のマッピングは決定的ですが、それによって実装がステートレスになるわけではありません。逆方向の変換は接続状態に依存することがあり、フェイルオーバーや非対称な経路はそれを無視する計画を壊す可能性があります。どれが当てはまるかはプラットフォームのドキュメントが決めます。

ポリシー、セレクター、ルートが適用される正確な段階は、ポリシーベースのIPsec、ルートベースのトンネル、その他の製品で異なります。運用するものに合わせて設計してください。

計画をオーバーレイに通す

ハブでは、各エイリアスプレフィックスをそれを所有する拠点パスに割り当て、タスクに必要なトランジットだけを許可します。メッシュでは、関係するすべてのピアが同じプレフィックスとポリシーの知識を必要とします。トンネルを追加しても、あいまいなアドレス指定自体は直りません。

サブネット全体の公開は、一つのサービスの公開より広範囲です。数台のマシンやポートだけが必要なら、アクセスルールはマッピングより狭く保ってください。

ヘッダー変換はアプリケーションのペイロードを書き換えません。リダイレクト、設定ファイルに埋め込まれたアドレス、送信元ベースの権限は、いずれも元のアドレスを運び続けることがあります。pingだけでなく、アプリケーションの経路をテストしてください。ICMPの応答が返ることはマッピングの存在を証明しますが、アプリケーションがエイリアスを受け入れるかどうかは何も語りません。

各呼び出し元が見る名前を修正する

保守用の名前に、呼び出し元のビューと一致する回答を返します。遠隔の技術者がホスト名を解決する場合、その拠点のエイリアスアドレスを返すべきであり、共有の元の範囲ではありません。

最初の保守ウィンドウの前に、拠点ごとにDNSビューを確認します。元のサブネットに解決される名前は、計画が取り除くはずだったあいまいさに呼び出し元を戻します。

拠点ごとに記録して検証する

実際の呼び出し元から各拠点を個別に受け入れ、どのマシンが応答したかを確認します。元のアドレス、エイリアス、所有ゲートウェイ、許可されたサービスをまとめて記録します。

三つ目の拠点が同じ既定のLANで現れたとき、その区別を保つのはこの台帳です。ポリシーベースのIPsec NATガイドは一つの具体的な変換モデルを文書化していますが、すべてのプラットフォームに対する契約ではありません。