カテゴリー: Application Gateway

Azure Application Gatewayは、アプリケーション レイヤー (OSI レイヤー 7) で動作する、Web トラフィック ロード バランサーです。

https://docs.microsoft.com/ja-jp/azure/application-gateway/overview

Azure Front DoorでWEBアクセスの送信元IP制限

投稿日: 投稿者: tama-negi

 

Azure Front DoorのバックエンドプールにApplication Gatewayを使用した場合の送信元IPアクセス制限を試してみました。

Front Door経由のWEBアクセスはすべてAzureFrontDoor.BackendでプールされるIPになります。

その為Application GatewayやWeb Apps等のバックエンド側ではアクセス元IPがわからない為NSGでのアクセス制御が出来ません。Front Doorでのアクセス制御が必要になります。

今回実施した内容は以下の２つになります。

      • NSGでFront DoorからのApplication GatewayへのアクセスをFront Doorのみに制限する
      • Front DoorのWeb Application Firewallポリシーのカスタム規則でIP制限を行う

Azure Front Doorのアクセス制限はNSGの設定で出来ない為、Web Application Firewallポリシーのカスタム規則で実施しています。

WAFの構築についてはこちらで試しております。併せて見て頂ければと。

Azure Web アプリケーションファイアウォールを作ってみた

1.Application GatewayサブネットのNSGでFront Doorからのアクセスのみに制限する

最初にApplication GatewayへのアクセスをFront Doorからのみ制限します。

Application Gatewayのサブネットに適用しているNetwork Security Groupの受信規則でService TagがAzureFrontDoor.Backendの許可設定を追加します。

      • ソース：Service Tag
      • ソースサービスタグ：AzureFrontDoor.Backend
      • ソースポート範囲；*(Any)
      • 宛先：VirtualNetwork
      • 宛先ポート範囲：80、443
      • プロトコル：TCP
      • アクション：許可

次にFrontDoorからのアクセス許可より優先順位が下に、InterNetからのアクセス拒否ポリシーを設定します。

  • ソース：Service Tag
  • ソースサービスタグ：InterNet
  • ソースポート範囲；*(Any)
  • 宛先：VirtualNetwork
  • 宛先ポート範囲：80、443
  • プロトコル：TCP
  • アクション：拒否

この2つのルールにより、Application GatewayではInternetから来るWEBアクセスが拒否されFront Door経由のアクセスのみが許可されます。

Application Gatewayのドメインへのアクセスを実施すると、このサイトにアクセスできませんというメッセージが表示されます。

2.Web Application Firewallポリシーのカスタム規則でIP制限を行う

Front Door側でアクセス元IPを制限する場合、NSGではできず、WAFのカスタム規則を利用します。

今回は、特定のIPからのアクセスのみを許可します。

    • Web Application Firewallのポリシーを防止にする
    • 特定のIPを含まない場合はトラフィックを拒否する設定をする

※防止にすると必要なアクセスがブロックされる場合もありますので注意して下さい。

Web アプリケーション ファイアウォールのポリシーのメニューで設定の中にあるポリシー設定を選択すると下記画面が表示されます。

モードで防止を選択し保存します。

次に設定にあるカスタム規則を選択します。

カスタムルースの追加を選択すると条件設定の画面が表示されますので、以下の通り設定します。

      • 一致の種類：IPアドレス
      • 一致変数　RemoteAddr
      • 操作：次の値を含まない
      • IPアドレスまたは範囲：許可するIP
      • 結果　トラフィックを拒否する

最後にカスタム規則の保存を行えば、作業が完了です。

これで特定のIPからのみアクセスが許可され、それ以外のアクセスはブロックされます。

Azure MonitorでApplication Gateway正常性プローブを監視

投稿日: 投稿者: tama-negi

 

Application GatewayはL7のレイヤーでWEBアクセスを負荷分散してくれるAzure上のロードバランサーになります。

Application Gatewayの負荷分散先(バックエンド)にある、WEBサーバ(HTTP(S))が正常に応答していないと、WEBサイトがエラーになる等の事象になってしまいます。

その為、WEBサイトに障害が発生していた場合の切り分けの1つとして、Application GatewayからWEBサーバへの通信状況(正常性プローブ)の状態を監視する事は非常に重要になってきます。

今回は、Azure  Monitorの機能を利用してApplication Gatewayの正常性プローブのステータスの変化を検知するようにしてみました。

Application Gatewayの構築についてはこちらに記載しております。

Azure Application Gatewayを構築してみた

1.Application Gatewayのメトリックで正常なホストの数、異常なホストの数がわかる

Application Gatewayの正常性プローブの変化は、正常なホストの数、異常なホストの数の変化で分かります。

Application Gatewayのメトリックでは、この正常なホストの数、異常なホストの数を検知する事ができます。これはV1、V2どちらでも可能です。
このホストの数は、正常性プローブによって正常もしくは異常と判断されたバックエンドの数になります。

正常性プローブ自体は、バックエンドにあるWEBサーバへHTTP(S)のヘルスチェックで確認されます。

マイクロソフト様のサイトに記載があります。

https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-metrics#backend-metrics

マイクロソフト様のサイトを読むと、以下のような事が言えます。

      • 正常なホストの数が0の場合は、すべてのバックエンドプールに問題が発生しており、サイトが表示されない状態
      • 異常なホストの数が１以上の場合は、1つ以上のバックエンドプールで異常が発生している状態（特定のバックエンドにあるホストが停止している状態

