オンプレ接続と重複CIDRの現実解 — IPが被ったらどうするか

オンプレミスとAWSをVPNやDirect Connectで結ぶとき、意外なほど頻繁につまずくのがCIDRの重複です。既存拠点で 10.0.0.0/8 が乱立していると、AWS側でどんなにきれいに設計しても通信が成立しません。本記事では、なぜ重複が起きるのか、そして被ってしまったときの現実的な解決策を、優先順位をつけて整理します。

01なぜオンプレとAWSでIPが被るのか

CIDR重複は、設計をサボった結果というより「歴史の積み重ね」で起きます。多くのエンタープライズでは、拠点ごと・部門ごとに 10.0.0.0/8 の中から適当なレンジを切り出して使ってきました。全社的なIPアドレス管理台帳が整備されていないケースは珍しくありませんし、M&Aで別会社のネットワークを取り込んだ結果、同じ 10.1.0.0/16 が二重に存在する、といったこともよくあります。

そこへAWSを新規に接続します。VPCのデフォルト値や、Web上のサンプルをそのまま流用して 10.0.0.0/16 を切ってしまうと、オンプレのどこかで既に使われているレンジと衝突します。オンプレ側は 10.0.0.0/8 全体をまとめて経路広告していることも多く、AWSの新規VPCが最初から「被る宿命」を背負ってしまうわけです。

02被ると何が起きるか — ルーティングが成立しない

CIDRが重複すると、ルーティングテーブルが「同じ宛先」を複数の方向へ持てないため、通信が根本的に成立しません。たとえばAWS側のインスタンスが 10.1.0.5 のオンプレサーバへアクセスしようとしても、自分のVPCも 10.1.0.0/16 だと、そのパケットはVPC内部で完結してしまい、そもそもオンプレへ向かいません。ロンゲストマッチ以前に、宛先が自分の足元にあると判断されてしまうのです。

Transit Gateway(TGW)で複数VPCを集約する場合はさらに厄介です。TGWのルートテーブルは重複するCIDRを共存させられません。後から追加した重複VPCの経路はTGWルートテーブルに伝播(propagate)されず、最初に受理された経路のVPCだけが到達可能になり、もう一方は事実上「到達不能」になります。障害調査で「なぜか特定VPCだけ疎通しない」という形で表面化し、原因究明に時間を取られがちです。

03最優先の対処 — 最初から被らないVPC設計にする

もっとも安価で確実な対処は、そもそも被らないことです。VPCを新規に切る段階で、オンプレの利用実績とバッティングしないレンジを選定します。当たり前に聞こえますが、後述するNATや再採番のコストを考えれば、初期設計の一手間が圧倒的に安く済みます。

• 全社IPアドレス管理を先に決める：AWS用に 10.100.0.0/16 〜 10.199.0.0/16 のように「AWS予約帯」を明確に切り出し、拠点増設でも被らないよう台帳化します。IPAM(Amazon VPC IP Address Manager)で集中管理すると、以降のVPC払い出しで重複を機械的に防げます。
• 将来の拡張を織り込む：単一VPCだけでなく、マルチアカウント・マルチVPC・DR先リージョンまで見越して、連続した大きな帯を確保しておきます。後から飛び地でレンジを足すと管理が破綻します。
• 172.16.0.0/12 も選択肢に：10.0.0.0/8 が拠点で乱立している環境なら、比較的空いていることの多い 172.16.0.0/12 帯へAWSを寄せるのも有効です。

アカウントとネットワークの初期方針は、後戻りが効きにくい領域です。アカウント初期設定や設計ガイドラインとあわせて、接続前に固めておくことを強くおすすめします。

04既に被ってしまったら — Private NAT Gatewayで変換する

問題は「もう被っている、いまさらVPCを作り直せない」ケースです。ここで有力なのがPrivate NAT Gatewayです。Private NAT Gatewayは、VPC内の重複しがちなレンジに対して、送信元アドレスをオンプレから見て一意な「変換用レンジ」へ付け替える(送信元NATする)役割を担います。

典型的な構成は次の通りです。まずVPCにオンプレと重複しないセカンダリCIDRを追加します。このセカンダリ帯に「ルーティング可能(routable)サブネット」を作り、そこにPrivate NAT Gatewayを配置します。ワークロードは従来どおり重複帯(非ルーティングサブネット)に置いたまま、オンプレ宛の通信だけをNAT Gateway経由に向けます。オンプレから見ると、AWSからの通信は一意なセカンダリ帯の送信元アドレスに見えるため、重複が解消され疎通します。

05Transit Gateway集約時の注意点

複数VPCをTGWで束ねる構成では、重複CIDRの扱いに特有の落とし穴があります。前述のとおり、TGWルートテーブルは重複する宛先を共存できません。同じCIDRのVPCを2つアタッチしても、経路は先勝ちで一方しか受理されず、もう一方はブラックホール同然になります。ECMPでの負荷分散もできません。

• NATはVPC内で閉じる：重複を吸収するPrivate NATは、TGWの手前(各VPC内)で完結させます。TGWに乗せる時点では既に一意なセカンダリ帯になっている、という状態を作るのが定石です。
• ルートテーブルの分離：TGWの関連付け(association)と伝播(propagation)を用途別ルートテーブルで分け、意図しない重複経路の相乗りを防ぎます。設計思想の整理にはTransit Gateway か 共有VPC かもあわせてご覧ください。
• ブラックホールルートの活用：疎通させたくない重複帯には、明示的にブラックホールルートを置いて「うっかり通る」事故を防ぎます。

マルチアカウントでVPCを量産する組織では、レンジ払い出しのガバナンスそのものが効いてきます。マルチアカウント統制の枠組みでIPAMとレンジ台帳を運用に組み込むと、そもそも重複が生まれにくくなります。

06最終手段 — 再採番という選択

NATによる変換は強力ですが、万能ではありません。双方向で全面的に重複している、多数のシステム間でフルメッシュ通信が必要、NATによるIP変換がログ追跡やアプリの動作前提と噛み合わない——such なケースでは、いっそ再採番(re-addressing)が最もシンプルで、運用が素直になることがあります。

もちろん再採番は重い選択です。ハードコードされたIP、ファイアウォールポリシー、DNS、証明書のSAN、監視の宛先定義まで、影響範囲は広く、移行と同等のプロジェクトになります。だからこそ「最終手段」ですが、逆に言えばクラウド移行のタイミングは再採番の数少ない好機でもあります。どうせサーバを載せ替えるなら、そのついでにレンジも綺麗にする、という判断が現実的な場面は少なくありません。

—まとめ

CIDR重複は、AWS接続で「あるある」の割に、後から解くと高くつく問題です。優先順位はシンプルで、(1)最初から被らないVPC設計にする、(2)被ってしまったらPrivate NAT GatewayとセカンダリCIDRで変換する、(3)双方向で全面的に被るなら再採番も選択肢に入れる——この順で検討するのが定石です。

TGWで集約する場合は、重複をVPC内で吸収してから乗せる、という原則を守れば大半の事故は防げます。接続方式そのものの選定はVPN と Direct Connectを、コスト面ではNAT Gatewayのコスト設計もあわせて確認してください。いずれにせよ、鍵になるのは「オンプレの実物の経路を先に棚卸しする」ことです。台帳ではなく現物から始めれば、多くの重複は接続前に潰せます。