サイト間VPNの前にサブネットを計画する：再番号付けかアドレス変換か

二つのオフィスがどちらも 192.168.1.0/24 を使っているのは、誰も別の計画を立てなかったからで、トンネルが何とかしてくれると期待されています。それは無理です。ルーターは同じプライベートアドレスを二つの別の場所として扱えません。これを防ぐ作業は、最初のトンネルパラメーターを入力する前に終わらせます。

忘れた範囲も含めて、すべての範囲を棚卸しする

LAN、サーバーセグメント、リモートアクセスのクライアントプール、クラウドの VPC 範囲、そしてホストが到達する必要のあるコンテナやオーバーレイのネットワークを集めます。忘れられがちなのがクライアントプールで、どちらも同じ既定値から選ばれたために、オフィスの範囲と驚くほど頻繁に重なります。管理ネットワークと帯域外のセグメントも含めます。

所有者、ゲートウェイ、目的、そしてそのプレフィックスを相手拠点から到達可能にする必要があるかを記録します。トンネルを越える必要がまったくないプレフィックスは一意である必要はなく、それを知っておけば再番号付けの作業が減ります。

IPv6 は別に扱います。計画も重なりも独立しているからです。

見慣れたアドレスではなく、プレフィックスを比較する

ホストアドレスが違う二つのネットワークでも重なることがあります。重なりはマスクの性質であって、人が覚えている数字の性質ではないからです。10.20.0.0/16 は 10.20.30.0/24 を含みます。誰が口に出そうが出すまいと変わりません。プレフィックスの組を丸ごと比較し、集約がその中の小さなネットワークと衝突しないか確かめます。だからこの確認は誰かの頭ではなく表計算に入れるべきなのです。

同じ確認は VPN 自身のクライアントプールにも、導入を予定している変換後の範囲にも当てはまります。衝突する変換範囲は元の重なりよりも悪いからです。

マスク付きのプレフィックス表で十分です。マスクのない図では足りません。

実際に越えさせるものを決める

拠点に三十のサブネットがあっても、リモートアクセスを必要とするのは一つのサービスネットワークかもしれません。その要件から始め、必要なものだけを広告します。小さな広告と一致するアクセスルールのほうがレビューしやすく、誤って広げにくいからです。使っているすべてのプライベート範囲を広告するのは、トンネルをブリッジに変える習慣です。広告が狭いほど、将来のミスの影響範囲は小さくなります。

プライベート DNS は、想定したクライアントが到達できるアドレスを返さなければなりません。広告されていない範囲や重なった範囲を指す名前は、検索が成功しても壊れたままです。

アクセスリストはトンネル設定の前に書きます。失敗した後ではありません。

再番号付けか変換か、コストを知る

一つのネットワークを再番号付けするのが通常は最も明快な長期的な対策で、予約、機器、DNS、ファイアウォールのルール、設定にアドレスが焼き込まれたあらゆるものに影響します。再番号付けが現実的でない場合の代替がアクセス範囲の変換で、送信元の同一性に加えて、アドレスをペイロードに埋め込む種類のプロトコルというコストがかかります。どちらか一つを選んでやり切ってください。半分だけ再番号付けしたネットワークは、どちらの選択肢よりも悪いからです。

どちらを選んでも、元のアドレスと提示するアドレスの両方を記録してください。その後のトラブルシューティングはどちらも必要とするからです。

戻り経路のない回避策は回避策ではありません。

受け入れテストとして経路マトリックスを使う

最後にマトリックスを作ります：ローカルプレフィックス、リモートプレフィックス、許可するサービス、戻りゲートウェイ。この表がトンネル開通時の受け入れテストであり、次のエンジニアが読む文書でもあります。ゲートウェイからではなく、選んだサブネット上の実ホストからテストします。

トンネルアドレス間の ping は、トンネルが存在することを示すだけで、その背後のアドレス計画については何も示しません。

マトリックスはトンネル設定と一緒に保管します。次の拠点追加は記憶ではなくデータから始まります。計画があれば、strongSwan の転送ガイドがゲートウェイ側を扱っています。