したがって、正常なホストの数や異常なホストの数状態を監視することにより、Application Gatewayのバックエンド正常性状態がわかります。

2.Application GatewayでWEBサーバへのヘルスチェック状況をAzure Monitorで検知する(正常なホストの数が0になった場合)

Azure MonitorでApplication Gatewayのメトリックを監視することができます。

まず、モニター＞アラート＞新しいアラートルールを選択します。

そうすると、下記画面が表示されますので、リソースの選択でアプリケーションゲートウェイを選択します。

    選択が終わったら、完了を押します。

ルールの作成画面に戻りますので、次に条件の項目で追加を選択してください。

そうすると、下記のようにシグナルロジックの構成が表示されます。

ここに項目が表示されるのですが、今回対象とする項目は下記2つになります。

    • Unhealthy Host Count　が異常なホストの数になります
    • Healthy Host Count　が正常なホストの数になります

すべて正常性プローブがNGになった場合の検出は正常なホストの数で設定をします。

Healthy Host Countを選択をすると下記のような画面が表示されます。バックエンドのサーバが1つ（ルールもHTTP用1つ）で検証していますので、以下のように1となります。

これが、0になると、正常なバックエンドがなくなる為、すべてのアクセスが停止する状態になります。ですので以下のような設定とします。

    • しきい値：Static
    • 演算子：より小さい
    • 集計の種類：平均
    • しきい値（演算子の方）：１

１より小さいとなりますので、バックエンドにあるWEBサイトからのヘルスチェックがすべてNGだった場合（一時的な状態を含む）が検出される事になります。

評価基準は適時選択してください。最後に完了ボタンを選択します。

ルールの作成画面に戻りますので、アクショングループの選択、アラートの詳細を適時記入し、アラートルールの作成をクリックします。

これで、Azure　MonitorでApplication Gatewayのバックエンド正常性がすべてNGになった場合に、アラートを発生させることができます。

3.Application GatewayのバックエンドのWEBサーバに異常があった場合に検知する

Application GatewayのバックエンドにいるWEBサーバに異常があった場合(ヘルスチェックがNG)になった場合の検出は異常なホスト数で行います。

シグナルロジックの構成で、Unhealthy Host Countを選択します。

そうすると、下記画面が表示されます。

すべてのバックエンド正常性がOKなので、0になります。

これが0より大きい場合は、バックエンド正常性に問題が発生している事を示します。ですので、下記のように設定にします。

    • しきい値：Static
    • 演算子：より大きい
    • 集計の種類：平均
    • しきい値（演算子）：0

評価基準は適時選択し完了ボタンを選択します。

ルールの作成画面に戻りますので、同様に、アクショングループの選択、アラートの詳細を適時記入し、アラートルールの作成をクリックします。

Application GatewayのバックエンドにあるWebサーバが1つでもNGになっている場合に、Azure Monitorを使ってアラートを発生させることができます。

Azure Front Doorのバックエンド正常性監視については、こちらで試しております。

Azure Front Doorのバックエンド正常性監視

 

フロントドアとWAFのログをLog Analyticsで確認

投稿日: 投稿者: tama-negi

 

Azure Froot Door のアクセスログやWAFログを診断設定でLog Analyticsへ転送しクエリで確認してみました。

Azure Front Doorのログではアクセス先のURL等の情報だけではなくキャッシュのヒットなどの情報も分かります。

WAFのログではどのルールでブロックされたのか？なども分かります。例えばレート制限時にはアクセス制限状況も分かります。

その為、Azure Front Doorの使用状況を把握するのには、診断設定で取得出来るログは非常に重要なログになります。

今回実際に実施した作業内容は下記の通りになります。

      • Azure Front Dorrの診断設定
      • Log Analyticsでのログ検索

設定にあたっては、マイクロソフト様サイトを参考に進めました。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-diagnostics

WAFの作成についてはこちらを参考にして頂ければと。

Azure Web アプリケーションファイアウォールを作ってみた

Application Gatewayのログについてはこちらを参考にして頂ければと。

Azure Application GatewayのアクセスログをLog Analyticsで確認する

1.Azure Froot DoorやWAFのログ取得設定は診断設定で行います

Azure Froot DoorのアクセスログはApplication Gatewayと同様に診断設定を利用します。

Azure Front Doorのメニューで診断設定を選択します。

下記画面が表示されますので診断設定を追加するを選択します。

診断設定の画面が表示されます。

logに表示されている2項目にチェックを入れます。(必要に応じてMetricにもチェックを入れます。)

今回はLog Analyticsで確認するのでLog Analytics への送信にチェックを入れて、送信先のワークスペース名を選択します。

診断設定の名前を付けて保存します。

※FrontdoorWebApplicationFirewallLogはFroot DoorでWeb Application Firewallの設定を行っている場合のみ出力されます。

2.Log AnalyticsでAzure Front DoorやWAFログの検索を行う。

診断設定で選択したLog Analyticsのワークスペースでログを開きます。(Azure Front Doorのメニューでログを選択しても同じ動作になります。)

今回取得設定したのは以下の2つのログになります。

      • FrontdoorAccessLog：Azure Front Doorのアクセスログ
      • FrontdoorWebApplicationFirewallLog：WAFのログ

アクセスログを表示する為のサンプルは下記の通りになります。

#アクセスログを表示する

AzureDiagnostics
| where Category == “FrontdoorAccessLog”
 
#アクセスログをアクセス元のIPでカウントする。（アクセス数順で並び変える。）

