Azure のいろいろなサービスでリバース プロキシを作るぞ

とあるところから以下のようなと相談がありまして、いろいろ試してみました。


# おなやみごと

- ユーザーの端末はインターネットへの接続を許可されていない閉域環境にある。ただ、ある外部 Web サイト 
(第三者が管理？) へのアクセスだけは許可したい。
- 上記の外部 Web サイトは一部のユーザーだけが使用する (ある作業の一場面でしか使用しない) ので、Azure Firewall (Premium) を導入するまででもない。他のサービスを利用して実現したい。 
- 端末の「プロキシ サーバーの設定」は別の用途で設定済みであるため、このための設定変更はできない。


# 準備する

## 検証環境を用意する

相談事を検証するため、Azure 上に仮想ネットワークをデプロイし、下図のような構成で用意しました。
「リバース プロキシ (:question: のところ)」に配置するものについて検証していきます。
なお、クライアントはとりあえず Windows OS の端末と想定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/baacbbdc-f380-a253-6b6f-21194841a5fb.png)


## ターゲットとなる外部 Web サイトを調べる

対象の外部 Web サイトにアクセスした時、およびそのサイトで操作した時に発生する通信 (どのような FQDN に対して通信が発生するか) を把握しましょう。
地道に行うなら、ブラウザーの [開発者ツール] の [ネットワーク] タブで、操作ごとに発生する通信を確認すれば良いと思います。(もっと良い方法はあると思いますけど...:sweat_smile:)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/7567bce7-aa3b-73c2-531e-d8231839a8d1.png)

おおよその Web サイトでは、以下のような構成、および振る舞いを行っていると思います。

1. HTTPS のみのアクセスを許可している。
2. ページ内のコンテンツが (FQDN が異なる) 複数のサーバー (Web サイトや CDN) に配置されている。 (JavaScript、CSS、画像 など) 
3. 表示されたページ内で何らかの操作を行うと、JavaScript などが Web サイトに対してリクエストしている (リンクを踏めばこうなる)。


## SSL 証明書と名前解決

[前述](#%E3%82%BF%E3%83%BC%E3%82%B2%E3%83%83%E3%83%88%E3%81%A8%E3%81%AA%E3%82%8B%E5%A4%96%E9%83%A8-web-%E3%82%B5%E3%82%A4%E3%83%88%E3%82%92%E8%AA%BF%E3%81%B9%E3%82%8B)について、クライアントのブラウザーから HTTPS でかつ完全な URL (対象の外部 Web サイトの URL) でアクセスする場合は、クライアントとリバース プロキシ (:question: のところ) 間も HTTPS でかつその URL (FQDN) で通信できなければならないので、SSL 証明書を用意します。今回はプライベートな環境で使用する目的で自己署名証明書を PowerShell で以下のようなかんじで作成しておきます。

```powershell:自己署名証明書を作成する
New-SelfSignedCertificate `
  -Type SSLServerAuthentication `
  -Subject "*.example.com" `
  -DnsName "*.example.com", "example.com" `
  -CertStoreLocation "cert:\LocalMachine\My" `
  -KeyDescription "Self-signed certificate" `
  -KeyExportPolicy Exportable `
  -NotAfter (Get-Date).AddYears(30)
```

作成した証明書 (PKCS #12 でエクスポート) は、クライアントの証明書ストア (信頼されたルート証明機関) にインポートします。

名前解決については、クライアントの hosts ファイルに記載して行うこととします。
※クライアントからのリクエストに「ホスト名」が含まれる想定。


# リバースプロキシとして検証してみたサービス

リバース プロキシとなりそうな候補として、以下の 3 つのサービスについて検証してみました。

- **Windows 仮想マシン (IIS+ARR)**
- **内部 App Service Environment (ILB ASE)**
- **Azure Application Gateway (SKU v1, v2)**

これらについて、順に説明していきます。


## リバプロとして Windows 仮想マシン (IIS+ARR)

こんなかんじの構成で。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/ace7d719-5d4a-d822-a37a-7ab8b23c49bc.png)


### IIS と Web サイトを構築する

今回は、Web サーバーとして「Internet Information Services (IIS)」を利用します。仮想マシン (Windows Server) を作成してサーバーの役割で「Web サービス (IIS) 」を追加します。

リバース プロキシとして「Application Request Routing (ARR)」を利用します。インストーラーは以下からダウンロードできます。

https://www.iis.net/downloads/microsoft/application-request-routing

IIS 上の Web サイトは (プライベート) IP アドレス＋ポートの組み合わせでひとつずつ作成するのがカンタンだと思います。また、Web サイトにバインドできる SSL 証明書 (サーバー証明書) をひとつのみですので、ドメイン単位でサブドメインのワイルドカードの SSL 証明書 (前述で作成した[証明書](#ssl-%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%81%A8%E5%90%8D%E5%89%8D%E8%A7%A3%E6%B1%BA)) を用意して、Web サイトをバインドします。(ドメイン単位で Web サイトを作成して SSL 証明書をバインド)

場合によっては、複数の IP アドレスを用意する必要があります。仮想マシンに複数の IP アドレスを割り当てる方法については、以下のドキュメントをご参考ください。

- ひとつのネットワーク インターフェイス カード (NIC) に複数のプライベート IP アドレスを割り当てる方法

https://docs.microsoft.com/ja-jp/azure/virtual-network/ip-services/virtual-network-multiple-ip-addresses-portal?WT.mc_id=AZ-MVP-5003113

- 仮想マシンに複数のネットワーク インターフェイス カード (NIC) をアタッチする方法

https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/multiple-nics?WT.mc_id=AZ-MVP-5003113

IIS 上の Web サイトは以下のような構成で用意します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/c2665795-0617-12d0-31b4-816a80c3e817.png)


### URL を書き換える

IIS 上の Web サイトにアクセスしてきたら、対象の外部 Web サイト (FQDN) にアクセスできるようにします。
Web サイトごとに「URL 書き換え」で設定していきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/9c86d395-dbc8-028d-7b16-2d9907968531.png)

要求されたホスト名が一致した時は該当の外部 Web サイト (FQDN) の URL を書き換える、一致しない時は次のルールに遷移するというように書き換えルールを作っていきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/dc525ba4-33ad-7960-7408-608009605aa5.png)

作成した書き換えルールは Web サイトの web.config に保存されます。

```xml:web.config
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="Access To www" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTP_HOST}" pattern="^www.example.com$" />
                    </conditions>
                    <action type="Rewrite" url="https://www.example.com/{R:1}" />
                </rule>
                <rule name="Access To apis" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTP_HOST}" pattern="^apis.example.com$" />
                    </conditions>
                    <action type="Rewrite" url="https://apis.example.com/{R:1}" />
                </rule>
                <!-- (中略) -->
            </rules>
        </rewrite>
    </system.webServer>
