Powershellを使ったWildcard Azure Application Gatewayのデプロイ

Azure Application Gateway はもうかなりの年月が経過しています。 過去数年間で、Web Application Firewall 機能のないオリジナルの標準 (V1) から、WAF 機能の有無にかかわらず最新の標準 (V2) へと変化しているのが見て取れます。 2019年4月30日にV2版がリリースされたので、おそらく今頃はV1のほとんどを置き換えていることでしょう（あるいは新しく始めるなら、V2がお勧めでしょう）

Application Gatewayとはどのようにして動くのか?

念のため、Azure Application Gatewayは具体的にどのように動作するのかについて説明します。

上の画像のように、（Web）クライアント、たとえばWebサイトに接続したいユーザーとバックエンドサーバーの間に Azure Application Gatewayを配置することが可能です。 従来のロードバランサーはトランスポート層 (OSI レイヤー 4 – TCP および UDP) で動作し、ソース IP アドレスとポートに基づいてトラフィックを宛先 IP アドレスとポートにルーティングします。

Application Gateway は、URI パスやホスト ヘッダーなどの HTTP 要求の追加属性に基づいてルーティングを決定することができます。 たとえば、受信 URL に基づいてトラフィックをルーティングすることができます。 たとえば、受信URLに/imagesが含まれている場合、画像用に設定された特定のサーバーセット（プールと呼ばれる）にトラフィックをルーティングすることができます。 775>

このタイプのルーティングは、アプリケーション層 (OSI レイヤー 7) のロード バランシングとして知られています。 Azure Application Gateway は、URL ベースのルーティングなどを行うことができます。 アプリケーションが持つすべての機能について詳しく知りたい方は、こちらのサイト

Now introducingをご覧ください。 ARM テンプレート、Azure CLI、または Powershell を使用して、過去に Application Gateway をデプロイしたことがある人は、特に複数のリスナーやバックエンド HTTP 設定を定義したい場合、AGW のデプロイ プロセスが非常に面倒であることを知っていることでしょう。 個人的には、過去に15個のリスナーとそれに続くバックエンドの設定で構成された Application Gateway をデプロイしたことがありますが、すべて同じドメイン名で終わっていました。
www.contoso.com;
Contoso.com;
My.contoso.com;
Etc.

このような設定の問題点は、リスナーを作成し、それらをルールに関連付け、さらにバックエンドと HTTP 設定に関連付ける作業が非常に多く発生することでした。

しかし、2020 年 7 月 20 日以降、Microsoft は、マルチサイト リスナーでワイルドカード ホスト名を定義するオプションもサポートすると発表しました。 そして、リスナーごとに最大 5 つのユニークなホスト名を使用することができます。 素晴らしいことだと思いませんか。

では、それが具体的にどのように機能するのかを、以下の写真で説明します。

上の画像でわかるとおり、このアプリケーション ゲートウェイでは複数の「マルチサイト」リスナーが設定され ています。
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-??.com
これらのリスナーは、同じまたは異なるバックエンド プールにルーティングできます。
したがって、ホスト名のワイルドカード文字を使用して、1 つのリスナーに複数のホスト名を一致させることが可能です。 たとえば、*.contoso.com は ecom.contoso.com や b2b.contoso.com だけでなく customer1.b2b.contoso.com などと一致させることが可能です。 ホスト名の配列を使用して、リスナーに複数のホスト名を設定し、バックエンドプールに要求をルーティングすることができます。 たとえば、リスナーは contoso.com と fabrikam.com を含むことができ、両方のホスト名の要求を受け入れます。

ワイルドカード リスナーの注意点

ワイルドカード リスナーは現在まだプレビュー中なので、考慮すべき点と制限がいくつかあります：
1. この機能はプレビューであり、Application Gateway の Standard_v2 と WAF_v2 SKU でのみ利用可能です。

2. この機能は、現在 Azure PowerShell と Azure CLI のみで利用可能です。 ポータルのサポートは近日中に行われる予定です。 ポータルのサポートが完全ではないため、HostNames パラメータのみを使用している場合、ポータルではリスナーが Basic リスナーとして表示され、リスナー リスト ビューのホスト名列には設定されているホスト名が表示されないことに注意してください。 ワイルドカードリスナーの変更については、ポータルでサポートされるまで、必ず Azure PowerShell または CLI を使用するようにしてください。

3. ワイルドカードまたは複数のホスト名を使用するターゲットリスナーでリダイレクションルールを作成することはできません。