AzureDiagnostics
| where Category == “FrontdoorAccessLog”
| summarize total_hits = count() by clientIp_s
| sort by total_hits desc
 

FrontdoorAccessLogの主な出力項目としてはこんな内容が表示されます。

      • 時刻
      • リクエストURL
      • User-Agent
      • アクセス元のIP
      • キャッシュヒット
      • ルールエンジン(利用時)

Web Application Firewallのログは下記のクエリで確認可能です。

#Web Application Firewallのログを表示する

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
 

アクセスログに表示される項目以外に、どのルールにマッチしたのか、ブロックされたのか等の情報が併せて表示されます。

なお許可された通信も表示されます。許可された通信以外(LogやBlock)を表示するには下記のようにします。

#Allow以外のアクセスログを表示する

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
| where action_s != “Allow”
 

Web Application FirewallでBlockされたログのみの場合は以下のようなクエリを利用します。

#Web Application FirewallでBlockされたアクセスログを表示する

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
| where action_s == “Block”
 

実行結果を確認するとどのルールでBlockされたのかもわかります。

3.Azure Froot Doorのバックエンドプール側のクライアントIPはFront DoorのIPになります。

Froot Doorを使う場合ですが、バックエンドプール側のアクセスログに表示されるclientIP_sがFroot DoorのBackend poolのIPアドレスになります。

その為、バックエンドプール側（Virtual Machine等）でアクセス元IPを確認する場合は、x-forwarded-forを確認する必要があります。

また、マイクロソフト様のサイトにも記載がありますが、Froot Doorからのヘルスチェックアクセスが結構な数のアクセスが来るので、アクセスログが大量になる事にも注意が必要です。

【参考】Web Application Firewallの作成は下記に記載しています。

 https://www.tama-negi.com/2020/05/10/azure-web-application-firewall/ ‎

Azure Application GatewayのARMテンプレートをPower Shell使ってエクスポートする

投稿日: 投稿者: tama-negi

 

Azure Application Gatewayの設定情報のダウンロードを試してみました。

Azure Application Gatewayは設定項目が多く、いろいろな所の設定変更していくと、どこを変更した分からなくなり、元に戻せてなくて設定がうまく行かないケースがありました。

Azure PortalでARMテンプレートをPower Shellでエクスポートをという事を試してみました。併せてGet-AzApplicationGatewayで設定情報を取得も実施してみました。

実施にあたっては以下のサイトを参考に進めました。

https://docs.microsoft.com/en-us/powershell/module/az.resources/export-azresourcegroup?view=azps-3.8.0
https://docs.microsoft.com/en-us/powershell/module/az.network/get-azapplicationgatewayhttplistener?view=azps-3.8.0

今回作成したものは　GitHub上に公開しています。

https://github.com/Tama-negi/Li-akb-branch-office/tree/PowerShell_Azure/ApllicationGateway-Template-Export-20200422

1.Azure Application Gatewayのテンプレートエクスポート＋情報取得

Get-AzApplicationGateway でApplication Gatewayの情報を取得しています。

また、Export-AzResourceGroupで、テンプレートのエクスポートを行います。Application Gateway名を指定することで、Application Gatewayのみのテンプレートをエクスポートします。

#Application Gateway Template Export

#取得するApplication Gatewayのパラメータ

$SubscriptionId = “サブスクリプションID”
$RG = “リソースグループ名”
$APGW = “Application Gateway名”
$TemplatePath =“テンプレートのパス（例：C:\temp）”

#Getコマンドで情報取得
Get-AzApplicationGateway -Name $APGW -ResourceGroupName $RG

