はじめに
前回以下の記事を書きましたが、JPCYBERのACL設定が正常に適用されるかは確認ができませんでした。
https://qiita.com/handy-dd18/items/8bd91eba22d46ab66ba9
そこで今回はJPCYBERの通信をWiresharkで見て、どのような処理をしているのかを追ってみようと思います。
パケットレベルのネットワークはそこまで理解していないので、変な表現があってもご了承ください。
Wireshark確認
事前確認
環境は前回の流用ですが、最低限以下は既に整っていることとします。
・ファイルアップロードするAWSアカウントとS3のあるAWSアカウントは別
・アップロード元AWSアカウント上でEC2(JPCYBER)を準備
・JPCYBERはEC2にアタッチされたIAMロールの権限を使用する
・S3バケットのポリシーでIAMロールを許可
・EC2にはWiresharkをインストール済み
確認内容
前回記事ではJPCYBERは想定通りにできず、CloudBerryDriveは想定通りにできました。
CloudBerryDriveの設定では、S3へ送信するリクエストヘッダにx-amz-aclを追加したことで、AWS CLIと同じように設定がされたのだと思います。
そのため、今回はJPCYBERのオプション設定のACL項目にチェックを入れたときに、リクエストヘッダに同じパラメータが設定されるかを確認します。
JPCYBER設定
検証用に作成したS3バケットをJPCYBERでマウントします。
この時の注意点は「SSL/TLS暗号化通信を使用する」チェックを外しておくことです。
そうすることで復号しなくてもWiresharkでパケットを確認することができます。
※検証される場合は自己責任でお願いします。
サービス状態が実行中で割り当て済みドライブに名前があれば設定完了です。
エクスプローラーからS3の中身が確認できました。
オプション設定の「親バケットの～」のチェックをつけておきます。
ファイルアップロード
まずは普通にファイルをアップロードしてみます。
チェックは付けていたはずですが、親バケットのACLは適用されていないようです。
Wireshark起動
Wiresharkを起動してイーサネットを選択します。
パケットのキャプチャがスタートします。
今回はHTTPのパケットだけ確認出来たらよいので、フィルタで絞っておきます。
ファイル再アップロード
Wiresharkの設定ができたところでファイルを再度アップロードします。
操作時のパケットは以下のようです。思ったよりも出ているようです。
順番に見ていきます。
最初にdesktop.iniのヘッダ情報を取ろうとしていますが、当然そんなファイルがないので404エラーで返されています。
次にGETリクエストが投げられています。
demlimiterに2F(/)、list-typeとmax-keysがあり、Prefixがブランクであることから、S3バケット配下のリストしていると思われます。
その後アップロードするファイルが既に存在しているか確認しています。
testフォルダの配下にアップロードしたので、併せてtestフォルダ配下に対してリストが実施されているようです。
既存ファイルがなく、リストリクエストも問題ないことが確認出来た段階でファイルをアップロードしています。
これを見る限りはアップロード→ACL設定の順番でリクエストが送られているようです。
ただ、ACL設定のリクエストで403エラーが発生しており、アップロードだけが成功している状態のようです。
見る限り2回試行してダメであれば終了するようです。
ACL設定のリクエストではQuery Parameterにaclが設定されています。
CloudBerryDriveではリクエストヘッダにX-Amz-Aclパラメータがありましたが、JPCYBERのリクエストではありませんでした。(当然ですが)
レスポンスを確認しましたが、権限ではじかれたことぐらいしかわかりませんでした。
CloudBerryDriveと比較してみる限りだと、リクエストがアップロードとACL設定で分かれているので、そもそもの設定方法が異なるようでした。
終わりに
S3をマウントするツールを使用した場合にどのようにリクエストされているかは今まで曖昧だったので、今回具体的に確認できたのは良かったです。
また、CLIだとオブジェクトアップロード時にACLオプションを設定していますが、JPCYBERの場合はアップロードとALC設定を別々に実行していることがわかったので、その処理の違いも理解できました。
S3のALC周りは理解しきれていないところがあるので、今度はその辺りをもう少し勉強してみることにします。