お疲れ様です。矢儀 @yuki_ink です。
プロキシとVPCエンドポイント、使ってますか？？
このような構成で、AWS上でプロキシとVPCエンドポイントを利用されているケースは結構多いと思います。
今回はそんな構成に対する問題提起をしてみたいと思います。
なお、この記事は、過去のLTにてご紹介したTipsの1つを、記事として解説・深堀りするものです。
スライドを一通り見ていただくことで理解が進む点もあると思いますので、よろしければご参照いただければと思います。
（出典）VPCエンドポイントを巡る名前解決とルーティングの話
プロキシ側にもVPCエンドポイント置いてませんか????
プロキシを置いているようなパブリックサブネットには、VPCエンドポイントは置かないほうがよい!!（特にゲートウェイ型!!）
その理由は、以下のような状況が考えられるからです。
プロキシに流したAWSサービス向けの通信が、意図せずVPCエンドポイントに流れ、VPCエンドポイントに設定されたポリシーやアクセス先S3バケットのバケットポリシーの制御を受けて、結果としてサービスへのアクセスが不可となる事象が発生する可能性があります。
「環境の構成が理解できていればそんなこと起こらないのでは??」と思いますが、特にエンタープライズの大規模な（”共通プロキシ”的なものを置いているような…）環境では、構成の全体像を把握できる人間は結構少ないと思います。
なぜ上記のようになってしまうのか。
順を追って整理してみます。
まず、ゲートウェイ型VPCエンドポイントの仕組みを振り返ります。
EC2から東京リージョンのS3のエンドポイントにアクセスしようとするとき、流れとしては次のようになります。
＝＝＝＝＝＝＝＝＝＝
s3.ap-northeast-1.amazonaws.com を問い合わせ）＝＝＝＝＝＝＝＝＝＝
ルートテーブルの設定によって、通信がVPCエンドポイントに流れ、プライベート通信が成立という点がポイントです。
逆に言えば、ゲートウェイ型VPCエンドポイントだけ作っても、ルートテーブルの設定がなければ意味がありません！
次に、インターフェイス型VPCエンドポイントの仕組みを振り返ります。
EC2から東京リージョンのSSMのエンドポイントにアクセスしようとするとき、流れとしては次のようになります。
＝＝＝＝＝＝＝＝＝＝
ssm.ap-northeast-1.amazonaws.com を問い合わせ）＝＝＝＝＝＝＝＝＝＝
インターフェイス型VPCエンドポイントを利用している環境では、紐づくサービスのエンドポイントは プライベートIPで名前解決 され、VPC内のローカル通信として処理される点がポイントです。
AWSサービスの利用に限らず、URLを使った全ての通信は最初に名前解決を行います。
では、プロキシを使って通信を行う場合、クライアント、あるいはプロキシのどちらが名前解決を担うのか。
答えはプロキシです。
例えば、クライアントから投げられた s3.ap-northeast-1.amazonaws.com へのリクエストは、そのままプロキシに流れ、プロキシ側で名前解決がなされます。
非常にイメージしやすい図がありましたので、紹介させていただきます。
（出典）【図解】httpプロキシサーバの仕組み(http GET/https CONNECTメソッド)や必要性・役割・メリットデメリット・DNSの名前解決の順序
AWSサービスへのリクエストがプロキシに投げ込まれた場合、プロキシ側でエンドポイントの名前解決がされ、その結果、プロキシが存在するサブネットのルートテーブルに従ってVPCエンドポイントに通信が向かうということが、ご理解いただけたと思います。
特にゲートウェイ型VPCエンドポイントは、VPCエンドポイントポリシーで接続先のリソースを制限している場合があり、そこにハマるとトラブルに直結します。
なかなかマイナーな設定かと思いますが、だからこそ、注意が必要です。
上記でも何度か例示しましたが、AWSサービスのエンドポイントは s3.ap-northeast-1.amazonaws.com という形になっており、つまり リージョンごとにAWSサービスのエンドポイントは違います。
では、クロスリージョンのAWSサービス間通信でプロキシとVPCエンドポイントを利用したらどうなるの・・・??
ここで次のケースを考えてみたいと思います。
＝＝＝＝＝＝＝＝＝＝
【プロキシサーバ】
【クライアント（接続元EC2）】
＝＝＝＝＝＝＝＝＝＝
この環境でのS3向け通信の経路について、様々なパターンを考えてみます。
結論としては、以下のようになります。
プロキシサーバ（大阪） ⇒ VPCエンドポイント ⇒ S3（大阪）
プロキシサーバ（大阪） ⇒ インターネットゲートウェイ ⇒ S3（東京）
★ポイント1★
他リージョンのS3へのアクセスは、VPCエンドポイントに向かわず、インターネットゲートウェイに向かう
EC2（大阪） ⇒ プロキシサーバ（大阪） ⇒ VPCエンドポイント（プロキシ側） ⇒ S3（大阪）
EC2（大阪） ⇒ VPCエンドポイント（クライアントEC2側） ⇒ S3（大阪）
EC2（大阪） ⇒ プロキシサーバ（大阪） ⇒ インターネットゲートウェイ ⇒ S3（東京）
対象の通信のルートが無いことにより通信が失敗
★ポイント2★
プロキシ除外設定をしてはじめて、通信がVPCエンドポイントに行く!!
プロキシに向かわせたくない通信はNO_PROXYに書いておく
EC2（東京） ⇒ プロキシサーバ（大阪） ⇒ VPCエンドポイント（プロキシ側） ⇒ S3（大阪）
対象の通信のルートが無いことにより通信が失敗
EC2（東京） ⇒ プロキシサーバ（大阪） ⇒ インターネットゲートウェイ ⇒ S3（東京）
EC2（東京） ⇒ VPCエンドポイント（クライアントEC2側） ⇒ S3（東京）
★ポイント4★
プロキシと同じリージョンのS3にプロキシ経由でアクセスする場合、プロキシからプロキシ側のVPCエンドポイントに通信が捻じ曲げられる
以上、プロキシ環境下でVPCエンドポイントを使うときは注意が必要！ということをご紹介しました。
VPCエンドポイントは気軽に作成でき、ゲートウェイ型VPCエンドポイントに至っては無料で利用できるので、何も考えずに「とりあえず作っとけ！」となることもあると思います。
しかし、そこにプロキシが入ると、通信経路が思わぬ形になり、トラブルの種となる可能性がありますので、十分にご注意ください。
最後までお目通しいただき、ありがとうございました！
Be the first to comment
