ALB の裏に IIS を置いた時の ERR_TOO_MANY_REDIRECTS をコードを触らずに直す
はじめに
こんにちは、クラスメソッドオペレーションズの watabo です。
今回は若干レガシーな AWS マイグレーションで起こりそうな事象の記事です。
オンプレミス時代に IP アドレスで直接アクセスしていた IIS の Web アプリを ALB 配下に移行したところ、「トップページは開けるのに、一部の画面だけ開けない」という事象に遭遇しました。
原因は ALB あるあるのリダイレクトループです。
直し方を調べると、アプリのコードを修正する記事がほとんどでした。
ただ、運用側では「アプリはベンダー管理なので、コードには手を出せない」ことも多いはずです。
そこで今回は、IIS マネージャーの画面操作だけで直す方法を検証環境で試してみました。
環境
| 項目 | 内容 |
|---|---|
| ロードバランサー | ALB（HTTPS:443 で TLS 終端 → ターゲットへ HTTP:80） |
| OS | Windows Server 2022 日本語版 |
| Web サーバー | IIS 10 |
| アプリ | ASP.NET Core（インプロセスホスティング、UseHttpsRedirection あり） |
構成例
発生した事象
対象の画面を開くと、ブラウザにこう表示されます。
curl で見てみると、アクセスした URL と同じ URL に 307 で飛ばされ続けていました。
curl -sk -o /dev/null -D - https://loop.example.com/demo/
HTTP/2 307
location: https://loop.example.com/demo/
ALB のアクセスログでも elb_status_code=307 / target_status_code=307 になっていて、リダイレクトしているのは ALB ではなくアプリ（IIS 側）だと分かります。
結論
IIS の構成エディターで、環境変数を 1 つ追加すれば直ります。
| 名前 | 値 |
|---|---|
ASPNETCORE_FORWARDEDHEADERS_ENABLED |
true |
なぜループするのか
ALB で HTTPS を終端する構成では、ALB が「鍵付きの封筒（HTTPS）」を開けて、中身だけを EC2 に HTTP で渡します。
EC2 のアプリからは、HTTP で届いたように見えます。
そこにアプリの UseHttpsRedirection（HTTP で来たら HTTPS へ案内し直す機能）が働くと、次のループになります。
- ブラウザ「HTTPS で送ります」
- ALB「開封して HTTP で渡します」
- アプリ「HTTP ですね。HTTPS で来てください」（307）
- 1 に戻る
実は ALB は「元は HTTPS だったよ」というメモ（X-Forwarded-Proto: https）を付けてくれています。
アプリがこのメモを読んでいないのが、根本の原因です。
「IIS の裏だから大丈夫」ではなかった
ここが今回一番ハマったところです。
ASP.NET Core には、IIS の裏で動かすときに X-Forwarded-Proto を自動で読んでくれる仕組み（IIS 統合）があります。
なので「IIS で動いているなら勝手にやってくれるのでは？」と思っていました。
ところが公式ドキュメントを読むと、この自動設定には条件がありました。
いろいろ書いているのですが、要約すると以下です。
- 自動で有効になるのは アウトプロセスホスティング (Out-of-Process) の場合だけ
- しかも信頼するのは 単一の localhost のプロキシ（= 同じサーバー上の IIS 自身）だけ
今回のアプリは インプロセスホスティング (In-Process) なので、そもそも自動設定の対象外です。
仮にアウトプロセスだったとしても、信頼されるのは IIS 自身だけなので、その手前にいる ALB のメモまでは読んでくれません。
つまり、アプリから見ると ALB は「IIS 以外のリバースプロキシ」 です。
ドキュメントでも、IIS 以外のリバースプロキシの裏で UseHttpsRedirection を使うと無限ループになる、と明記されています。
Apps that call UseHttpsRedirection and UseHsts put a site into an infinite loop if deployed to an Azure Linux App Service, Azure Linux virtual machine (VM), or behind any other reverse proxy besides IIS.
「IIS で動いているから大丈夫」は、ALB を挟んだ時点で通用しなくなります。
補足: インプロセスホスティングは、.NET Core 2.2 以降のデフォルト設定です。
直し方（IIS マネージャーだけで完結）
1. 構成エディターを開く
IIS マネージャーで サイト → Default Web Site → demo（対象アプリ）を選び、構成エディターを開きます。
2. system.webServer/aspNetCore を選ぶ
上部の「セクション」から system.webServer → aspNetCore を選びます。
3. 環境変数を追加する
environmentVariables の「…」をクリックし、「追加」から次の値を入力します。
- name:
ASPNETCORE_FORWARDEDHEADERS_ENABLED - value:
true
閉じたら右側の 適用 をクリック。アプリが自動で再起動されます。
4. 確認
ページを再読み込みすると、表示されるようになりました。
アプリが認識しているスキームが https になっていて、ALB のメモを読めていることが分かります。
注意点
- アプリの再発行で設定が消えることがある
この手順の設定はweb.configに書き込まれるため、ベンダーがアプリを入れ直すと上書きされる場合があります。
長く使うなら、サーバーノードの構成エディター →system.applicationHost/applicationPools→ 対象のプール →environmentVariablesに設定しておくと安心です。 - EC2 は ALB からの通信だけ受け付けること
この環境変数を使うと、どこから来たメモでも信じるようになります（ドキュメントにも、信頼するプロキシを絞る機能は効かないと注意書きがあります）。
EC2 のセキュリティグループは、ALB のセキュリティグループからの通信だけを許可しておきましょう。
他の直し方として、以下の方法もあります。
- ターゲットグループを HTTPS にする
- アプリに
UseForwardedHeadersを追加する
インフラ側・開発側で対応できるなら、そちらも選択肢です。
さいごに
ALB の裏にいるアプリは、自分が HTTPS で呼ばれていることを知りません。
そして「IIS で動いているから大丈夫」も、インプロセスホスティングでは通用しません。
IIS の画面にはそれらしい設定項目がないので、「SSL が必要」のチェックボックスをいじって迷子になりがちですが、構成エディターで環境変数を 1 つ足すだけで直せます。
コードに手を出せない運用担当の方の助けになれば幸いです。
