【ネットワーク】Route53 Resolver Outbound Endpointを経由した通信のIPアドレス

# はじめに
AWS環境からAWS外にあるDNSサーバへ名前解決を行うために、Route53 Resolver Outbound Endpointを利用する機会がありました。
DNSサーバへの通信要件を決定するために、Route53 Resolver Outbound Endpointを経由した通信のIPアドレスが変換されるか気になったため、検証しました。

※本記事は、[【ハンズオン】Route53 Resolver Inbound/Outbound Endpoint](https://qiita.com/okuken123/private/cee3e88e8f0a3501cb56) の環境を前提に記載しています。

# 目次
<!-- タイトルとアンカー名を編集 -->
1. [構成の確認](#Chapter1)
1. [IPアドレスの確認](#Chapter2)
1. [IPアドレスの変換](#Chapter2)
1. [まとめ](#Chapter3)
1. [参考文献](#reference)

# 構成の確認
検証を行う構成は以下の通りです。構築手順の詳細は、[【ハンズオン】Route53 Resolver Inbound/Outbound Endpoint](https://qiita.com/okuken123/private/cee3e88e8f0a3501cb56) を参照ください。

Route53Inbound/OutboundEndpointと転送ルールを使用して大阪EC2からプライベートドメインが付与されたオハイオEC2にpingを送信して、IPアドレスを確認します。

**構成図**
![構成図.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332470/4d98ea94-8b86-469d-8e48-5197c5009137.png)

# IPアドレスの確認
早速結論ですが、オハイオEC2へのリクエストにおける送信元IPアドレスは、大阪EC2のIPアドレスになります。Route53 Resolver Inbound/Outbound Endpointでは、IPアドレスの変換が行われません。

[【ハンズオン】Route53 Resolver Inbound/Outbound Endpoint](https://qiita.com/okuken123/private/cee3e88e8f0a3501cb56) を確認いただいた方はお気づきだと思いますが、そもそもオハイオEC2に設定しているセキュリティグループのインバウンドでは大阪EC2のサブネットを許可しています（Route53 Resolver Inbound/Outbound EndpointのIPアドレスを許可していません）。

確認のため、大阪EC2からオハイオEC2にpingを送信しつつ、オハイオEC2でtcpdumpを利用してネットワーク通信をキャプチャしました。
pingとtcpdumpは、EC2にSession Manager経由で接続して実行しました。

**大阪EC2 → オハイオEC2 にping**
![大阪→オハイオ_ping.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332470/45f29972-4bd1-458c-84d3-031a8f5f5eaa.png)

**オハイオEC2 でtcpdump**
※大阪EC2のプライベートIPは、172.31.1.159 
![オハイオ_ec2_dump.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332470/8a11c8e5-2f6c-4718-8c2b-eed550cda344.png)


# IPアドレスの変換
では、「送信元のIPアドレスを隠したい」「別のIPに変換したい」などの要件に備え、NAT Gatewayを利用して、送信元のIPアドレスを変換できるか追加で検討しました。
今回はプライベートNAT Gatewayを利用しました。

検討した構成は以下です。

**追加検証の構成図**
![構成図.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332470/0c3daaf2-b3c8-47d3-9842-0b94d574c5b4.png)

始めに、大阪リージョンにNAT Gateway用サブネットを作成し、プライベートNAT Gatewayを設置しました。
**大阪 NAT Gateway用サブネット**
![大阪_サブネット_nat.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332470/7001b54c-4f03-4d88-8575-18ac7a565892.png)

**大阪 NAT Gateway**
![大阪_nat.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332470/3027fead-0d60-47c5-8881-3f1765fe832b.png)

続いて、大阪EC2 → オハイオEC2への通信経路を確保します。
大阪VPCからオハイオVPCへのリクエスト時、先ほど作成したプライベートNAT Gatewayを経由するよう設定したルートテーブルを作成し、大阪EC2用サブネットに関連付けました。

**大阪EC2用サブネット ルートテーブル**
![大阪_ec2_rt.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332470/1b77762d-d189-44ab-a6a2-613b0ace571b.png)

オハイオEC2のセキュリティグループにて、大阪 プライベートNAT GatewayのIPアドレスを許可するインバウンドルールを追加しました。

**オハイオEC2用セキュリティグループ**
![オハイオ_ec2_sg.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332470/e17a5cb2-8d4a-44e4-8b78-a480c92d8473.png)

最後に確認のため、大阪EC2からオハイオEC2にpingを送信しつつ、オハイオEC2でtcpdumpを利用してネットワーク通信をキャプチャしました。
pingとtcpdumpは、EC2にSession Manager経由で接続して実行しました。

**大阪EC2 → オハイオEC2 にping**
![大阪→オハイオ_ping.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332470/45f29972-4bd1-458c-84d3-031a8f5f5eaa.png)

**オハイオEC2 でtcpdump**
※大阪EC2のプライベートIPは、172.31.1.159 
![大阪→オハイオ_ping_nat.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3332470/0e126fb7-61c0-41c8-9f18-11aa16b821a9.png)

無事、オハイオEC2への送信元IPアドレスが、大阪 プライベートNAT GatewayのIPアドレスになっていることを確認でき、リクエスト元である大阪EC2のIPアドレスから変換されていることが確認できました。

# まとめ
Route53 Resolver Outbound Endpointを経由した通信のIPアドレスは、エンドポイントで変換されることなく、送信元IPアドレスが維持されることがわかりました。

また、なんらかの理由で別のIPアドレスに変換したい場合は、NAT GatewayによるIPアドレス変換が利用可能であることがわかりました。

本記事がどなたかの参考になれば幸いです。

# 参考文系
[超絶初心者むけtcpdumpの使い方](https://qiita.com/tossh/items/4cd33693965ef231bd2a)