#テンプレートをエクスポートする
Export-AzResourceGroup `
-ResourceGroupName $RG `
-Resource “/subscriptions/$SubscriptionId/resourceGroups/$RG/providers/Microsoft.Network/applicationGateways/$APGW”`
-Path $TemplatePath

なお、上記サンプルのように、Get-AzApplicationGatewayだけでそのまま情報を取得した場合、子に入っているSKUの情報等が取得出来ません。適時必要に応じて表示するようにして下さい。注意願います。

Azure Application Gatewayで特定のパスに来たアクセスを特定のVirtual Machineに振り分ける

投稿日: 投稿者: tama-negi

 

管理画面へのアクセス等、特定のパスへアクセスを特定のバックエンド（Virtual MachineやWeb Apps）へ振り分けたいという事があるかと思います。

今回は、Application Gatewayにパスベースのルール作成するを試してみました。

パスベースのルール規則作成で、設定が必要な内容は以下の2点になります。

　１）バックエンドプールを作成する。
　２）ルールにてパス ベースのルーティン規則を追加する。

今回は、Azure VM2台の冗長構成想定としています。

以下のようにadminというパスに来たアクセスはVM1に振り分ける。

http://www.xxxx.com/admin/

上記以外のアクセスは、2台(VM1、2)で受信するような構成を想定します。

Application Gateway自体の作成は下記記事に記載しておりますので併せて参照頂ければと。

Azure Application Gatewayを構築してみた

1 .Application Gatewayのバックエンドプールを追加する

パスベースのルールで使用するバックエンドプールを追加します。追加する内容は2つになります。

　１）VM1のみが存在するバックエンドプール(APGW-backend01)(特定のパスへのアクセスを受信するバックエンドプール)
　２）VM1、2が存在するバックエンドプール(APGW-backend02)(それ以外のアクセスを受信するバックエンドプール)

まず、特定のパスに来たアクセスを受信するバックエンドプール(APGW-backend01)を作成します。

アプリケーションゲートウェイでバックエンドプールを選択すると下記画面が表示されますので、追加をクリックします。

下記画面が表示されますので、転送先のVMを指定します。(今回の場合はVM1を指定)

同じくそれ以外のパスへ来たアクセスを受信するバックエンドプール(APGW-backend02)を作成します。下記の通りVM1,VM2を指定します。

下記のように2つのバックエンドプールが作成されます。

    • APGW-backend01が特定のパスに来たアクセスを受けるバックエンドプールになります。(対象サーバがVM1のみの1台になります。)
    • APGW-backend02がそれ以外のアクセスを受けるバックエンドプールになります。(対象サーバがVM1、VM2の2台になります。)

これでバックエンドプールの作成は終了です。

2 .Application Gatewayにパス ベースのルーティング規則を追加する

パスベースの規則作成ですが、Basicのルールからの変更はAzure Portalを利用しては出来ません。新規に作成する必要があります。

作成にあたっては、パスベース用のリスナー等を新規に作成する必要があります。

残念ながらデフォルト作成した状態では、リスナーやルールが1つしかない為削除できません。作成した後に後で削除する必要があります。

      • 既存リスナーの設定変更及び新規リスナーの作成
      • パスベースのルール作成
      • 既存リスナー、既存ルールの削除

※今回はお試しなのでこの手順で実施しています。停止を伴う為実際の環境で実施する場合は作業手順を検討して実施する事が必要になります。

１)まず既存リスナーのポート番号を変更します。これは同じポート番号でリスナーが作成できない為になります。今回は81を指定して保存しています。

２)新規にリスナーを追加します。今回はAPGW-Listener01という名前で追加しています。

設定が完了すると下記のような感じで2つリスナーができます。

３)次にルールの追加を行います。ルールを選択すると下記画面が表示されますので、要求ルーティングルールを選択します。

４)リスナーのタブでルール名を適時入力します。リスナーは先ほど作成したリスナーを選択します。

５)バックエンドターゲットのタブで、バックエンドターゲット、HTTP設定を選択します。パス ベースの規則を作成するには複数のターゲットを追加しますを選択します。

６)まず最初に/adminに来たアクセス用のルーティング規則を作成します。バックエンドプールにはVM1のみが含まれるバックエンドプールを指定します。

７)次にそれ以外に来たアクセス用のルーティング規則を作成します。バックエンドプールにはVM1、VM2が含まれるバックエンドプールを指定します。

作成が完了すると下記のように表示されています。

これで作成作業自体は完了です。

最後に、既存のルール削除、リスナーの削除を行えば作業完了です。(これを忘れないように注意が必要です。)

今回は基本的な設定を行いましたが、複数のパスを指定するような事も可能です。色々試してみたい所です。

※マイクロソフトサポート様に色々ご教授頂き、何とか設定できるようになりました。いつも本当に有難うございます。

Azure Application Gatewayのエラーページ設定更新

投稿日: 投稿者: tama-negi

 

Application Gatewayでシステムメンテナンス等でWEBサーバを全部停止した場合は、デフォルトの502エラーページが表示されます。

Application Gatewayのリスナーにカスタムのエラーページを設定する事でユーザー作成のエラーページを表示する事が出来ます。

WEBサイト等のシステムメンテナンスを案内する場合等には、リスナーにメンテナンス案内をエラーページを設定することで、Application Gatewayの機能でメンテナンス案内を表示が可能になります。

エラーページは、Blobストレージのパス等固定のURLを指定する事で設定できます。

最初にAzure Portal上でエラーページの設定を行いました。その次にカスタムエラーページのBlobストレージへのアップロード、Application Gateway側での設定更新をPower Shellでやってみました。

1 .Azure PortalでApplication Gatewayのエラーページ設定をしてみる

今回は以下の前提で試してみました。

      • エラーページはBlobストレージにアップしたHTMLファイルを利用する
      • エラー用のHTMLファイルは事前にアップロード済みである

まず、最初にBLOBストレージにアップロードしたエラーページのURLを確認します。

ストレージアカウントのStorage Explorerを選択すると下記画面が表示させますので、Blobコンテナのエラーファイルを置いたディレクトリに移動します。

ファイルを選択し右クリックしプルダウンでプロパティを選択します。

プロパティを選択すると下記画面が表示されますので、Uriの行がエラーページで指定する内容にあんります。Uriをコピーします

次にAzure Portal上Application Gatewayの設定を行います。

Application Gatewayのメニューで設定対象のApplication Gatewayを選択します。

Application Gatewayのメニューでリスナーを選択すると下記画面が表示されます。設定対象のリスナーを選択します。

リスナーの設定画面が表示されます。

エラーページのURLの項目ではいを選択します。

無効なゲートウェイ-502と禁止-403のエラーページが設定できます。先ほどストレージアカウントで確認したエラーページのUriを入力します。

これでAzure Portalを利用したエラーページの設定が完了です。

2 .Power Shellを使ってBlobストレージにファイルをアップロードする

次にPower Shellでのエラーページの更新を試してみます。実施する手順は2つになります。

      • エラーページのBlobストレージへのアップロード
      • Application Gatewayのエラーページパスを変更する。

まず、エラーページのHTMLファイルをBlobストレージを行います。

以下のページを参考に、HTMLファイルのBlobストレージアップロード用Power Shellを作ってみました。

https://docs.microsoft.com/en-us/powershell/module/az.storage/set-azstorageblobcontent?view=azps-3.3.0

※試してみた所、Content Typeを指定しないと、ファイルとしてアップロードはできますが、エラーページとして表示出来ませんでした。明示的にContent Typeを指定います。

※同じファイル名でアップロードしてもエラーページは更新されません。別名でのアップロードが必要です。

# Blobストレージにファイルをuploadする
# 参考URL
# https://docs.microsoft.com/ja-jp/azure/storage/blobs/storage-quickstart-blobs-powershell#upload-blobs-to-the-container

# パラメータ
$resourceGroupName = “ストレージアカウントのリソースグループ名”
$StorageAccountName = “ストレージアカウント名”
$containerName = “コンテナ名”
$LocalFilePath = “アップロードするファイルパス”

# 処理部分
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $StorageAccountName
$ctx = $storageAccount.Context

Set-AzStorageBlobContent -File $LocalFilePath `
-Container $containerName `
-Properties @{“ContentType” = “text/html”} `
-Context $ctx