</configuration>
```


### アクセスログを設定する

リバース プロキシとして ARR を使うと、アクセスログにはアクセス元の IP アドレスではなく、IIS 上の Web サイトの IP アドレスが記録されてしまいます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/62eed3ba-3c00-f762-ed93-260f7323b322.png)

アクセスログにアクセス元の IP アドレスを記録したい場合のひとつの手として、IIS のログ記録でカスタムフィールドを追加して HTTP ヘッダーの「[X-Forwarded-For](https://ja.wikipedia.org/wiki/X-Forwarded-For)」を設定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/06b5638b-9283-b6d7-4ff8-7e98d7de92d8.png)

このように設定することによって、アクセス元の IP アドレス (X-Forwarded-For) が出力されるようになります。[^1]

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/8d0bc632-f2a4-875a-3464-0db20912ab6e.png)


## リバプロとして 内部 App Service Environment (ILB ASE)

こんなかんじの構成で。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/02729c8b-a5b9-9f5a-bba9-0848463327ab.png)

前述の[仮想マシン上の IIS+ARR](#%E3%83%AA%E3%83%90%E3%83%97%E3%83%AD%E3%81%A8%E3%81%97%E3%81%A6-windows-%E4%BB%AE%E6%83%B3%E3%83%9E%E3%82%B7%E3%83%B3-iisarr) で構築した内容を「ILB ASE」で実現してみます。

https://docs.microsoft.com/ja-jp/azure/app-service/environment/overview?WT.mc_id=AZ-MVP-5003113

以下のドキュメントの手順を参考に「ILB ASE」と「Web アプリ」を作成します。
※デプロイにかなりの時間 (数時間ほど) がかかりますので焦らずに。

https://docs.microsoft.com/ja-jp/azure/app-service/environment/creation?WT.mc_id=AZ-MVP-5003113

https://docs.microsoft.com/ja-jp/azure/app-service/environment/create-ilb-ase?WT.mc_id=AZ-MVP-5003113


### カスタム ドメインを追加する

前述で作成した[証明書](#ssl-%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%81%A8%E5%90%8D%E5%89%8D%E8%A7%A3%E6%B1%BA)を Web アプリにバインドするため、カスタム ドメインを追加します。
なお、ILB ASE では、カスタム ドメインを所有者の検証なしで追加することができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/5a3bd386-51a8-db99-bbc9-124a62df99e9.png)


### 証明書をバインドする

前述で作成した[証明書](#ssl-%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%81%A8%E5%90%8D%E5%89%8D%E8%A7%A3%E6%B1%BA)をアップロードして、

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/ed3e063f-9823-3101-88a9-becad13ab8f1.png)

追加したカスタム ドメインにバインドします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/3786572d-40ed-e438-5a0c-0bb753c14fa3.png)

https://docs.microsoft.com/ja-jp/azure/app-service/environment/overview-certificates?WT.mc_id=AZ-MVP-5003113

https://docs.microsoft.com/ja-jp/azure/app-service/environment/certificates?WT.mc_id=AZ-MVP-5003113


### IIS のリバース プロキシ機能を有効にする

[Kudu](https://docs.microsoft.com/ja-jp/learn/modules/azure-diagnose-application-startup-errors-with-kudu-console/?WT.mc_id=AZ-MVP-5003113) で /site 配下に applicationHost.xdt を配置します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/370aadc4-affc-ca91-3de1-2c792ea8edb3.png)

applicationHost.xdt の内容は以下のとおりに記載して保存します。その後、Web アプリに設定を反映するために再起動しましょう。[^2]

```xml:applicationHost.xdt
<?xml version="1.0" encoding="UTF-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.webServer>
    <proxy
        xdt:Transform="InsertIfMissing"
        enabled="true"
        preserveHostHeader="false"
        reverseRewriteHostInResponseHeaders="false" />
  </system.webServer>
