ARRのURL書き換え先のWebサーバーでリクエストヘッダのHostの値が内部サーバーのIPやホスト名にならないようにする - IIS

ARRのURL書き換え先のWebサーバーでHostの値が内部サーバーのIPやホスト名にならないようにするための設定方法を紹介します。

概要

ARRを利用してURLの書き換えをして別のアプリケーションサーバーでWebアプリケーションを実行した場合、Webアプリケーションが動作するサーバーでは、 リクエストヘッダのHostの値がそのサーバーのIPアドレスやホスト名になってしまいます。
そのため、Hostの値を基にした処理を実行する場合本来のアクセス先のホスト名とは異なるホスト名になり処理で不具合が発生する場合があります。
この記事では、ARRでURLを書き換えた場合に、書き換え先のWebサーバーでHostの値をアクセスしたホストの値にする設定を紹介します。

動作の確認

リバースプロキシのある構成を例にします。https://abc.ipentec.com/app1 にアクセスすると、リバースプロキシがURLを書き換え内部のWebサーバーへのアクセスに変えます。リバースプロキシにアクセスした時点でのリクエストヘッダのHostの値はアクセスしてURLのホスト名(この場合は abc.ipentec.com)となりますが、内部のWebサーバーでのHostの値はWebサーバーのIPアドレス(またはホスト名)となります。


アプリケーションを実行する、内部のWebサーバーでHostの値を利用してリダイレクト先のURLを生成する場合を例にします。内部のWebサーバーでのHostの値は内部のWebサーバーのIPアドレスになっているため、Hostの値を利用してリダイレクト先のURLを生成すると https://192.168.nnn.mmm/app1/update のように、内部のWebサーバーを示すURLになってしまいます。一般的に内部のWebサーバーのURLは外部からは参照できないため、このURLにリダイレクトすると、404エラーになります。


そのため、内部のWebサーバーでも、本来アクセスしたホスト名をリクエストヘッダのHostに設定される状態にしたいです。

手順

リバースプロキシが設定されているARRのサーバーで [インターネット インフォメーション サービス(IIS) マネージャー]を起動し、[接続]ツリービューのサーバーノードを選択して[構成エディター]を表示します。
構成エディターの表示手順の詳細はこちらの記事を参照してください。


[構成エディター]の画面が表示されます。中央のエリアの[セクション]のコンボボックスをクリックして開きます。


コンボボックスが開かれドロップダウンウィンドウーが表示されます。ドロップダウンのツリービューの system.webServer/proxy の項目を選択します。
補足
system.webServer/proxy の項目が見つからない場合は、サイトのノードを選択して構成エディターを表示していないか、または、ARRがインストールされているか確認します。
対象サーバーを取り違えている可能性もありますので、操作しているサーバーも確認します。(ARRのリバースプロキシのサーバーではなく、内部のWebサーバーの構成エディターを開いてしまっている事例もあります。)


system.webServer/proxy のセクションの構成エディターの画面が表示されます。中央のエリアに設定できる項目が表示されています。


中央のエリアのpreserveHostHeader項目を変更します。デフォルトでは False になっています。


値を変更して True にします。

結果

preserveHostHeader=false に設定された場合のリクエストヘッダの値を確認します。リクエストヘッダの表示や取得についてはこちらの記事を参照してください。

リクエストヘッダのHostの値を確認すると、内部のWebサーバーのIPアドレスになっていることがわかります。また、アクセス元のクライアントIPアドレスは X-Forwarded-For に設定されていることも確認できます。アクセス元のIPアドレスはリバースプロキシのIPアドレスではなく、アクセス元端末のIPアドレスになっています。

preserveHostHeader=false の場合の出力結果
Accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding : gzip, deflate
Accept-Language : ja,en;q=0.9,en-GB;q=0.8,en-US;q=0.7
Cache-Control : max-age=0
Connection : Keep-Alive
Cookie : __gads=ID=0037bb6518ebd184:T=1591686855:S=ALNI_MbN6jv_XTUgSKwJuRs8hSK914_mMg; _gid=GA1.2.900728549.1599295136; ASP.NET_SessionId=tsoowiurlztes2cmggxxz01f; _ga=GA1.1.15427962.1591686856; _ga_F81X5MMRN8=GS1.1.1600091869.264.1.1600091879.50
Host : 192.168.64.nnn
Max-Forwards : 10
User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36 Edg/85.0.564.51
Upgrade-Insecure-Requests : 1
X-Original-URL : /open/Header/ShowRequestHeader
X-Forwarded-For : 183.77.nnn.mmm:60272
X-ARR-LOG-ID : 1de48cfe-3054-425f-b8a7-da5ea79c2e3d

続いて、preserveHostHeader=true に設定された場合のリクエストヘッダの値を確認します。 Hostヘッダの値がARRのサーバーのホスト名(アクセス元端末で入力したURLのホスト名)になっています。
また、アクセス元のクライアントIPアドレスは X-Forwarded-For に設定されていることも確認できます。アクセス元のIPアドレスはリバースプロキシのIPアドレスではなく、アクセス元端末のIPアドレスになっています。この値は、preserveHostHeaderがfalseの場合と同じ値になっています。

preserveHostHeader=true の場合の出力結果
Accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding : gzip, deflate
Accept-Language : ja,en;q=0.9,en-GB;q=0.8,en-US;q=0.7
Cache-Control : max-age=0
Connection : Keep-Alive
Cookie : __gads=ID=0037bb6518ebd184:T=1591686855:S=ALNI_MbN6jv_XTUgSKwJuRs8hSK914_mMg; _gid=GA1.2.900728549.1599295136; ASP.NET_SessionId=tsoowiurlztes2cmggxxz01f; _ga=GA1.1.15427962.1591686856; _ga_F81X5MMRN8=GS1.1.1600091869.264.1.1600091879.50
Host : test.ipentec.com
Max-Forwards : 10
User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36 Edg/85.0.564.51
Upgrade-Insecure-Requests : 1
X-Original-URL : /open/Header/ShowRequestHeader
X-Forwarded-For : 183.77.nnn.mmm:60272
X-ARR-LOG-ID : e0b0df47-6784-400f-8e9e-5876085ede58
著者
iPentec.com の代表。ハードウェア、サーバー投資、管理などを担当。
Office 365やデータベースの記事なども担当。
最終更新日: 2021-10-30
作成日: 2020-09-15
iPentec all rights reserverd.