3.Power Shellを使ってApplication Gatewayのエラーページを更新する

Application Gatewayのエラーページの更新は、エラーページのパスを変更する事で実現しています。Power Shell作成にあたっては以下のページを参考にしました。

https://docs.microsoft.com/ja-jp/powershell/module/az.network/set-azapplicationgatewayhttplistenercustomerror?view=azps-3.3.0&viewFallbackFrom=azps-2.4.0

# APGW Custom error Page Update
# 参考URL
# https://docs.microsoft.com/ja-jp/powershell/module/az.network/set-azapplicationgatewayhttplistenercustomerror?view=azps-3.3.0&viewFallbackFrom=azps-2.4.0

#パラメータ
$resourceGroupName = “Application GatewayのRG名”
$APGWName =“Application Gateway名”
$ListenerName = “リスナー名”
$StatusCode = “更新対象のエラーコード（ex;HttpStatus403)”
$customErrorUrl = “ErrorページのURL(ex;https://Blobストレージ名.blob.core.windows.net/コンテナ名/ファイル名)”

#処理部分
$AppGw = Get-AzApplicationGateway -Name $APGWName -ResourceGroupName $resourceGroupName
$httplistner = Get-AzApplicationGatewayHttpListener -Name $ListenerName -ApplicationGateway $Appgw
$updatelistener = Set-AzApplicationGatewayHttpListenerCustomError -HttpListener $httplistner -StatusCode $StatusCode -CustomErrorPageUrl $customErrorUrl
Set-AzApplicationGateway -ApplicationGateway $AppGw

※マイクロソフトサポート様に指摘/修正頂き完成しています。本当にありがとうございます。

4.留意点

Application Gatewayはエラーページをキャッシュで保持します。

キャッシュの更新は、エラーページのパス変更かApplication Gatewayの再起動でできます。

Application Gatewayの再起動の場合は同じファイル名でもエラーページのキャッシュ更新が可能ですが、Application Gateway再起動分の停止時間が発生します。

パスの変更の場合は設定変更の反映だけになる為停止時間が発生しません。

エラーページの更新は、事前にBlobストレージに別ファイル名でアップしておき、エラーページのパス名を切り替えるのが良さそうです。

Application  Gatewayの再起動については以下の記事に記載しております。

Power ShellでAzure Application Gatewayの起動停止

Power ShellでAzure Application Gatewayの起動停止

投稿日: 投稿者: tama-negi

 

Azure Application Gatewayの起動停止を試してみました。

Application Gatewayで403エラーページを更新した際に反映されないという事象があったのですが、Application Gatewayを停止、起動したら改善するんじゃない？という事で確認してみました。

Azure Portal上で確認してみた所Application Gatewayの再起動は出来ませんでした。

そこで調べてみた所、Power Shellで出来そうだったので試してみた所上手く行きました。

今回はPower Shellでの再起動手順を残しておきます。

1 .Azure Application Gatewayの停止、起動を行う

Application Gatewayの再起動はAzure Portalでは出来ない為、Power Shellを使って実施します。

      • 停止時：Stop-AzApplicationGateway 

      • 起動時：Start-AzApplicationGateway

#Application Gateway Restart PowerShell

# APGW Parameter

$ResourceGroupName = “Application Gatewayが所属するリソースグループ名”
$APGWName = “Application Gateway名”
 
$ag = Get-AzApplicationGateway -Name $APGWName -ResourceGroupName $ResourceGroupName

# APGW Stop

Stop-AzApplicationGateway -ApplicationGateway $ag

# APGW Start

Start-AzApplicationGateway -ApplicationGateway $ag

マイクロソフトサポート様から教えて頂いたコマンドになります。（有難うございました。）

2 .Azure Application Gateway再起動時の重要な注意点

注意点として再起動後のグローバルIPが変わる事があります。

V1の場合グローバルIPが動的であるため、Application Gateway再起動により、グローバルIPが変わります。３回ほど実施してみましたが、100％変わりました。

対応としてはDNS登録時は、グローバルIPのFQDNをCNAMEで登録する事になります。

これが推奨なので通常はそういう設定されているかと思いますが、自分はIPアドレスをAレコードで登録していた為、接続できなくなり少し焦りました。

もう1点の注意点として、Application Gatewayを停止しても、課金は停止しない事があります。この点も注意が必要です。

3 .Azure Application Gatewayのエラーページ更新について

今回、Application Gatewayの再起動でエラーページの更新をやったのですが、自分のやり方が間違ってました。

Application Gateway側にカスタムエラーページのキャッシュを持っており、これはカスタムエラーページのファイル名（もしくはパス）を変更して保存しない限り更新されないそうです。（公開情報にも記載がありました。）

Application Gatewayのエラーページの更新について、こちらにも記載しております。

Azure Application Gatewayのエラーページを更新するPower Shell

Azure Application GatewayのアクセスログをLog Analyticsで確認する

投稿日: 投稿者: tama-negi

 

今回はApplication GatewayのAccess LogをLog Analyticsで確認してみました。

Application GatewayのログをLog Analyticsに転送することにより、Log AnalyticsでAccess Logの内容を確認することが出来ました。

Log Analyticsへの転送設定はApplication Gatewayの診断設定で実施します。

今回は診断設定からLog Analyticsでのログ検索まで一連の流れを試してみました。

Application Gateway自体の作成はこちらに記載しております。

Azure Application Gatewayを構築してみた

Azure Front Doorでのログ確認も試してみました。併せて見て頂ければと。

フロントドアとWAFのログをLog Analyticsで確認

1.Application GatewayのAccess Logで確認できる内容

一般的なLogで取得されるような値は取得可能です。実際に以下の値を取得することができます。

項目名 実際に取得される値  
TimeGenerated 2019-07-14T10:36:57Z  
SourceSystem Azure  
clientIP_s 66.XX.XX.XX  
httpMethod_s GET  
requestUri_s /  
userAgent_s Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/75.0.3770.100+Safari/537.36  
httpStatus_d 200  
host_s www.xxxx-xxxx.com  

2.Application Gateway からLog AnalyticsへのLog転送設定方法

Application Gateway のAccess Log取得設定は診断設定にて実施します。

アプリケーションゲートウェイのメニューで診断設定を選択します。そうすると下記画面が表示されますので、診断設定を追加する選択します。

診断設定の画面が表示されますので診断設定の名前を入力します。

次に転送するログを選択します。ApplicationGatewayAccessLogがアクセスログに該当します。なお、ApplicationGatewayFirewallLogはWAF利用時のログになります。

転送先のLogAnalyticsワークスペースを選択します。

保存すれば設定は完了です。

3.Application GatewayのAccess LogをLog Analyticsで確認してみた

では実際のアクセスログを確認してみましょう。アプリケーションゲートウェイのメニューでログという項目をクリックします。そうしますと、診断設定で指定したLog Analyticsワークスペースが表示されます。クエリ入力欄に入力する事でログ検索ができます。

※なお、診断設定から実際のログ収集開始までは5分～10分程度かかります。上記画面は設定直後の為、ログが見つかりませんという表記になっております。

実際にAccess Logを検索するには、下記クエリで実施します。(検索時間はデフォルトでは24時間になります。)

AzureDiagnostics
| where Category == “ApplicationGatewayAccessLog”

4.Application GatewayのAccess Logをアクセス元IP単位で集計する。

Log Analyticsを利用していますので、色々な集計が可能です。例えば下記のようにする事でアクセス元IPで集計することが可能です。

AzureDiagnostics
| where Category == “ApplicationGatewayAccessLog”
| summarize total_hits = count() by clientIP_s

今回は基本的な設定のみですが、色々加工ができそうです。今後色々試してみたい所です。

 

Azure Application Gateway利用した時のApacheアクセスログについて

投稿日: 投稿者: tama-negi

 

Application Gatewayからバックエンド側への通信はローカルIPで実施されます。

バックエンドプールにあるWebサーバログのアクセス元IPが、Application GatewayのローカルIPになります。この点はAzure Load Balancer を使った場合等との違いになります。

実際にApacheのアクセスログを確認した時に、すべてApplication GatewayのIPが表示されていました。

接続元の実IPはX-Forwarded-Forに含まれているとの事で、実IPを確認する為にはX-Forwarded-Forから戻す必要があります。

今回はApacheのaccess.logにX-Forwarded-For(実IP)が表示されるようにしてみました。access.logのsyslog化も併せて実施してみました。

Application Gatewayの作成については下記記事を参考にして頂ければと。

Azure Application Gatewayを構築してみた

1.Application Gatewayを利用した場合のApacheアクセスログを確認する

Application Gateway利用した場合のバックエンド側にあるApacheのアクセスログを確認してみました。

Azure Load Balancer利用時は実IPが表示されますが、今回はアクセス元IPがApplication GatewayのIPになっている事が分かります。

192.168.X.4 – – [16/May/2019:09:54:00 +0900] “GET / HTTP/1.1” 200 17540 “-” “-“
192.168.X.5 – – [16/May/2019:09:54:02 +0900] “GET / HTTP/1.1” 200 17540 “-” “-“
192.168.X.4 – – [16/May/2019:09:54:13 +0900] “GET /favicon.ico HTTP/1.1” 200 – “http://www.XXX.com/” “Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36”
192.168.X.4 – – [16/May/2019:09:54:30 +0900] “GET / HTTP/1.1” 200 17540 “-” “-“
192.168.X.5 – – [16/May/2019:09:54:32 +0900] “GET / HTTP/1.1” 200 17540 “-” “-“

実IP確認の為には、X-Forwarded-Forの値をアクセスログに表示させる必要がある事が分かります。

2.X-Forwarded-Forを表示するようにApacheを設定変更する

Apacheの設定変更は、httpd.confで行います。今回は以下の2点を実施しています。

    • httpd.confのLog Formatの変更(X-Forwarded-Forを表示させる)
    • CustomLog、ErrorLogのsyslog化(サンプルはLocal6を指定(環境に合わせて設定))

[root@test-vm ~]#cp -p /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.`date “+%Y%m%d”`
[root@test-vm ~]#vi  /etc/httpd/conf/httpd.conf

#変更前

ErrorLog “logs/error_log”
LogFormat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” combined
CustomLog “logs/access_log”

#変更後

  LogFormat “%{X-Forwarded-For}i \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”” combined
CustomLog “|/usr/bin/logger -p local6.info -t httpd_access” combined
ErrorLog “|/usr/bin/logger -p local6.info -t httpd_error”

※access log、error log両方local6に出力する設定です。
※Logに出力される日時は、syslog側で付与するので、LogFormatから削除しています。

3.rsyslogファイル作成

rsyslog側の設定を行います。

ApacheのLog出力先にlocal6を指定したので、rsyslog側でLocal6のファイル出力先を指定します。そのままだとmessagesにも出てしまうので除外指定も行います。

#新規にファイルを作成し、下記を追加する。

[root@test-vm ~]#vi /etc/rsyslog.d/httpd.conf

local6.* /var/log/httpd/access.log

#このままだと、messagesにも表示されてしまうので、rsyslog.confも編集する。

[root@test-vm ~]#cp -p /etc/rsyslog.conf /etc/rsyslog.conf.`date “+%Y%m%d”`

[root@test-vm ~]#vi /etc/rsyslog.conf

#変更前
*.info;mail.none;authpriv.none;cron.none; /var/log/messages

#変更後
*.info;mail.none;authpriv.none;cron.none;local6.none var/log/messages

4.Application Gatewayの正常性プローブアクセスをログから除外する

Application Gatewayはバックエンドの正常性を確認する為、バックエンド側のWEBサーバへ正常性プローブのアクセスを行います。

そのままだとこのアクセスがApacheのアクセスログに表示されてしまいLogが見にくくなります。

今回は正常性プローブのアクセスを、rsyslogでignoreを使って除外設定を行います。

#新規にファイルを作成し、下記を追加する。

[root@test-vm ~]#vi /etc/rsyslog.d/httpd-logstop.conf

msg, contains, “GET / HTTP/1.1” stop

#※除外の文字列は今回のLogFormatに合わせてます。

5.logrotate.dの設定を行う

今回はrsyslog化の設定と併せて、Apacheのaccess.logのログローテの設定を行ってみました。設定後、rsyslogおよびhttpdの再起動を行います。なお設定は環境に合わせて適時変更して下さい。

[root@test-vm ~]#cp -p /etc/logrotate.d/httpd /etc/logrotate.d/httpd.`date”+%Y%m%d”`
[root@test-vm ~]#vi  /etc/httpd/conf/httpd.conf

#設定ファイルの中身を下記記載に置き換えます。

/var/log/httpd/access.log {
　daily
　rotate 32
　nocompress
　ifempty
　missingok
　create
　sharedscripts
　postrotate
　　/sbin/service httpd graceful > /dev/null 2>/dev/null || true
　endscript
}

#今回は32日保管で、ローテ後圧縮にしています。

[root@test-vm ~]#systemctl restart httpd

[root@test-vm ~]#systemctl restart rsyslog

6.出力されたApacheのアクセスログを確認する

設定が完了後のログを確認してみました。

/var/log/httpd/access.logに、アクセス元のIPが表示されている事が確認できました。

May 27 15:49:39 webサーバ名 httpd_access: XXX.XXX.XXX.XXX:XXX “GET /favicon.ico HTTP/1.1” 200 – “http://www.XXX.com/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36”

今回はCentOS7で実施しています。Apacheのバージョン等により設定が異なると思いますので、適時環境に合わせて修正して頂ければと。

Azure Application Gatewayを構築してみた

投稿日: 投稿者: tama-negi

 

Azure Portalを利用してApplication Gateway(V1) の構築を実施してみました。

主な作成手順は下記の通りになります。

    1. Application Gateway用のSubnetのNSG設定
    2. Application Gateway用のSubnet作成
    3. Application Gateway作成(パブリックIPの作成も同時に行います)
    4. (任意)Application Gateway追加設定(正常性プローブ設定)

なお今回は、インターネット等の外部ネットワークからHTTPを受信するという一番基本的な構成を想定し作成しています。

※本記事は2020年7月12日に更新した内容になります。

1.Application Gateway用のNSGを作成する

Application Gateway用のサブネットに適用するNSGを作成します。

１)ネットワークセキュリティグループの画面で追加を選択します。