</configuration>
```


### URL を書き換える

[Kudu](https://docs.microsoft.com/ja-jp/learn/modules/azure-diagnose-application-startup-errors-with-kudu-console/?WT.mc_id=AZ-MVP-5003113) で /site/wwwroot 配下に web.config を配置します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/26ea3cf9-0e26-7fec-b35d-ef31cb78d22d.png)

前述の Windows 仮想マシン (IIS+ARR) の「[URL を書き換える](#url-%E3%82%92%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88%E3%82%8B)」の時と同じように URL の書き換えルールを書きます。前述との違いは、すべての FQDN に対する書き換えルールをひとつの web.config にまとめて記載します。

```xml:web.config
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="Access To www.example.com" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTP_HOST}" pattern="^www.example.com$" />
                    </conditions>
                    <action type="Rewrite" url="https://www.example.com/{R:1}" />
                </rule>
                <rule name="Access To apis.example.com" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTP_HOST}" pattern="^apis.example.com$" />
                    </conditions>
                    <action type="Rewrite" url="https://apis.example.com/{R:1}" />
                </rule>
                <rule name="Access To demodemo.jp" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTP_HOST}" pattern="^demodemo.jp$" />
                    </conditions>
                    <action type="Rewrite" url="https://demodemo.jp/{R:1}" />
                </rule>
                <!-- (中略) -->
            </rules>
        </rewrite>
    </system.webServer>
