COLUMN
AWSでIPv6を使う場合のリファレンスアーキテクチャを読み解く:後編
こんにちは、白鳥です。 |
今回解説するアーキテクチャは、下記の9つとなります。
- アーキテクチャ9:DNS64
- アーキテクチャ10:NAT64
- アーキテクチャ11:NAT64を使ったアウトバウンドトラフィックの集約
- アーキテクチャ12:デュアルスタックVPCにおけるVPCピアリング接続
- アーキテクチャ13:デュアルスタックVPC間のTransit Gateway接続
- アーキテクチャ14:デュアルスタックVPC間のAWS Privatelink接続
- アーキテクチャ15:デュアルスタックVPCとオンプレミスのDirect Connectを使用した接続
- アーキテクチャ16:デュアルスタックVPCとオンプレミスのSite-to-Site VPNを使用した接続
- アーキテクチャ17:Transit Gateway Connectを使った接続
前回及び前々回のコラムは、こちらをご覧ください。
AWSでIPv6を使う場合のリファレンスアーキテクチャを読み解く:準備編
AWSでIPv6を使う場合のリファレンスアーキテクチャを読み解く:前編
目次:
- 想定する読者
- アーキテクチャ毎の解説
- アーキテクチャ9:DNS64
- アーキテクチャ10:NAT64
- アーキテクチャ11:NAT64を使ったアウトバウンドトラフィックの集約
- アーキテクチャ12:デュアルスタックVPCにおけるVPCピアリング接続
- アーキテクチャ13:デュアルスタックVPC間のTransit Gateway接続
- アーキテクチャ14:デュアルスタックVPC間のAWS Privatelink接続
- アーキテクチャ15:デュアルスタックVPCとオンプレミスのDirect Connectを使用した接続
- アーキテクチャ16:デュアルスタックVPCとオンプレミスのSite-to-Site VPNを使用した接続
- アーキテクチャ17:Transit Gateway Connectを使った接続
- まとめ
想定する読者
- 自身の環境のIPv6移行を検討されている方
- AWSの各種ネットワーク系サービスを知っている方
アーキテクチャ毎の解説
アーキテクチャ9:DNS64
ここまでの話は、どちらかというとIPレイヤの話が中心でした。IPv6のみのリソースがIPv4しか持っていないリソースに対して、DNSで名前解決して通信できるようにするためにはどうしたらよいでしょうか?という問いに答えるのがこのDNS64です。
DNS64を使い割り当てたIPv4-IPv6変換プレフィックスを利用するよう、 IPv4アドレスをプレフィックスの末尾に埋め込む形でアドレスの合成をおこなってIPv6のみのリソースがIPv4のみのリソースに対して通信できるようにします。
VPCを作成すると、デフォルトでRoute 53 Resolverが作られます。
IPv6の場合、Route 53 Resolverにはfd00:ec2::253のユニークローカルアドレスが割り当てられます。
また、デフォルトではDNS64は有効化されていないので、サブネットごとにDNS64を有効化します。
IPv6のリソースがRoute 53 Resolverに対しDNSクエリを行うと、Route 53 Resolverは下記のように動きます。
- 対象のリソースがIPv6アドレスを持つ場合(AAAAレコードを持つ場合)は、IPv6アドレスを回答し、IPv4からIPv6変換を行わずに通信できるようになります。
- 対象のリソースがIPv6アドレスを持たない場合(Aレコードのみを持つ場合)は、RFC6052に規定されたWell-Knownプレフィックス(64:ff9b::/96)を使い、IPv4アドレスを埋め込みます。
例えば、IPv4アドレスが192.0.0.1のみを持つリソースに対してのDNS64を用いてIPv6アドレス変換を行った場合は、64:ff9b::c000:0001となります。
アーキテクチャ10:NAT64
DNS64/NAT64はセットで使われるのが一般的です。DNS64で得られたアドレスに対して、IPv6のみのリソースがどのように通信するかが、こちらのアーキテクチャ10になります。
NAT GatewayはデフォルトでNAT64が有効化されており、自身で有効化/無効化を選択することはできません。NAT Gatewayにて適切なIPアドレス変換を行います。
IPv6のみのサブネットのルートテーブルに対しては、64:ff9b::/96の宛先をNAT gatewayに指定します。
NAT Gatewayでは、宛先が64:ff9b::/96のIPv6パケットを受け取ると、元のIPv4アドレスへ変換します。
また、NAT Gatewayを通じて同一VPC内のIPv4のみのサブネットに通信もできますし、IPv4のみを持つインターネット上のリソースにも通信できます。
同様にVPNや、Direct Connect、VPCピアリング、Transit GatewayでつながったIPv4のみのリソースにも通信できます。
インターネット上のリソースに通信を行う場合は、IPv4の時と同様、NAT Gatewayがパブリックサブネットに属しておりかつ、Elastic IPアドレスを所持している必要があります。
アーキテクチャ11:NAT64を使ったアウトバウンドトラフィックの集約
大規模ネットワークで複数のVPCを利用する場合に、VPCごとにNAT Gatewayを構築することはコスト増加や管理面で効率的ではありません。
こうした場合はTransit Gatewayでアウトバウンド専用のVPCを構築し、各VPCと接続する方式があります。
NAT64を使用する場合も同様にアウトバウンド専用のVPCを構築し、アウトバウンド専用のVPCにNAT Gatewayを集約させます。
DNS64/NAT64に関してはアーキテクチャ10,11と同様になります。
アーキテクチャ12:デュアルスタックVPCにおけるVPCピアリング接続
VPCピアリングはIPv6でもIPv4と同様に使えます。同一のリージョン内、リージョン間も同様です。
IPv6用のルートテーブルもそれぞれのVPCで設定することを忘れずに設定してください。
アーキテクチャ13:デュアルスタックVPC間のTransit Gateway接続
アーキテクチャ11でも出てきましたが、Transit GatewayはIPv6でも使用可能です。リージョン間を接続する場合はTransit Gateway Inter-Regionピアリングを使用します。
Transit GatewayのVPCアタッチメントはアベイラビリティゾーンごとに作るのもIPv4と同様です。
こちらもアーキテクチャ12と同様、IPv6用のルートテーブルもそれぞれのVPCで設定してください。
アーキテクチャ14:デュアルスタックVPC間のAWS Privatelink接続
Privatelinkを使ってVPC間を接続する場合は、このような形となります。Privatelinkエンドポイントは少なくとも2つのアベイラビリティゾーンで作ることが推奨されています。
エンドポイントはIPv4のみ、IPv6のみ、デュアルスタックいずれでも作ることができ、既存のIPv4のエンドポイントをデュアルスタックに変更することもできます。
IPv6アドレスを持つPrivatelinkエンドポイントはdenyAllIGWTrafficが設定されており、IGWからのトラフィックを拒否します。
これは変更できず、なおかつENI作成後に変更することもできません。
プロバイダ側のVPCでは、Privatelinkの接続先はNLBとなります。バックエンドとの接続はアーキテクチャ6,7と同様になります。
繰り返しになりますが、IPv6のみのターゲットグループには、IPタイプのみが使用可能となります。
プロバイダ側のVPCでIPアドレス変換が必要になった場合は、NLBでIPアドレス変換を行います。
アーキテクチャ15:デュアルスタックVPCとオンプレミスのDirect Connectを使用した接続
Direct Connectを使用した接続はIPv6でも使用可能です。VIFもBGPセッションもデュアルスタックで使用可能です。
IPv6においても、VIFはプライベートVIF、Transit VIF、パブリックVIFが使用可能です。IPv4の仕様は省略します。
IPv6においては、BGPピアリングはAWS払い出しの/125 プレフィックスが払い出され、これは変更できないので、オンプレ側のBGPルータの設定時に確認が必要です。
アーキテクチャ16:デュアルスタックVPCとオンプレミスのSite-to-Site VPNを使用した接続
IPv6のSite-to-Site VPNですが、利用にはいくつかの注意点があります。
準備編で記載したように、IPv6を使う場合はTransit Gateway経由でのみ使用可能です。
また、エンドツーエンドの通信がIPv6のみであっても、Customer Gateway(拠点側のルータ)のWAN側にはパブリックIPv4アドレスが必要となります。
これは、IPSecのコネクション確立にIPv4が必要になるためです。
IPv4の通信が必要な場合は、IPv4用のIPSecコネクションの確立が必要です。IPSecトンネルを介して、IPv6通信を行います。
アーキテクチャ17:Transit Gateway Connectを使った接続
Transit Gateway Connectと聞いて、もしかしたらなじみのない方もいらっしゃるかもしれません。
Transit Gateway ConnectはSD-WANのアプライアンスとTransit Gatewayを接続するもので、BGPやGREトンネルを使用してSD-WANをAWSまで拡張できるサービスです。
IPSecで接続する必要がないため、設定の手間が少なく済む利点があります。
接続する先はVPC上の仮想アプライアンスや、オンプレミスのSD-WANアプライアンスになります。
利用するためにはいくつかの条件があります。
Transit Gateway Connect アタッチメントと Transit Gateway Connect ピア
IPv6に特化した部分で言うと、下記のようになります。
- Transit GatewayのIPv6 CIDRブロックを/64以上、IPv4 CIDRブロックを/24以上にする。
- IPv6プレフィックスは、MP-BGPを使用して IPv4 BGPを介して交換されます。
- VPCアタッチメントではデュアルスタックが使えます。
- Transit VIFのBGPセッションはIPv6とIPv4の両方が確立できます。
- Connectピアを確立するために、GREトンネルが必要となりますが、GREトンネルはIPv6を利用できます。
- GREトンネルのためのBGP内部アドレスは、fd00::/8の範囲から/125を切り出したCIDRブロックを指定します。
まとめ
3回を通じて、IPv6をAWSで使うためのアーキテクチャについて解説してきました。
後半はIPv4とそれほど変わらないところ、IPv6特有のところもあり、個人的にもかなり勉強になりました。
こうしたノウハウを含め、NTT東日本はクラウド利用時のネットワーク設計や接続方法などのノウハウを多数有しております。
AWSとの接続方法やネットワーク設計についてお困りの方は、是非お気軽にご相談ください!
RECOMMEND
その他のコラム
相談無料!プロが中立的にアドバイスいたします
クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。