２)ネットワークセキュリティグループの作成画面が表示されますので、名前を入力し、リソースグループや地域(ロケーション)を選択します。確認および作成をクリックすると確認画面が表示されますので、そのまま作成を行います。

３)デプロイが完了したら下記画面が表示されますので、リソースの移動をクリックします。

４)ネットワークセキュリティの画面で受信規則を選択します。下記画面が表されますので、追加をクリックします。

５)受信規則の設定を行います。（今回は特定のIPからの許可のみの設定を前提としています。）

ルール１

    • 優先順位：100
    • 宛先ポート： 65503-65534
    • プロトコル：Any(or TCP)
    • ソース：Any
    • 宛先：Any
    • アクション：許可

ルール２

    • 優先順位：101
    • 宛先ポート：*
    • プロトコル：TCP
    • ソース： AzureLoadBalancer  (Service Tag)
    • 宛先：Any
    • アクション：許可

ルール３

    • 優先順位：102
    • 宛先ポート：80,443
    • プロトコル：TCP
    • ソース： 接続許可するIPアドレス　 (IPアドレス)
    • 宛先：Any
    • アクション：許可

ルール４

    • 優先順位：104
    • 宛先ポート：*
    • プロトコル：*
    • ソース： InterNet(Service Tag)
    • 宛先：Any
    • アクション：拒否

