トップ > CCI > クラウド環境でのIPv6について（WEB公開編）

クラウド環境でのIPv6について（WEB公開編）

CCI AWS

IPv6クラウドWEB公開編

IPv6の現状とAWSの設定について

CCIインフラ担当のYAMADAです。

techblog.cartaholdings.co.jpの続編になります。
前回はインスタンスの起動まで行ったので、Apacheを起動してALBでの外部公開まで試してみたいと思います。

Apacheの設定

ApacheではListenで待ち受けのアドレスとポート番号を指定します。デフォルトのコンフィグではこんな感じです。

#Listen 12.34.56.78:80
Listen 80

デフォルトでは、すべてのインターフェースが有効になるのでIPv6も問題なく有効になるはずです。逆にIPv6を指定する場合は、以下の様に角カッコでくくる必要があるとのこと。確かにIPアドレスとポート番号の区切りであるコロンがIPv6の表記で使われているので、かっこは必要ですね。

Listen [2001:db8::a00:20ff:fea7:ccea]:80

今回は何も考えずデフォルトのままメインホストで稼働させます。

インスタンスの起動イメージはAmazon linux 2023のため、おなじみのnetstatコマンドではなく、ssコマンドにてリッスンポートを確認してみます。

# ss -lt
State         Recv-Q        Send-Q               Local Address:Port               Peer Address:Port       Process
LISTEN        0             128                        0.0.0.0:ssh                     0.0.0.0:*
LISTEN        0             128                           [::]:ssh                        [::]:*
LISTEN        0             511                              *:http                          *:*

sshでは、[::]とIPv6感を出していますが、httpは＊でIPv6も受けているのか何とも言えません。 netstatでも確認してみるとhttpもIPv6でリッスンしていることがわかりました。

# netstat -at
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 localhost:ssh           localhost:56242         ESTABLISHED
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN
tcp6       0      0 [::]:http               [::]:*                  LISTEN

なぜ、ssコマンドだとhttpのみ＊になるのかわかりませんが、ssコマンドも-6オプションをつけることでIPv6のみ表示させることができるので、IPv6でもリッスンしていることは確認できました。 Amazon Linux 2023にデフォルトでnet-toolsがインストールされている限りはnetstatを使い続けてもよい気がしてきました。

次にIPv6環境のブラウザからアクセスしてみます。自宅のIPv6アドレスをセキュリティグループで許可して、IPv6で直接アクセスしてみます。

IPアドレスによるURLは久しく叩いていないのですが、以下の様にそのままブラウザのアドレスバーに入れてみます。

http://2406:da14:96f:b500:9cd7:15a0:54ab:72df/

ダメでした、ApacheのListenと同じくこれもコロンの影響があるため角カッコが必要でした。

http://[2406:da14:96f:b500:9cd7:15a0:54ab:72df]/

IPv6アドレスでアクセスできることが確認できました。

Apacheのアクセスログですが、以下の通りクライアントのIPアドレスがIPv6で記録されていることが確認できました。

2400:4051:****:****:****:****:****:**** - - [05/Jun/2023:07:55:52 +0000] "GET / HTTP/1.1" 403 45 "-" "Mozilla/5.0 (Win~~"
2400:4051:****:****:****:****:****:**** - - [05/Jun/2023:07:55:52 +0000] "GET /favicon.ico HTTP/1.1" 404 196 "http://[2406:da14:96f:b500:9cd7:15a0:54ab:72df]/" "Mozilla/5.0 (Win~~"

ロードバランサーの設定

次にロードバランサーでIPv6の設定を確認してみます。

マネジメントコンソールでVPCの画面からターゲットグループをクリックして、ターゲットグループ名とVPCを選択し「次へ」進み、作成したテスト用のインスタンスを選択します。

ターゲットグループの設定箇所（デフォルト以外）

  • ターゲットグループ名
    • 任意のグループ名
  • VPC
    • 作成したテスト用のVPCを選択
  • インスタンス
    • テスト用インスタンスを選択

次にロードバランサーから「ロードバランサーの作成」から「Application Load Balancer」を選択、クリックします。

ロードバランサーの設定箇所（デフォルト以外）

  • ロードバランサー名
    • 任意のロードバランサー名
  • IPアドレスタイプ
    • Dualstack を選択。これによりIPv6でアクセス可能となる
      ロードバランサー 基本的な設定
  • VPC
    • 作成したVPC
  • マッピング
    • 2つのアベイラビリティーゾーンとゾーンごとの1つのサブネット
    • サブネットはIPv6が有効になっている必要がある
  • セキュリティグループ
    • インスタンス用のセキュリティグループで問題ない
  • リスナーとルーティングのデフォルトアクション
  • デフォルトアクションの転送先
    • 作成したターゲットグループ

