[TIL] 5. AWS VPC
wakakaインターフェイス型VPCe理解した気がする
大前提として、AWSでは通信がサービスエンドポイント（service.region.amazonaws.com）に到達することでサービスを利用できる。Public環境下でこれらのサービスエンドポイントを名前解決するとグローバルIPアドレスが返ってくる（表：右上）。
だが、VPCeの「プライベートDNS名を有効化」すると、サービスエンドポイントとVPCeのプライベートIPを対応させるAレコードがPrivate hosted zoneに作成される（表：左上）。
これによりVPC内からサービスエンドポイントを名前解決するとVPCeのプライベートIPアドレスが返ってくるため、インターネットに出ていくことなくサービスを利用できる。
Regional DNS名とZonal DNA名は「プライベートDNS名を有効化」せずともPublic hosted zoneにAレコードが作成される。これより、VPC内から名前解決しても、外部Resolverから名前解決してもプライベートIPアドレスが返ってくる（表：中央、下段）。
オンプレからCLIを用いてサービスを利用する場合には注意が必要。aws s3 ls などのCLIコマンドを実行する際には、内部的にサービスエンドポイント（s3.ap-northeast-1.amazonaws.com）へのリクエストを実行している。オンプレからPrivate hosted zoneは参照できないので、サービスエンドポイントを名前解決しようとするとグローバルIPアドレスが返ってくる（表：右上）。つまり、S3などのサービスにアクセスする際にインターネットを経由することになってしまう。
インターフェイス型VPCeを経由してサービスにアクセスするためには、以下のいずれかの設定をする必要がある。
- オンプレ側で参照先DNSサーバをRoute53 Inbound Endpointに指定
- VPCeのRegional DNS名かZonal DNS名を明示的にコマンドで指定（--endpoint-url）
| VPC内での名前解決 | 外部Resolverでの名前解決 | |
|---|---|---|
| service.region.amazonaws.com | 192.168.1.xx, 192.168.3.xx | 52.219.ww.xx, 52.219.yy.zz, ... |
| Regional DNS名 | 192.168.1.xx, 192.168.3.xx | 192.168.1.xx, 192.168.3.xx |
| Zonal DNS名 | 192.168.1.xx or 192.168.3.xx | 192.168.1.xx or 192.168.3.xx |
wakakaVPCeを利用してAWSサービスを利用する場合には、VPCeが存在するリージョンのサービスにしかアクセスすることができない。別リージョンのS3バケットなどにアクセスしたい場合には、別リージョンにVPCeを作成し、VPC Peeringで接続する必要がある。
wakaka特殊なPrivate IPアドレスは使用しない方がいい
EC2はPublic IPアドレスへの25番ポートを介したOutbound通信を制限している。
172.15.0.0/16などをPrivate IP帯として使用している場合、EC2側からはPrivate IPとしてではなくPublic IPとして認識されるために、EC2から172.5.0.0/16へのSMTP通信が拒否されてしまう。
公式レファレンスの通り、RFC1918で定義されているPrivate IP帯を使用する必要がある。
- クラスA：10.0.0.0〜10.255.255.255（10.0.0.0/8）
- クラスB：172.16.0.0〜172.31.255.255（172.16.0.0/12）
- クラスC：192.168.0.0〜192.168.255.255（192.168.0.0/16）
wakakaAWSでインスタンスのルートテーブルを気にしなくてもいい理由
AWSでは端末レベルでのルートテーブルを気にする必要がない。これはAWSで定義したルートテーブルのルーティング情報を各端末に自動で定義してくれているからである。
実際にはSubnet間にルータが存在し、このルータが各端末のデフォルトゲートウェイとなる。Subnet外に向かう通信は全てルータに集約され、ルータで定義されたルートテーブルに従ってルーティングされていく。ルータのルートテーブルを確認することはできないが、Subnetに関連づけられたルートテーブルで外部に向けたルートを作成した場合には、ルータのルートテーブルに定義されると思われる。
wakakaVPCにおける「DNS解決」と「DNSホスト名」とは
- DNS解決：Route 53 Resolverによるフルサービスリゾルバー機能を提供する属性
- DNSホスト名：Route53 ResolverによるPrivate hosted zoneを参照した名前解決を提供する属性
wakakaClient VPN使用時のクライアントのルートテーブル
Client VPNセッションを確立すると、クライアント端末に仮想NICが作成され、ルートテーブルが書き換えられる。スプリットトンネルが有効の場合には、Client VPNエンドポイントのルートテーブルで定義した通信先のCIDRへのルートがクライアント端末に設定される。
注意点として、自宅ネットワークのCIDRとVPCのCIDRが重複しないようにする必要がある。仮に自宅ネットワークのCIDRが 192.168.10.0/24 であり、VPCのCIDRが 192.168.0.0/16、クライアントCIDRが172.16.0.0/22 であるとする。この状態でClinet VPNセッションを確立すると、6~8行目のルートがクライアント端末のルートテーブルに追加される（採番されたクライアントIPは172.16.0.130）。
この時、アクセスしたいEC2やFargateが 192.168.10.0/24 というCIDRのサブネットに存在している場合、ロンゲストマッチに則り一番下のルートが選択されてしまい、AWS上のリソースに到達できない。以上のように、Client VPNを利用する場合にはCIDR設定に注意する必要がある。
```
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 192.168.10.1 UGScg en0
127 127.0.0.1 UCS lo0
127.0.0.1 127.0.0.1 UH lo0
169.254 link#15 UCS en0 !
169.254.169.254 link#15 UHRLSW en0 11
172.16.0.128/27 172.16.0.130 UGSc utun6
172.16.0.130 172.16.0.130 UH utun6
192.168 172.16.0.129 UGSc utun6
192.168.10 link#15 UCS en0 !
~~~~~~~~~~~~~~~~~ 以下省略 ~~~~~~~~~~~~~~~~~
```
wakaka図にも記載があるが、ClientVPN用ENI経由での通信ではNATが利用されているため、EC2側から見たときのSource IPはClientVPN用ENIのIPアドレスとなる。
wakakaスプリットトンネルを有効化しても、0.0.0.0/0向けルートはPushされない
スプリットトンネルを有効化すると、Client VPNエンドポイントのルートテーブルで定義した通信先のCIDRへのルートがクライアント端末に設定される。
ここで一つだけ例外があり、0.0.0.0/0向けのルートはクライアント端末に設定されない。
つまり、インターネット向けの通信は常にクライアント端末（自宅ネットワーク）から直接出ていく。