実際に設定が完了すると、下記のようになります。APGW01のプロトコルはAnyで作成との記載があったりもしますのでAnyで作成すべきかと思われます。

※なお、送信規則は、InterNetへのアクセスが許可されている必要があります。別途停止させている場合は、送信許可設定を追加します。

これでNSGの設定は完了です。

2.Application Gateway用のサブネットを作成する

Application Gateway用のサブネットを作成します。Application GatewayのサブネットにはAzure VM等は設置できません。個別で専用に作成する必要があります。

１)仮想ネットワークの画面でサブネットを選択します。以下の画面が表示されますので、サブネットを追加します。

２)サブネットの追加を行います。名前やアドレス範囲(/27以上)のサブネット適時入力します。ネットワークセキュリティグループには先ほど作成したNSGを指定します。

これで、サブネットの追加作業は完了です。

3.Application Gatewayを作成する

事前準備が完了したので、Application Gatewayを作成します。なお今回は試験用なので最小規模で作成しています。インスタンス数は2以上が推奨なので実際の利用時は注意して下さい。

以前はバラバラの作成だったのですが、2020年7月12日現在では一元的に作成するようになっています。

作成は以下の通りの流れで進みます。

      • 基本情報の設定
      • フロントエンドの作成(パブリックIPの作成も行います)
      • バックエンドプールの作成
      • ルーティング規則の作成