```

### ネットワークのアクセス制御とルーティングを設定する

以下のドキュメントを参考に、NSG とルートテーブルを設定します。

https://docs.microsoft.com/ja-jp/azure/app-service/environment/networking?WT.mc_id=AZ-MVP-5003113

https://docs.microsoft.com/ja-jp/azure/app-service/environment/network-info?WT.mc_id=AZ-MVP-5003113


### 診断ログを有効にする

アクセスログ (AppServiceHTTPLogs) は、診断ログを有効にすることで出力されます。以下のドキュメントを参照してください。

- ログを Azure Monitor に送信する

https://docs.microsoft.com/ja-jp/azure/app-service/troubleshoot-diagnostic-logs?WT.mc_id=AZ-MVP-5003113#send-logs-to-azure-monitor

出力される AppServiceHTTPLogs の内容については、以下のドキュメントを参照してください。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/reference/tables/appservicehttplogs?WT.mc_id=AZ-MVP-5003113

IIS のアクセスログを出力したい場合は、以下のドキュメントを参照してください。

- Web サーバーのログ記録を有効にする

https://docs.microsoft.com/ja-jp/azure/app-service/troubleshoot-diagnostic-logs?WT.mc_id=AZ-MVP-5003113#enable-web-server-logging


## リバプロとして Azure Application Gateway

こんなかんじの構成で。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/421dec7f-7903-d520-31ea-82936801c6c6.png)

Application Gateway は、ホスト名によるルーティングする仕組みがないため、対象の外部 Web サイトの FQDN ごとに以下の要素を用意する必要があります。

- リスナー
- バックエンドプール
- HTTP 設定
- 要求ルーティング規則

https://docs.microsoft.com/ja-jp/azure/application-gateway/multiple-site-overview?WT.mc_id=AZ-MVP-5003113


### バックエンド プールを作成する

バックエンド プールは、外部 Web サイトの FQDN ごとに作成します。
[ターゲットの種類] で「IP アドレスまたは FQDN」を選択し、[ターゲット] に[先に調べた FQDN](#%E3%82%BF%E3%83%BC%E3%82%B2%E3%83%83%E3%83%88%E3%81%A8%E3%81%AA%E3%82%8B%E5%A4%96%E9%83%A8-web-%E3%82%B5%E3%82%A4%E3%83%88%E3%82%92%E8%AA%BF%E3%81%B9%E3%82%8B) を入力します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/552a12f6-3c82-c79a-a435-efeaf5f47748.png)


### HTTP 設定を作成する

バックエンド プールの外部 Web サイトに HTTPS でアクセスする必要がある場合は、「End to End TLS 暗号化」を使用します。そのためには、この HTTP 設定で対象の外部 Web サイトの証明書 (Base-64 エンコード X.509(.CER) 形式) をアップロードする必要があります。なお、必要な証明書は SKU によって異なります (後述)。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/823c0a8f-5ed4-d4d5-5dbc-cfca5b668e84.png)

- Application Gateway でのエンド ツー エンド TLS 暗号化

https://docs.microsoft.com/ja-jp/azure/application-gateway/ssl-overview?WT.mc_id=AZ-MVP-5003113#end-to-end-tls-encryption


#### Application Gateway v1 で必要な証明書

Application Gateway v1 では「認証証明書 (バックエンド サーバー証明書の公開キー)」が必要です。入手方法については、以下のドキュメントを参照してください。

- 認証証明書をエクスポートする (v1 の場合)

https://docs.microsoft.com/ja-jp/azure/application-gateway/certificates-for-backend-authentication?WT.mc_id=AZ-MVP-5003113#export-authentication-certificate-for-v1-sku

なお、ブラウザーで対象の Web サイトにアクセスして、下図のように証明書を表示して赤枠のものをファイルコピーすることもできます (試したときはできました)。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/f27431de-9163-a1a9-77ca-a5534ef69e0b.png)


#### Application Gateway v2 で必要な証明書

Application Gateway v2 では「信頼されたルート証明書」が必要です。入手方法については、以下のドキュメントを参照してください。

- 信頼されたルート証明書をエクスポートする (v2 の場合)

https://docs.microsoft.com/ja-jp/azure/application-gateway/certificates-for-backend-authentication?WT.mc_id=AZ-MVP-5003113#export-trusted-root-certificate-for-v2-sku

なお、ブラウザーで対象の Web サイトにアクセスして、下図のように証明書を表示して赤枠のものをファイルコピーすることもできます (試したときはできました)。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/4d65a9cd-790a-4223-7fd3-507ed3cb687c.png)


#### 正常性プローブを作成する

また、バックエンド サーバーで End to End TLS 暗号化を有効にし、それらに対して Application Gateway から要求をルーティングするには、正常性プローブが成功して、正常な応答が受け取れなければなりません。このために「正常性プローブ」を用意します。
この正常性プローブには、実際にエンドユーザーがアクセスする URL (Web サーバー) で HTTP ステータス「200 ～ 399」を必ず返すコンテンツ (Favicon とか) を指定すれば良いと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/d95b7ad9-1e24-7c66-5dc0-ef445f5ae3a2.png)

そして、各 HTTP 設定で「カスタム プローブ」を使用し、この「正常性プローブ」を指定すれば良いでしょう。


#### 新しいホスト名でオーバーライドする

Application Gateway を経由してバックエンド サーバーにアクセスした場合、バックエンド サーバー (対象の外部 Web サイト) には Application Gateway のホスト名が送信されます。
対象の外部 Web サイトでどのように処理しているかわからない場合は、この項目に対象のホスト名 (FQDN) を設定しておくとこの値がバックエンド サーバーに送信されるので、設定しておくほうが良いでしょう。


### リスナーを作成する

クライアントから HTTPS でアクセスするため、先に作成した [SSL 証明書 (自己署名証明書)](#ssl-%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%81%A8%E5%90%8D%E5%89%8D%E8%A7%A3%E6%B1%BA) をアップロードしておきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/a7e44b39-99ec-75a1-825c-b96700f92229.png)

- Application Gateway での TLS termination

https://docs.microsoft.com/ja-jp/azure/application-gateway/ssl-overview?WT.mc_id=AZ-MVP-5003113#tls-termination

また、FQDN ごとにリスナーを作成する必要があるので、[リスナーの種類] で「マルチサイト」を選択し、[ホスト名] にそれぞれの FQDN を入力します。


### 要求ルーティング規則を作成する

要求ルーティング規則によって、先に作成した「リスナー」が「バックエンド プール」と「HTTP 設定」にバインドされます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/7720ab3c-03b2-1862-7e8d-4f14e0afe577.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/230264/3c842cf2-79e8-76e3-73cf-a704b684cd8b.png)

https://docs.microsoft.com/ja-jp/azure/application-gateway/configuration-request-routing-rules?WT.mc_id=AZ-MVP-5003113


### ネットワークのアクセス制御とルーティングを設定する

以下のドキュメントを参考に、NSG とルートテーブルを設定します。

https://docs.microsoft.com/ja-jp/azure/application-gateway/configuration-infrastructure?WT.mc_id=AZ-MVP-5003113


### 診断ログを有効にする

アクセスログ (ApplicationGatewayAccessLog) は、診断ログを有効にすることで出力されます。以下のドキュメントを参照してください。

https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-diagnostics?WT.mc_id=AZ-MVP-5003113#diagnostic-logs

出力される ApplicationGatewayAccessLog の内容については、以下のドキュメントを参照してください。

- Application Gateway v1 の場合

https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-diagnostics?WT.mc_id=AZ-MVP-5003113#for-application-gateway-standard-and-waf-sku-v1

- Application Gateway v2 の場合

https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-diagnostics?WT.mc_id=AZ-MVP-5003113#for-application-gateway-and-waf-v2-sku


### ちょっと気になる点...

#### フロントエンド IP が気になる

Application Gateway v2 のフロントエンド IP には**必ずパブリック IP アドレスが付きます**。プライベート IP のみの構成はサポートされていません。プライベート IP のみ使用したい場合は、以下の FAQ をご参考ください。

- プライベート フロントエンド IP アドレスのみで Application Gateway V2 を使用するにはどうすればよいですか?

https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-faq?WT.mc_id=AZ-MVP-5003113#---------------ip---------application-gateway-v2------------------


#### NSG が気になる

Application Gateway で NSG はサポートされていますが、インターネットへのアウトバウンドで特定のポート (例えば HTTP と HTTPS) のトラフィックのみを許可して、これ以外のトラフィックを拒否するというようなルールを設定することはできません。

- ネットワーク セキュリティ グループ

https://docs.microsoft.com/ja-jp/azure/application-gateway/configuration-infrastructure?WT.mc_id=AZ-MVP-5003113#network-security-groups

ただ、Application Gateway のリソースを配置するサブネットには、Application Gateway のリソースしか配置できないので、それほど気にする必要はないかもしれませんけど。


# まとめ

今回利用したサービスを以下のように「そもそもの役割」で分けることができると思います。

- **リバース プロキシ**
    - Windows 仮想マシン (IIS+ARR)
    - 内部 App Service Environment (ILB ASE)
- **L7 ロード バランサー**
    - Azure Application Gateway (SKU v1, v2)

**「リバース プロキシ」**で括ったサービスは「URL Rewrite」という機能を使って、バックエンドのサーバーである対象の外部 Web サイトが動作しているか否かは意識せず、各サービス上に設置した Web サイトにアクセスされた時の振る舞い (URL 書き換え) を定義しました。
また、「URL 書き換えルール」は web.config に保存されるため、このファイルをアプリケーションのソースとして別途管理したほうが良さそうですね。

いっぽう**「ロードバランサー」**で括ったサービスは、バックエンドのサーバーである対象の外部 Web サイトが動作しているか否かを意識しなければなりません。そのために End to End TLS 暗号化やバックエンドの正常性チェックを施す必要があります。そして、End to End TLS 暗号化を有効にするためには、バックエンドのサーバーである対象の外部 Web サイトの証明書 (v1 の場合は公開キーの証明書、v2 の場合は信頼されたルート証明書) が必要で、証明書が更新されたら、Application Gateway の HTTP 設定にアップロードした証明書も更新する (第三者が管理している場合はいつ更新されるか分からず、後追いで対応することになるだろう) 運用が必要ですね。


[^1]: [こちらの記事](https://blog.shibayan.jp/entry/20150130/1422602421)を参考にさせていただきました。多謝。
[^2]: [こちらの記事](https://logico-jp.io/2021/03/22/use-app-service-as-a-reverse-proxy/)を参考にさせていただきました。多謝。