ロードバランサーを使った構成で、HTTPをHTTPSにリダイレクトする



X-Forwarded-Protoを使う場合と、使わない場合で、まとめてみました。

AWSだと、このドキュメントにやり方が書いてありますね。

手元にAWS環境がないから試せないけど、流れとしては、下記のような感じだと思います。

  • ロードバランサーに対してHTTPでアクセスされても、HTTPSでアクセスされても、バックエンドWebサーバー(ロードバランサーに紐付いたサーバー)の80番ポートに転送する
  • バックエンドWebサーバー側では、X-Forwarded-Proto リクエストヘッダーを利用して、ロードバランサーに対してHTTPでアクセスされたか、HTTPSでアクセスされたかを判定する
  • ロードバランサーに対してHTTPでアクセスされた場合、URLを書き換える

.htaccess の使用は推奨されていないこと、初めて知りました。
VirtualHostを使えと。

下記、上記ドキュメントから引用。

仮想ホストファイルまたは .htaccess ファイルのいずれかで、mod_rewrite ルールを使用します。リダイレクトルールには仮想ホストファイルを使用することをベストプラクティスとして推奨しています。

注: .htaccess の使用は推奨されません。メインの構成ファイルにアクセスできない場合にのみ使用するようにしてください。

Apacheのサイトでも説明されていますね。

一般的に、サーバの主設定ファイルにアクセスできない場合を除いて、 .htaccess ファイルの使用は極力避けてください。

「HTTP HTTPS リダイレクト」とかで検索すると、.htaccessを利用した例がたくさん出てくるので、注意ですね。

X-Forwarded-Protoは、ここに説明されていますね。

バックエンドWebサーバーから見ると、ロードバランサーにHTTPでアクセスされても、HTTPSでアクセスされても、(上の例では)バックエンドWebサーバーの80番ポートに転送されるので、クライアントがHTTPでアクセスしたか、HTTPSでアクセスしたかを、RewriteCond %{HTTPS} offとかだと判定できません。

X-Forwarded-Protoには、ロードバランサーに対してHTTPでアクセスされたか、HTTPSでアクセスされたかが記載されていますので、バックエンドWebサーバー側でX-Forwarded-Protoを参照することにより、クライアントがHTTPでアクセスしたか、HTTPSでアクセスしたかを判定することができます。

AWSクラシック環境にもあるんですね。

X-Forwarded-Protoを使わない場合は、HTTPとHTTPSで、バックエンドWebサーバーの別のポートに転送すればいいと思います。

このページに紹介された方法が、この方法に当たると思います。

例えば、(リンクのページのやり方とは違いますが)ロードバランサーに対してHTTPでアクセスされたら80番、HTTPSでアクセスされたらウェルノウンポート番号以外の任意のポート番号に転送すればいいです。

これにより、ロードバランサーに対してHTTPでアクセスされたか、HTTPSでアクセスされたかによって、バックエンドWebサーバー側の異なるポートに転送されますので、バックエンドWebサーバー側で判定できます。

HTTPでアクセスされた場合のみ、80番ポートに転送されますので、<VirtualHost *:80></VirtualHost>の中でURLを書き換えれば、HTTPの場合はHTTPSにリダイレクトすることができます。

HTTPSでアクセスされた場合のみ、URLを書き換えることもできますね。例えば、10000番に転送した場合、バックエンドWebサーバーで10000番をListenするように設定し、<VirtualHost *:10000></VirtualHost>にRewriteを設定すれば良いです。

以上のように、ロードバランサーを使った構成で、HTTPをHTTPSにリダイレクトする方法について、X-Forwarded-Protoを使う場合と、使わない場合で、まとめてみました。

コメント

このブログの人気の投稿

PowerShell 6で、Shift_JISのCSVをImport-Csvで読み込んだら文字化けした

Windowsで、特定のユーザーに特定のサービスの再起動を許可する

PowerShellでイベントログを取得する時、「指定した選択条件に一致するイベントが見つかりませんでした。」が煩わしいのでcatchする