ルーティング規則の作成では、以下の内容を作成します。

      • リスナーの作成
      • HTTP設定の作成

１)Azure Portalでアプリケーション ゲートウェイのメニューを開きます。追加をクリックします。

２)アプリケーション ゲートウェイの作成画面が表示されますので、設定を進めていきます。

今回、設定値は下記の通り指定います。環境に合わせて適時修正頂ければと思います。

設定項目 設定値 備考
名前 APGW 適時命名してください。
レベル Standard  
インスタンス数 １  
SKUサイズ Ｓ  
リソースグループ 適時環境に合わせて選択します  
場所 適時環境に合わせて選択します  
仮想ネットワーク Application Gateway用のサブネットがある仮想ネットワークを指定  
サブネット Application Gateway用のサブネットを指定  

３)次はフロントエンドの設定になります。今回は外部公開用を想定する為、パブリックIPも新規作成します。パブリックIPアドレスの新規追加をクリックし追加します。

４)次にバックエンドプールの作成になります。下記画面が表示されますので、バックエンドプールの追加をクリックします。

下記画面が表示されますので、バックエンドプールを追加します。ターゲットはhttpを受信するWebサーバ(Azure VMやWeb Apps等)を適時選択します。(Webを受信する環境が無い場合は、ターゲットを持たないバックエンドプールを追加しますの項目で”はい”を選択します。)

５)構成画面が表示されます。ルーティング規則の追加をクリックし設定を行っていきます。

６)ルーティング規則の作成で、まずリスナーの設定を行います。ルール名やリスナー名を適時入力します。またフロントエンドIPでパブリックを選択します。

７)バックエンドターゲット側の設定を行います。バックエンドターゲットは作成したバックエンドを指定します。HTTP設定は新規追加をクリックします。

HTTP設定の追加ではHTTP設定名を入力します。今回はその他の項目は設定は変更しません。

設定作業が完了したら、追加をクリックします。

８)タグの画面が表示されますので、環境に合わせて適時設定します。(必要が無ければ、何も入力しなくてもOKです。)

９)確認画面が表示されますので、問題なければ作成をクリックし作成します。これで作成作業は完了です。

4.Application　Gatewayの追加設定

正常性プローブの設定は必須ではありませんがこっちも設定してみます。正常性プローブはバックエンドプールの正常性を確認するものです。

デフォルトは/へのアクセスで確認になります。詳細は下記サイトをご確認してください。

https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-probe-overview#default-health-probe-settings

１)作成したアプリケーションゲートウェイの画面で、正常性プローブを選択します。下記画面が表示されますので、追加をクリックします。

２)名前を入力します。またホスト部分ですがマルチサイトでない場合は127.0.0.1を指定します。パスはURLのパスを適時指定します。下記画面はhttp://ドメイン/index.htmlを正常性プローブとして指定しています。設定が終わったら保存をクリックします。

３)作成した正常性プローブをHTTP設定と関連付けします。関連付けを行うHTTP設定を行うと下記のように追加の画面が表示されますので、カスタムプローブの使用を”はい”を選択、カスタムプローブに先ほど作成した正常性プローブを選択します。最後に更新すれば作業完了です。

Azure Monitorを利用したバックエンド正常性監視については下記記事に記載しております。

Azure Monitorを使ってAzure Application Gateway正常性プローブのステータス変化を検知する

パスベースのルールの作成については下記記事に記載しております。

Azure Application Gatewayで特定のパスに来たアクセスを特定のVirtual Machineに振り分ける

－－－－－－－－