はじめに
AWS環境からAWS外にあるDNSサーバへ名前解決を行うために、Route53 Resolver Outbound Endpointを利用する機会がありました。
DNSサーバへの通信要件を決定するために、Route53 Resolver Outbound Endpointを経由した通信のIPアドレスが変換されるか気になったため、検証しました。
※本記事は、【ハンズオン】Route53 Resolver Inbound/Outbound Endpoint の環境を前提に記載しています。
目次
構成の確認
検証を行う構成は以下の通りです。構築手順の詳細は、【ハンズオン】Route53 Resolver Inbound/Outbound Endpoint を参照ください。
Route53Inbound/OutboundEndpointと転送ルールを使用して大阪EC2からプライベートドメインが付与されたオハイオEC2にpingを送信して、IPアドレスを確認します。
構成図
IPアドレスの確認
早速結論ですが、オハイオEC2へのリクエストにおける送信元IPアドレスは、大阪EC2のIPアドレスになります。Route53 Resolver Inbound/Outbound Endpointでは、IPアドレスの変換が行われません。
【ハンズオン】Route53 Resolver Inbound/Outbound Endpoint を確認いただいた方はお気づきだと思いますが、そもそもオハイオEC2に設定しているセキュリティグループのインバウンドでは大阪EC2のサブネットを許可しています（Route53 Resolver Inbound/Outbound EndpointのIPアドレスを許可していません）。
確認のため、大阪EC2からオハイオEC2にpingを送信しつつ、オハイオEC2でtcpdumpを利用してネットワーク通信をキャプチャしました。
pingとtcpdumpは、EC2にSession Manager経由で接続して実行しました。
大阪EC2 → オハイオEC2 にping
オハイオEC2 でtcpdump
※大阪EC2のプライベートIPは、172.31.1.159
IPアドレスの変換
では、「送信元のIPアドレスを隠したい」「別のIPに変換したい」などの要件に備え、NAT Gatewayを利用して、送信元のIPアドレスを変換できるか追加で検討しました。
今回はプライベートNAT Gatewayを利用しました。
検討した構成は以下です。
追加検証の構成図
始めに、大阪リージョンにNAT Gateway用サブネットを作成し、プライベートNAT Gatewayを設置しました。
大阪 NAT Gateway用サブネット
大阪 NAT Gateway
続いて、大阪EC2 → オハイオEC2への通信経路を確保します。
大阪VPCからオハイオVPCへのリクエスト時、先ほど作成したプライベートNAT Gatewayを経由するよう設定したルートテーブルを作成し、大阪EC2用サブネットに関連付けました。
大阪EC2用サブネット ルートテーブル
オハイオEC2のセキュリティグループにて、大阪 プライベートNAT GatewayのIPアドレスを許可するインバウンドルールを追加しました。
オハイオEC2用セキュリティグループ
最後に確認のため、大阪EC2からオハイオEC2にpingを送信しつつ、オハイオEC2でtcpdumpを利用してネットワーク通信をキャプチャしました。
pingとtcpdumpは、EC2にSession Manager経由で接続して実行しました。
大阪EC2 → オハイオEC2 にping
オハイオEC2 でtcpdump
※大阪EC2のプライベートIPは、172.31.1.159
無事、オハイオEC2への送信元IPアドレスが、大阪 プライベートNAT GatewayのIPアドレスになっていることを確認でき、リクエスト元である大阪EC2のIPアドレスから変換されていることが確認できました。
まとめ
Route53 Resolver Outbound Endpointを経由した通信のIPアドレスは、エンドポイントで変換されることなく、送信元IPアドレスが維持されることがわかりました。
また、なんらかの理由で別のIPアドレスに変換したい場合は、NAT GatewayによるIPアドレス変換が利用可能であることがわかりました。
本記事がどなたかの参考になれば幸いです。