以前の記事にて、メッシュ内からメッシュ外へ通信を行う方法として、アクセス先のエンドポイント専用の仮想ノードを作成するという方法を紹介しました。
ただその際、アクセス先のサイトがIPv6に対応しているかどうかで通信が失敗するという事例に遭遇したので、この記事ではそれについてまとめます。
結論
IPv6を用いる予定がないのであれば、
アクセス先のエンドポイント専用の仮想ノードを作成する際に、「IP バージョンの設定」をデフォルトとせず、IPv4が優先されるようにする。
失敗する原因
仮想ノードを作成する際、「IP バージョンの設定」という設定があります。
ここを何も変更しなければ勿論この設定についてはデフォルトとなるのですが、
こちらデフォルトでは名前解決時にIPv4よりもIPv6を優先するような設定となっています。(公式ドキュメント)
ただ、特に意識せずにECSタスクを立ち上げた場合、ECSタスクはIPv6に対応していません。
(正確にはVPCのIPv6対応等が必要)
まとめると、名前解決はIPv6で行われるが、ECSタスクがIPv6に対応していないためエラーとなっていました。
対策
結論にも記載した通り、「IP バージョンの設定」をIPv4が優先されるものに変更したら解決します。
画像でいうなら
- IPv4 を設定済み
- IPv4 のみ
の2つですね。
補足
ここまで書いてきた内容はアクセス先のサイトがIPv6に対応していなければ発生しません。
なので例えば「aws.amazon.com」へのアクセスは、「IP バージョンの設定」がデフォルト状態でも成功します。
「aws.amazon.com」はIPv6未対応
xxx>nslookup aws.amazon.com
サーバー: xxx
Address: xxx
権限のない回答:
名前: dr49lng3n1n2s.cloudfront.net
Address: 18.65.165.68
Aliases: aws.amazon.com
tp.8e49140c2-frontier.amazon.com
※一部伏字
まとめ
上記問題に遭遇した時は、curlコマンドを用いて接続確認をしていたのですが(ECS Execを使用)、
エラー文がcurl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
と、IPv6と直接結びつけるのが難しいものだったので苦戦しました。
(最終的にはAWSサポートのお力も借りました・・・)
なので、App Meshを使う際のちょっとした参考になればなと思います。