ロードバランサーに割りあてられるIPv6アドレスは、VPCに割り当てられたIPv6 CIDRでした。ロードバランサーはVPC内に立つ以上確かにと言ったところです。

IPv6でのアクセス確認のため、ロードバランサーのURLに直接アクセスしてみます。 IPv6でアクセスしているかどうかは、ブラウザで確認します。確かにIPv6でアクセスしているようです。

Chrome - デベロッパーツール - ネットワーク

ロードバランサーのアクセスログも確認しましたが、以下の様にIPv6が記録されておりました。

http 2023-06-12T05:22:47.348365Z app/test-ipv6-lb/f7f6353b2362bda9 2400:4051:****:****:****:****:****:****:34612 10.0.0.48:80 0.000 0.001 0.000 200 200 523 318 "GET http://te
http 2023-06-12T05:22:47.409077Z app/test-ipv6-lb/f7f6353b2362bda9 2400:4051:****:****:****:****:****:****:34612 10.0.0.48:80 0.000 0.001 0.000 404 404 477 387 "GET http://te

サーバ側、つまりApacheのアクセスログはどうでしょうか。
ブラウザからALBに対してIPv6でアクセスされた場合でも、アクセスログにはロードバランサーのIPv4アドレスが記録されており、ロードバランサーでIPv6からIPv4に変換される形となりました。つまり、サーバ側はIPv6が有効でなくてもロードバランサーにてIPv6による公開が可能となります。 ロードバランサーに振られるIPv6アドレスはVPCに割り当てられたIPv6CIDRから振られるため、VPCをIPv6化しておく必要はありそうですが。

X-Forwarded-forにて、サーバ側のアクセスログにクライアントのIPアドレスも記録してみます。 確かに以下のような書式でブラウザのIPv6アドレスが記録されていました。 10.0.0.51はロードバランサーのIPアドレスです。

2400:4051:****:****:****:****:****:**** 10.0.0.51 - - [12/Jun/2023:05:22:47 +0000] "GET / HTTP/1.1" 200 46 
2400:4051:****:****:****:****:****:**** 10.0.0.51 - - [12/Jun/2023:05:22:47 +0000] "GET /favicon.ico HTTP/1

CloudFrontのIPv6設定

次にCloudFrontのIPv6を確認してみます。
マネジメントコンソールでCloudFrontの画面からディストリビューションを開いて、「ディストリビューションを作成」ボタンをクリックし、新規に設定していきます。ここでも以下の通り選択や入力を求められない限りはデフォルト設定のまま進めます。

  • オリジン
    • オリジンドメイン
      • 上段で作成したABLを選択する
    • プロトコル
      • HTTPのみ
  • デフォルトのキャッシュビヘイビア
    • キャッシュキーとオリジンリクエスト
      • キャッシュポリシーはCachingOptimizedForUncompressedObjectsを選択する
  • ウェブアプリケーションファイアウォール (WAF)
    • セキュリティ保護を有効にしないでくださいを選択する（IP制限するため）
  • 設定
    • 料金クラス
      • 北米、欧州、アジア、中東、アプリ化を使用 を選択する

そしてIPv6の設定です。一番下にありましたがデフォルトで有効になっていました。

CloudFront ディストリビューションIPv6

作成後、ディストリビューションドメイン名をnslookupしてみましたがIPv6アドレスはCloudFront独自のCIDRで、VPCに設定しているIPv6のCIDRとは別物でした。

> nslookup d10wzrlo4qn13n.cloudfront.net
サーバー:  UnKnown
Address:  ****:****:****:****:****:****:****:

権限のない回答:
名前:    d10wzrlo4qn13n.cloudfront.net
Addresses:  2600:9000:221a:e00:3:8043:d4c0:21
          2600:9000:221a:4400:3:8043:d4c0:21
          2600:9000:221a:600:3:8043:d4c0:21
          2600:9000:221a:4800:3:8043:d4c0:21
          2600:9000:221a:4000:3:8043:d4c0:21
          2600:9000:221a:ee00:3:8043:d4c0:21
          2600:9000:221a:6800:3:8043:d4c0:21
          2600:9000:221a:e000:3:8043:d4c0:21
          18.65.190.211
          18.65.190.224
          18.65.190.179
          18.65.190.222

ALBのセキュリティグループでCloud Frontからのアクセスを許可する場合、CloudFrontのマネージドプレフィックスリスト（ com.amazonaws.global.cloudfront.origin-facing）を許可することで可能となりますが、このプレフィックスリストのエントリはIPv4だけなので、ALBへのアクセスもこれらIPv4アドレスからのアクセスとなりました。

既存環境のIPv6での公開

CloudFrontは、デフォルトでIPv6で公開する構成となっており、サーバもALBも設定を変更する必要がありません。CloudFrontを利用していてIPv6を無効にする理由がない場合、設定を確認してみてはどうでしょうか。