4. バックエンドのヘルスチェックでは、HTTP設定ごとに複数のカスタムプローブを関連付けることはできません。 代わりに、バックエンドのWebサイトの1つをプローブするか、バックエンドサーバーのローカルホストをプローブするために “127.0.0.1” を使用することができます。 ただし、リスナーでワイルドカードや複数のホスト名を使用している場合、ルールの種類（基本またはパスベース）に応じて、指定したすべてのドメインパターンに対する要求がバックエンドプールにルーティングされます。

5. 正規表現を使用してホスト名を言及することはできません。 アスタリスク（*）やクエスチョンマーク（？）などのワイルドカード文字のみを使用してホスト名パターンを形成することができます。

6. 同じリスナーに複数のホスト名が記載されている場合、記載されているホスト名に一致する CN を持つ SAN 証明書（サブジェクト代替名）をアップロードしなければなりません。

7. それが *.contoso.com のようにワイルドカードのホスト名の場合、 *.contoso.com のように CN のワイルドカード証明書をアップロードしなければなりません

もう理論はいい！？

前述したように、このブログを書いている時点では、Powershell か Azure CLI のどちらかを使用します。

私は、次のことを行う powershell サンプルを作成しました。 AGW を配置する適切な VNET とサブネットを見つけます。
2. AGW で使用するパブリック IP アドレスを作成します。
3. Gateway とフロントエンドの IP 構成を作成します。
4. バックエンドプールを作成します。 リスナーとルーティング ルールの作成
6. Web Application Firewall ポリシーの作成
7. TLS ポリシー設定の構成
8. アプリケーション ゲートウェイの作成 (この時点では HTTP のみ AGW)

AGW が正常に展開された後、スクリプトによりアプリケーション ゲートウェイに HTTPS を追加します：

9.アプリケーション ゲートウェイに HTTP を導入します。 AGWを検索し、変数
10に格納します。 SSL証明書（PFX + パスワードが必要）を追加し、変数
11に格納します。 HTTPSフロントエンドリスナーポートを追加し、変数
に格納する12. フロントエンドのIP設定を取得し、変数
13に格納します。 フロントエンドリスナー(HTTPS)を追加し、変数
14 に格納します。 backendpoolを取得し、変数
15に格納します。 バックエンドのHTTP設定を追加し、変数
16に格納します。 上記のすべてをルーティングルールで結びつけます
17。 手順 8 ～ 15 で作成したものすべてで Application Gateway を更新します。

パワーシェル スクリプト

パワーシェル スクリプトを実行する前に、いくつか行う必要があることがあります：

1. powershell を使用して Azure にログインします (login-azAccount)

2. 導入したいサブスクリプションを探します (get-azSubscription)

3. サブスクリプションを選択します (select-azsubscription -subscription “SUBSCRIPTIONNAME”)

4. 以下のことを確認し、AGWを導入できるVNETとサブネットはサブスクリプションで作成しましょう。 サブネットのサイズについては、/26サブネットを使用することが最小値として推奨されます。 VNETとサブネットを選択したリソースグループに展開した場合、次のパラメータに適切な情報を入力します。
– Virtual Network ResourceGroup name ($VnetRGName)
– Virtual Network Name ($VnetName)
– SubnetName ($SubnetName)

6. 残りの変数については、実際にあなた次第となります。 命名規則やタイムアウトの設定など、いろいろと絡んでくるかもしれませんので。 ここでは何もお勧めしません。 私のスクリプトは、単一のバックエンドといくつかのデフォルトの http 設定を持つ単一のワイルドカード リスナーに基づいていますが、お好みで自由に編集してください。 WAF & SSL/TLS 設定には特に注意を払っています。 このスクリプトは、WAF を有効にし、アプリケーション ゲートウェイが展開されるのと同じリソース グループに WAF ポリシーを作成します。 このWAFポリシーは、その後、AGWに関連付けられます。 SSL/TLS 設定については、最新の事前構成された (ベストプラクティス) ポリシー設定を有効にしています。

その結果はどうなるでしょうか。

Powershell スクリプトを実行すると、次のリソースを持つリソース グループが作成されます。

1. アプリケーション ゲートウェイ本体
2. アプリケーション ゲートウェイに関連付けられたパブリック IP アドレス
3. アプリケーション ゲートウェイに関連付けられたカスタム Web アプリケーション ファイアウォール ポリシー

この投稿が、希望する Wildcard Application Gateway の展開と設定に役立つことを願っています！

役立つリンク：
github にある Powershell スクリプト
Microsoft 文書

。