こんにちはnagisa_53です。
重複した IP アドレス範囲を持つネットワーク間接続については、以下のAWS公式ブログが参考になりますが、VPCとオンプレミス接続に特化した場合にどうなるかを整理しておきたかったので、検証結果と合わせて記載していきます。
前提
IPアドレス重複が発生する場合、対処することで構成は複雑になり、管理負荷も上がります。そのため、まず最初に考えるのは、IPアドレスのリナンバリングやなど、通信対象間でそもそも重複しないようにできないか、です。
ただ、既に稼働中の環境間接続など、接続せざるを得ないケースは時折発生します。
今回はどうしても重複せざるを得なかった場合に取り得る構成例を整理していきます。
パターン
IPアドレスが重複するケースにおいては、以下のパターンが考えられます。
| 通信方向 | 方向 | パターン名 |
|---|---|---|
| 一方向 | オンプレミス→AWS方向のみ | パターンA |
| 一方向 | AWS→オンプレミス方向のみ | パターンB |
| 双方向 | - | パターンC |
それぞれのパターンで取りうる構成について整理していきたいと思います。
パターンA：オンプレミス→AWS方向のみ
構成としては以下のようにAWS PrivateLinkを利用した接続が考えられます。
オンプレミスと図中の「業務VPC」はIPアドレスが重複しているため、直接接続できません。
そのため、AWS Direct ConnectもしくはAWS Site-to-Site VPNを経由して直接接続するためのVPC（今回はInterface VPCと命名）を準備します。簡略化のために直接VPC間を接続していますが、AWS Transit Gatewayを挟む形でも問題ありません。
Interface VPCと業務VPC上のServer@AWSへの接続はPrivateLinkを利用します。
今回はNetwork Load Balancer（NLB）を宛先Amazon EC2の手前に配置する形としていますが、Resource configuration、Resource gatewayを利用する構成とすることも可能です。
今回は簡易化のために単一AZ風の図になっていますが、PrivateLinkのエンドポイントサービスとエンドポイントは同一AZ ID（≠AZ名）上に存在する必要があるため、実構築時は考慮が必要です。※パターンBも同様
パターンB：AWS→オンプレミス方向のみ
こちらもPrivateLinkを利用した構成が考えられます。
オンプレミスが宛先でPrivateLinkが利用可能？と思われる方もいらっしゃるかもしれませんが、Interface VPCにNLBを配置し、NLBのターゲットとしてオンプレミスのサーバーを指定（IPアドレスで指定）することで実現が可能です。
他にもPrivate NAT Gatewayを利用した方法も考えられそうですが、技術的には実現できそうなもののPrivateLinkがUDPにも対応した今、コスト面や構成の複雑さから、そちらを選択する理由はあまりないのではと思います。
パターンC：双方向通信が必要
通信対象が限られている場合、パターンA + Bを組み合わせる方法が良さそうです。
ただ、通信対象が多くNAT対象を一元管理したい場合は、双方向で1対1NATを行いたい場面が出てくるかもしれません。その場合、以下のような形が取れるかと思います。
（オンプレミスとの間の接続にTrangit Gatewayを挟んだ上でセカンダリCIDRを利用し、AWS側のVPCを1つにまとめるなどはできそうな気がするのでこちらはあくまで一例です。）
通信対象環境の重複するアドレス帯（10.0.0.0/24）に1対1でマッチするアドレス帯（こちらは重複不可）を双方向に準備し（図中の192.168.0.0/24, 192.168.2.0/24）、双方の環境で送信元、宛先共に1対1でNATすることにより疎通を可能にします。
上記の図の例だと、オンプレミス側の"10.0.0.10"のIPアドレスが紐付くサーバは変換用アドレスとして"192.168.0.10"が割り当てられ、AWS側の"10.0.0.10"のIPアドレスが紐付くサーバは変換用アドレスとして"192.168.2.10"が割り当てられる形になります。
オンプレミス側からAWS側の"10.0.0.10"のIPアドレスが紐付くサーバに通信を行いたい場合は、"192.168.2.10"を送信先として指定し、その逆のケースの場合は"192.168.0.10"を送信先として指定します。
NAT処理は、オンプレミス側はCustomer Gateway、AWS側はEC2でiptables等のOS機能を利用、もしくはNW機器の仮想アプライアンスを利用するなどの選択肢があるかと思います。
が、理論上はできそうなものの構成が複雑になる（対象障害性を考えた場合には更に複雑になる）ため全くお勧めはしません。このパターンを採用する前に、アドレス帯として100.64.0.0/10（RFC 6598）を利用する案などを含め、NATを使用しないで済む方法を改めて検討することをお勧めします。
実際にやってみた
パターンA/Bについて実際に環境を構築してみました。
前提
今回は、以下の前提で構築しています。
- オンプレミス環境が準備できなかったので、オンプレミスを模したVPC（オンプレミスVPC）を利用する形とします。構築には以下を利用させていただきました。（オープンソースのVPN製品であるstrongSwanを構築するためのCloudFormationテンプレートが提供されており、大変助かりました。）
- 接続プロトコルとしてはHTTPを利用（オンプレミス/AWS双方のServerでApacheを起動）、かつ、AWSから提供されているDNS名をそのまま利用しています。
カスタムドメイン名を利用する場合や、HTTPS通信等で証明書を利用する場合は別途ドメイン名の考慮が必要になりますので、ご注意ください。
パターンA
詳細な手順は割愛しますが、構築した環境構成は以下の通りです。
PrivateLink EndpointのDNS名はパブリックに名前解決可能なため、特に特殊な設定を行わなくてもServer＠On-Premiseから名前解決が可能です。
無事に接続できました。
パターンB
同じく詳細な手順は割愛しますが、構築した環境構成は以下の通りです。
こちらも無事に接続できました。
まとめ
IPアドレスが重複したVPC⇔オンプレミス間の接続についてパターンを整理し、一部の検証を実施してみました。複数の要素が絡むので、環境を構築する中でも色々と学びがありました。近いうちにカスタムドメイン名やHTTPS通信を交えた場合の考慮事項についても整理できればと思います。