はじめに
複数のVPCでIPアドレスが重複しているが，それでもなんとかして通信したいという悲しい要件を実現してみます。（そもそもアドレス設計段階で…というお小言は言わないお約束）。トリッキーな方法でなんとかしましょう。
（まだ書きかけなので，そのうちもう少し整理します。）
前提知識
この記事は，以下のスキルと知識をお持ちの方むけの解説です。
- AWS
- VPC
- TransitGateway
- NAT Gateway
- Application Loadbalancer
- SecurityGroup
- ルートテーブル
- サブネット
- IPv4の知識
- サブネット
- NAPT
- NAT
要件整理
- クライアントとWebサーバ間でHTTP/HTTPS通信させる。
- クライアントとWebサーバが別VPCにある。
- クライアントのネットワークアドレスとWebサーバのネットワークアドレスが重複しているOrz
- Webサーバ側のVPC構成はできるだけ変更しない（サブネットを追加したり追加リソースはできるだけ使わない）
- できるだけAWSマネージドなサービスで
制約事項
- 疎通させるプロトコルは，HTTP/HTTPS限定とします。
- 可用性（AZ故障）は考慮しません。
- 実際のネットワーク設計に適合しない可能性があります。
- WebサーバのIPアドレスは固定とします。
- WebサーバのアクセスログにはクライアントのIPアドレスが記録できません（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のアドレスを見せています。言い方を変えると，プライベートNATゲートウェイ→ALB宛てのパケットの送信元IPアドレスは10.0.1.*のアドレスになります。 -
1:1NAT（もどき）をALBで実現した
AWSには1:1NATを実現するサービスがありません（多分）。なので，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に持ってきました。
おまけ
1:1NATをできるインスタンス（EC2＋Linux+iptablesとかFWなアプライアンスとか）を作って，同じようにルートテーブルを工夫すれば，HTTP/HTTPSに限定せずIPリーチャブルに近い環境を作れると思います。ただしAWSマネージドではないので構築保守運用が大変です。