はじめに
複数のVPCでIPアドレスが重複しているが，それでもなんとかして通信したいという悲しい要件を実現してみます。（そもそもアドレス設計段階で…というお小言は言わないお約束）。トリッキーな方法でなんとかしましょう。
前提知識
この記事は，以下のスキルと知識をお持ちの方むけの解説です。
- AWS
- ルートテーブル
- NAT Gateway（プライベートNAT Gateway）
- VPC
- TransitGateway
- Application Loadbalancer
- SecurityGroup
- サブネット
- IPv4の知識
- サブネット
- NAPT
- NAT
要件整理
- クライアントとWebサーバ間でHTTP/HTTPS通信させる。
- クライアントとWebサーバが別VPCにある。
- クライアントのネットワークアドレスとWebサーバのネットワークアドレスが重複している
- Webサーバ側のVPC構成はできるだけ変更しない（サブネットを追加したり追加リソースはできるだけ使わない）
- できるだけAWSマネージドなサービスで
制約事項
- この記事は簡易的な構成で作成しており，実際のネットワーク設計に適合しない可能性があります。
- 疎通させるプロトコルは，HTTP/HTTPS限定とします。
- 可用性（AZ故障）は考慮しません。
- WebサーバのIPアドレスは固定とします。
- WebサーバのアクセスログにはクライアントのIPアドレスが記録できません（ALBもしくはNAT GatewayのIPアドレスが記録される）。
- Webサーバからクライアント宛の通信は発生しないとします。
構成図
ALBのターゲットグループにWebサーバのIPアドレスを登録しました。
結果
クライアントからALBにHTTPでアクセスすると，Webサーバにアクセスできました。
$ curl http://vpc1-alb-8c9e1*****5d52.elb.us-east-1.amazonaws.com
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
以下略
ということで，無事に動作しました。なお，ALBのホスト名は10.0.2.*のプライベートIPに解決されていました。
トリッキーなポイント
-
サブネット毎に，ルートテーブルで到達できる範囲を制限した
特にPrivateSubnet3です。10.64.0.0/24は，Webサーバ側VPCにルーティングしました。「クライアントヘの経路はどうするの？」という疑問に対しては，この後のプライベートNATゲートウェイの説明を見てください。 -
プライベートNATゲートウェイを使って，VPC内でNAPTした
プライベートNATゲートウェイを使って，ALBには10.64.0.0/24ではなく，10.1.0.0/24のアドレスを見せています。クライアントから送信されたパケットの送信元IPアドレスは10.64.0.Xです。このパケットがプライベートNATゲートウェイを通過した後（ALBに届くまで）の送信元IPアドレスは10.0.1.Y（NAT Gatewayのアドレス）になります。
NATゲートウェイよりもNAPTゲートウェイと呼んだ方がしっくりくるかもしれません。 -
1:1NAT（もどき）をALBで実現した
AWSには1:1NAT（宛先IPアドレスを書換える）を実現するサービスがありません（多分）。なので，1:1NATの代替としてALBで無理矢理アドレス変換をしています。
微妙にストレス発生な設定
-
プライベートサブネットのルートテーブル
TransitGatewayをターゲットにする場合TransitGatewayを直接指定できず，TransitGatewayアタッチメントのENI（ElasticNetworkInterface）を指定する必要があります。ENIを特定するのが手間。 -
ALBのターゲットグループ
異なるVPCのインスタンス指定やDNS名（FQDN）をターゲットに設定できません。なのでWebサーバのIPアドレス直撃です。 -
TransitGatewayの伝播を削除
10.64.0.0/24宛ての経路をシビアに制御したかったので，デフォルトで作成される伝播を全削除しました。
まとめ
IPアドレスが重複しているVPC間で，HTTP/HTTPSを疎通させてみました。
トラブルシューティング
- つながらない
ルートテーブルが誤っていないか，ルートテーブルがサブネットにアタッチされているか通信したいポートがセキュリティグループで設定されているか，など基本的な箇所を確認しましょう。 - 切り分け方法
リーチャビリティアナライザーを使って切り分けましょう。以下のような区間で試験するとよいでしょう。
・Client→ALB
・PrivateSubnet3のTransitGateway ENI→Webサーバ
参考情報
参考にしたのは公式リンクです。構成図のうちWebサーバ側のVPCにあったALBをクライアント側VPCに持ってきました。
その他参考にした情報です。
https://aws.amazon.com/jp/blogs/news/connecting-networks-with-overlapping-ip-ranges/
おまけ
1:1NATをできるインスタンス（EC2＋Linux+iptablesとかFWなアプライアンスとか）を作って，同じようにルートテーブルを工夫すれば，HTTP/HTTPSに限定せずIPリーチャブルに近い環境を作れると思います。ただしAWSマネージドではないので構築保守運用が大変です。