Application Gateway のバックエンドの正常性に関する問題のトラブルシューティング

[アーティクル]
03/08/2024

概要

既定では、Azure Application Gateway は、バックエンドサーバーに対して probe を実行して、その正常性状態を確認すると共に、バックエンドサーバーが要求を処理する準備ができているかどうかを確認します。ユーザーは、カスタム probe を作成して、ホスト名、probe の対象となるパス、および正常として受け入れられる状態コードを指定することもできます。どちらのケースでも、バックエンドサーバーが正常に応答しない場合、Application Gateway はそのサーバーを "異常" とマークし、サーバーへの要求の転送を停止します。サーバーが正常に応答し始めると、Application Gateway は要求の転送を再開します。

バックエンドの正常性を確認する方法

バックエンドプールの正常性を確認するには、Azure portal の [バックエンド正常性] ページを使用できます。また、Azure PowerShell、CLI、または REST API を使用することもできます。

これらのいずれかの方法で取得される状態は、次のいずれかになります。

Healthy
異常
Unknown

バックエンドプールのサーバーが正常な状態の場合、Application Gateway はそれに要求を転送します。バックエンドプール内のすべてのサーバーが異常または不明な場合は、クライアントでバックエンドアプリケーションへのアクセスに関する問題が発生する可能性があります。以降では、バックエンド正常性によって報告されるさまざまなメッセージ、その原因、および解決策について詳しく説明します。

Note

バックエンドの正常性状態を表示するアクセス許可をユーザーが持っていない場合、No results. が表示されます。

バックエンドの正常性状態: 異常

バックエンドの正常性状態が異常の場合、ポータルの表示は次のスクリーンショットのようになります。

Azure PowerShell、CLI、または Azure REST API のクエリを使っている場合は、次の例のような応答を受け取ります。

PS C:\Users\testuser\> Get-AzApplicationGatewayBackendHealth -Name "appgw1" -ResourceGroupName "rgOne"
BackendAddressPools :
{Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
                              "BackendAddressPool": {
                                "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appgw1/b
                          ackendAddressPools/appGatewayBackendPool"
                              },
                              "BackendHttpSettingsCollection": [
                                {
                                  "BackendHttpSettings": {
                                    "TrustedRootCertificates": [],
                                    "Id": "/subscriptions/536d30b8-665b-40fc-bd7e-68c65f816365/resourceGroups/rgOne/providers/Microsoft.Network/applicationGateways/appg
                          w1/backendHttpSettingsCollection/appGatewayBackendHttpSettings"
                                  },
                                  "Servers": [
                                    {
                                      "Address": "10.0.0.5",
                                      "Health": "Healthy"
                                    },
                                    {
                                      "Address": "10.0.0.6",
                                      "Health": "Unhealthy"
                                    }
                                  ]
                                }
                              ]
                            }
                        ]

バックエンドプール内のすべてのサーバーについて、バックエンドサーバーの状態として "異常" が返される場合、要求はサーバーに転送されず、Application Gateway は 502 "ゲートウェイが不適切です" というエラーを要求元のクライアントに返します。この問題のトラブルシューティングを行うには、[バックエンド正常性] タブの [詳細] 列を確認します。

[詳細] 列に表示されるメッセージは問題に関する詳細な分析情報を示すため、それらの詳細に基づいて、問題のトラブルシューティングを開始できます。

Note

既定のプローブ要求は、<プロトコル>://127.0.0.1:<ポート> の形式で送信されます。たとえば、ポート80 における HTTP probe の場合は http://127.0.0.1:80 になります。 HTTP 状態コード 200 から 399 のみが正常と見なされます。プロトコルと宛先ポートは、HTTP 設定から継承されます。 Application Gateway で別のプロトコル、ホスト名、またはパスに対して probe を実行し、他の状態コードを正常として認識させるには、カスタム probe を構成し、それを HTTP 設定に関連付けます。

エラーメッセージ

バックエンドサーバーのタイムアウト

メッセージ: Time taken by the backend to respond to application gateway's health probe is more than the timeout threshold in the probe setting. (バックエンドがアプリケーションゲートウェイの正常性 probe に応答するのにかかる時間が、probe 設定のタイムアウトしきい値を超えています。)

原因: Application Gateway は、HTTP(S) probe 要求をバックエンドサーバーに送信した後、構成された期間にわたってバックエンドサーバーからの応答を待ちます。バックエンドサーバーが、構成された期間 (タイムアウト値) 内に応答しない場合は、構成されたタイムアウト期間内に応答が再開されるまで、"異常" とマークされます。

解決策: 構成されたタイムアウト期間内にバックエンドサーバーまたはアプリケーションが応答しない理由を確認し、アプリケーションの依存関係も確認します。たとえば、応答の遅延を引き起こす可能性がある問題がデータベースにあるかどうかを確認します。アプリケーションの動作を把握したうえでアプリケーションがタイムアウト値の経過後にのみ応答するようにする必要がある場合は、カスタム probe 設定でタイムアウト値を引き上げます。タイムアウト値を変更するには、カスタム probe が必要です。カスタム probe を構成する方法については、こちらのドキュメントのページを参照してください。

タイムアウト値を引き上げるには、次の手順に従います。

バックエンドサーバーに直接アクセスし、そのページでサーバーが応答するまでにかかった時間を確認します。開発者ツールを使用するブラウザーなど、任意のツールを使用してバックエンドサーバーにアクセスできます。
アプリケーションが応答するまでの時間を把握したら、[正常性プローブ] タブを選んでから、対象の HTTP 設定に関連付けられているプローブを選びます。
アプリケーションの応答時間を超える任意のタイムアウト値を秒単位で入力します。
カスタム probe 設定を保存し、バックエンドの正常性が [正常] と表示されるかどうかを確認します。

DNS の解決エラー

メッセージ: Application Gateway could not create a probe for this backend. (Application Gateway でこのバックエンドに対するプローブを作成できませんでした。) This usually happens when the FQDN of the backend has not been entered correctly. (これは、通常、バックエンドの FQDN が正しく入力されていない場合に発生します。)

原因: バックエンドプールの種類が IP アドレス、FQDN (完全修飾ドメイン名)、または App Service の場合、Application Gateway は DNS を通して入力された FQDN の IP アドレスに解決します (カスタムまたは Azure の既定値)。その後、アプリケーションゲートウェイは、HTTP の設定で指定されている TCP ポートでサーバーへの接続を試みます。ただし、このメッセージが表示された場合は、Application Gateway が入力された FQDN の IP アドレスを正常に解決できなかったことを示しています。

解決策:

バックエンドプールに入力された FQDN が正しいことと、それがパブリックドメインであることを確認し、ローカルコンピューターから解決を試みます。
IP アドレスを解決できる場合は、仮想ネットワークの DNS 構成に問題がある可能性があります。
仮想ネットワークがカスタム DNS サーバーで構成されているかどうかを確認してください。そのようになっている場合は、DNS サーバーが指定された FQDN の IP アドレスに解決されない理由を確認します。
Azure の既定の DNS を使用している場合は、適切な A レコードまたは CNAME レコードマッピングが完了しているかどうかをドメイン名レジストラーで確認します。
ドメインがプライベートまたは内部の場合は、同じ仮想ネットワーク内の VM から解決を試みます。解決できる場合は、Application Gateway を再起動して、もう一度確認してください。 Application Gateway を再起動するには、次のリンク先のリソースで説明されている PowerShell コマンドを使用して、停止および起動する必要があります。

TCP 接続エラー

メッセージ: Application Gateway could not connect to the backend. (Application Gateway がバックエンドに接続できませんでした。) Check that the backend responds on the port used for the probe. (バックエンドがプローブに使用されるポートで応答することを確認してください。) Also check whether any NSG/UDR/Firewall is blocking access to the Ip and port of this backend. (また、NSG、UDR、またはファイアウォールによってこのバックエンドの IP とポートへのアクセスがブロックされているかどうかも確認してください。)

原因: DNS 解決フェーズの後、Application Gateway は、HTTP 設定で構成されている TCP ポートでバックエンドサーバーへの接続を試行します。 Application Gateway が指定されたポートで TCP セッションを確立できない場合、probe はこのメッセージで "異常" とマークされます。

解決策: このエラーが発生した場合は、次のステップを実行します。

ブラウザーまたは PowerShell を使用して、HTTP 設定に指定されているポートでバックエンドサーバーに接続できるかどうかを確認します。たとえば、Test-NetConnection -ComputerName www.bing.com -Port 443 コマンドを実行します。
指定されているポートが目的のポートではない場合は、Application Gateway がバックエンドサーバーに接続するための適切なポート番号を入力します。
そのポート経由でローカルコンピューターからも接続できない場合は、次のようにします。

a. バックエンドサーバーのネットワークアダプターとサブネットのネットワークセキュリティグループ (NSG) 設定を調べて、構成されているポートへのインバウンド接続が許可されているかどうかを確認します。許可されていない場合は、接続を許可する新しい規則を作成します。 NSG 規則の作成方法については、こちらのドキュメントページを参照してください。

b. Application Gateway サブネットの NSG 設定で、接続を確立できるようにパブリックおよびプライベートのアウトバウンドトラフィックが許可されているかどうかを確認します。 NSG 規則を作成する方法の詳細については、手順 3a に示されているドキュメントのページを参照してください。
```
        $vnet = Get-AzVirtualNetwork -Name "vnetName" -ResourceGroupName "rgName"
        Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
```
c. Application Gateway およびバックエンドサーバーのサブネットのユーザー定義ルート (UDR) 設定でルーティングの異常の有無を確認します。 UDR によってトラフィックがバックエンドサブネットの外へ送信される設定になっていないことを確認します。たとえば、ネットワーク仮想アプライアンスへのルートや、Azure ExpressRoute および VPN 経由で Application Gateway サブネットにアドバタイズされる既定のルートを確認します。

d. ネットワークアダプターの有効なルートと規則を確認するために、次の PowerShell コマンドを使用できます。
```
        Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
        Get-AzEffectiveRouteTable -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
```
NSG または UDR で問題が見つからない場合は、構成されているポートでクライアントが TCP セッションを確立するのを妨げるようなアプリケーション関連の問題がないかどうかを、バックエンドサーバーで確認します。いくつかの確認事項を次に示します。

a. コマンドプロンプトを開き (Win + R キー -> 「cmd」と入力)、「netstat」と入力して、Enter キーを押します。

b. 構成されているポートでサーバーがリッスンしているかどうかを確認します。次に例を示します。
```
        Proto Local Address Foreign Address State PID
        TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
```
c. 構成されているポートでリッスンしていない場合は、Web サーバーの設定を確認します。たとえば、IIS のサイトバインド、NGINX のサーバーブロック、Apache の仮想ホストなどです。

d. OS のファイアウォール設定を調べて、ポートへの受信トラフィックが許可されていることを確認します。

HTTP 状態コードの不一致

メッセージ: Status code of the backend's HTTP response did not match the probe setting. (バックエンドの HTTP 応答の状態コードが probe 設定と一致しませんでした。) Expected:{HTTPStatusCode0} Received:{HTTPStatusCode1}. (必要: {HTTPStatusCode0} 受信: {HTTPStatusCode1}。)

原因:TCP 接続が確立され、TLS ハンドシェイクが完了すると (TLS が有効な場合)、Application Gateway は probe を HTTP GET 要求としてバックエンドサーバーに送信します。前に説明したように、既定のプローブの対象は <protocol>://127.0.0.1:<port>/ であり、200 から 399 の範囲の応答状態コードが正常と見なされます。サーバーがそれ以外の状態コードを返した場合、それはこのメッセージで "異常" とマークされます。

解決策: バックエンドサーバーの応答コードに応じて、次のステップを実行できます。一般的な状態コードをいくつか次に示します。

Error	アクション
プローブ状態コードの不一致: 401 を受信	バックエンドサーバーで認証が必要かどうかを確認します。 Application Gateway の probe では、認証用の資格情報を渡すことはできません。 probe 状態コードの照合で "HTTP 401" を許可するか、サーバーが認証を必要としないパスに対して probe を実行します。
プローブ状態コードの不一致: 403 を受信	アクセスは禁止されています。バックエンドサーバーでパスへのアクセスが許可されているかどうかを確認します。
プローブ状態コードの不一致: 404 を受信	ページが見つかりません。バックエンドサーバーでホスト名のパスにアクセスできるかどうかを確認します。ホスト名またはパスパラメーターをアクセス可能な値に変更します。
プローブ状態コードの不一致: 405 を受信	Application Gateway の probe 要求で HTTP GET メソッドが使用されています。対象のサーバーでこのメソッドが許可されているかどうかを確認します。
プローブ状態コードの不一致: 500 を受信	内部サーバーエラー。バックエンドサーバーの正常性と、サービスが実行されているかどうかを確認します。
プローブ状態コードの不一致: 503 を受信	サービス利用不可。バックエンドサーバーの正常性と、サービスが実行されているかどうかを確認します。

または、応答が正当なものであると判断したうえで、Application Gateway が他の状態コードを正常として受け入れるようにする場合は、カスタム probe を作成できます。この方法は、バックエンド Web サイトで認証が必要な場合に役立ちます。プローブ要求にユーザーの資格情報が含まれないために要求が失敗し、バックエンドサーバーから HTTP 401 状態コードが返されます。

カスタム probe を作成するには、こちらの手順に従います。

HTTP 応答本文の不一致

メッセージ: バックエンドの HTTP 応答の本文がプローブ設定と一致しませんでした。 Received response body does not contain {string}. (受信した応答本文に {string} が含まれていません。)

原因: カスタムプローブを作成するときに、応答本文の文字列と一致させることによってバックエンドサーバーを正常とマークできます。たとえば、一致する文字列として "unauthorized" を受け入れるように Application Gateway を構成できます。プローブ要求に対するバックエンドサーバーの応答に文字列 unauthorized が含まれている場合、それは "正常" とマークされます。それ以外の場合は、示されたメッセージで "異常" とマークされます。

解決策: この問題を解決するには、次のステップに従ってください。

バックエンドサーバーにローカルでアクセスするか、probe パス上のクライアントマシンからアクセスして、応答本文を確認します。
Application Gateway のカスタム probe 構成で、応答本文が構成内容と一致するかどうかを確認します。
それらが一致しない場合は、受け入れる正しい文字列値を持つように probe 構成を変更します。

Application Gateway の probe の一致の詳細を確認します。

Note

すべての TLS 関連のエラーメッセージについて、SNI の動作と、v1 と v2 の SKU 間の違いを確認するには、「TLS の概要」ページを参照してください。

共通名 (CN) が一致しません

メッセージ: (V2 の場合) バックエンドサーバーによって提示されるリーフ証明書の共通名が、アプリケーションゲートウェイのプローブまたはバックエンド設定のホスト名と一致しません。
(V1 の場合) バックエンド証明書の共通名 (CN) が一致しません。

原因: (V2 の場合) これは、バックエンド設定で HTTPS プロトコルを選び、かつカスタムプローブとバックエンド設定のホスト名 (その順番で) がバックエンドサーバー証明書の共通名 (CN) と一致しない場合に発生します。
(V1 の場合) バックエンドプールターゲットの FQDN が、バックエンドサーバーの証明書の共通名 (CN) と一致しません。

解決策: ホスト名情報は、その値が TLS ハンドシェイク中に Server Name Indication (SNI) の設定で使用されるため、バックエンド HTTPS 接続では重要です。この問題は、ゲートウェイの構成に応じて次のいずれかの方法で修正できます。

V2 の場合、

既定のプローブを使用している場合 – アプリケーションゲートウェイの関連付けられているバックエンド設定でホスト名を指定できます。 [バックエンド設定] で [特定のホスト名でオーバーライドする] または [バックエンドターゲットからホスト名を選択する] を選択できます。
カスタムプローブを使用している場合 - カスタムプローブの場合、[ホスト] フィールドを使用して、バックエンドサーバーの証明書の共通名を指定できます。または、[バックエンド設定] で既に同じホスト名が構成されている場合、プローブ設定で [バックエンド設定からホスト名を選択する] を選択できます。

V1 の場合、バックエンドプールターゲットの FQDN が共通名 (CN) と同じであることを確認します。

ヒント: バックエンドサーバーの証明書の共通名 (CN) を確認するには、次のいずれかの方法を使用できます。また、RFC 6125 に従って、SAN が存在する場合は、SNI の検証はそのフィールドに対してのみ行われることに注意してください。証明書に SAN がない場合は、共通名フィールドが照合されます。

ブラウザーまたは任意のクライアントを使用する: バックエンドサーバーに直接 (App Gateway を介さずに) アクセスし、アドレスバーの証明書南京錠をクリックして証明書の詳細を表示します。 [発行先] セクションに共通名が表示されます。
バックエンドサーバーにログインする (Windows):
1. 対象のアプリケーションがホストされているマシンにサインインします。
2. Win + R キーを押すか、[スタート] を右クリックして [実行] を選択します。
3. 「certlm.msc」と入力し、Enter キーを押します。 [スタート] メニューで証明書マネージャーを検索することもできます。
4. 証明書を見つけ (通常は、証明書 - ローカルコンピューター\個人\証明書内にあります)、証明書を開きます。
5. [詳細] タブで、証明書の [サブジェクト] を確認します。
バックエンドサーバーにログインする (Linux): 適切な証明書ファイル名を指定して、OpenSSL コマンド openssl x509 -in certificate.crt -subject -noout を実行します

バックエンドの有効期限が切れています

メッセージ: Backend certificate is invalid. (バックエンド証明書が無効です。) 現在の日付が、証明書の "有効期間開始日" と "有効期間終了日" の範囲内ではありません。

原因: 期限切れの証明書は安全でないと見なされるため、アプリケーションゲートウェイはバックエンドサーバーに期限切れの証明書を異常としてマークします。

解決策: 解決策は、バックエンドサーバーの証明書チェーンのどの部分が期限切れであるかによって異なります。

V2 SKU の場合、

リーフ (ドメインまたはサーバーとも呼ばれます) 証明書の期限切れ - 証明書プロバイダーでサーバー証明書を更新し、新しい証明書をバックエンドサーバーにインストールします。 Leaf (topmost) > Intermediate(s) > Root で構成される完全な証明書チェーンがインストールされていることを確認します。証明機関 (CA) の種類によっては、お使いのゲートウェイに対して次のアクションを実行する必要があります。
- 一般に知られている CA: 証明書の発行者が既知の CA である場合は、アプリケーションゲートウェイに対して何も行う必要はありません。
- プライベート CA: リーフ証明書がプライベート CA によって発行された場合は、署名ルート CA 証明書が変更されたかどうかを確認する必要があります。このような場合、お使いのゲートウェイの関連付けられたバックエンド設定に新しいルート CA 証明書 (.CER) をアップロードする必要があります。
中間証明書またはルート証明書の期限切れ – 通常、これらの証明書の有効期間は比較的長くなっています (10 から 20 年)。ルートまたは中間証明書の有効期限が切れた場合、更新された証明書ファイルについて証明書プロバイダーに確認することをお勧めします。バックエンドサーバーに、Leaf (topmost) > Intermediate(s) > Root で構成される更新済みの完全な証明書チェーンがインストールされていることを確認します。
- ルート証明書が変更されていない場合、または発行者が既知の CA である場合は、アプリケーションゲートウェイに対して何も行う必要はありません。
- プライベート CA を使用しており、ルート CA 証明書自体または更新された中間証明書のルートが変更された場合は、新しいルート証明書をアプリケーションゲートウェイのバックエンド設定にアップロードする必要があります。

V1 SKU の場合、

期限切れのリーフ (ドメインまたはサーバーとも呼ばれます) 証明書を CA で更新し、同じリーフ証明書 (.CER) を、お使いのアプリケーションゲートウェイの関連付けられているバックエンド設定にアップロードします。

中間証明書が見つかりませんでした

メッセージ: バックエンドサーバーによって提示された証明書チェーンに中間証明書がありません。証明書チェーンが完全で、バックエンドサーバーで正しく順序付けされていることを確認します。

原因: 中間証明書がバックエンドサーバーの証明書チェーンにインストールされていません。

解決策: 中間証明書はリーフ証明書に署名するために使用されます。そのため、チェーンを完了するには、この証明書が必要です。必要な中間証明書を認証局 (CA) に確認し、バックエンドサーバーにインストールしてください。このチェーンは、リーフ証明書で始まり、次に中間証明書、最後はルート CA 証明書の順である必要があります。ルート CA 証明書を含め、バックエンドサーバーに完全なチェーンをインストールすることをお勧めします。参考までに、「リーフはチェーンの最上位である必要があります」の証明書チェーンの例を確認してください。

Note

証明機関ではない自己署名証明書についても、同じエラーが発生します。これは、アプリケーションゲートウェイで、このような自己署名証明書が "リーフ" 証明書と見なされ、その署名中間証明書が検索されるためです。この記事に従って、自己署名証明書を正しく生成できます。

以下の画像は、自己署名証明書の違いを示しています。

リーフまたはサーバー証明書が見つからない

メッセージ: バックエンドサーバーによって提示された証明書チェーンにリーフ証明書がありません。チェーンが完全で、バックエンドサーバーで正しく順序付けされていることを確認します。

原因: バックエンドサーバーの証明書チェーンにリーフ (ドメインまたはサーバーと呼ばれます) 証明書がありません。

解決策: 証明機関 (CA) からリーフ証明書を取得できます。このリーフ証明書とそのすべての署名証明書 (中間 CA 証明書とルート CA 証明書) をバックエンドサーバーにインストールします。このチェーンは、リーフ証明書で始まり、次に中間証明書、最後はルート CA 証明書の順である必要があります。ルート CA 証明書を含め、バックエンドサーバーに完全なチェーンをインストールすることをお勧めします。参考までに、「リーフはチェーンの最上位である必要があります」の証明書チェーンの例を確認してください。

サーバーまたは中間証明書が一般に知られている CA によって発行されていない

メッセージ: The backend Server certificate isn't signed by a well-known Certificate Authority (CA). (バックエンドサーバー証明書が、既知の証明機関 (CA) によって署名されていません。) 不明な CA 証明書を使用するには、そのルート証明書をアプリケーションゲートウェイのバックエンド設定にアップロードする必要があります。

原因: バックエンドの設定で [well-known CA certificate] (既知の CA 証明書) を選びましたが、バックエンドサーバーから提示されたルート証明書は公に既知のものではありません。

解決策: プライベートの証明機関 (CA) によって発行されたリーフ証明書の場合、署名ルート CA 証明書をアプリケーションゲートウェイの関連付けられたバックエンド設定にアップロードする必要があります。こうすることで、アプリケーションゲートウェイはそのバックエンドサーバーとの信頼された接続を確立できます。これを解決するには、関連付けられたバックエンド設定に移動し、[not a well-known CA] (既知ではない CA) を選び、ルート CA 証明書 (.CER) をアップロードします。ルート証明書を特定してダウンロードするには、「信頼されたルート証明書の不一致」に記載されているものと同じ手順を実行します。

中間証明書が一般に知られている CA によって署名されていない

メッセージ: The Intermediate certificate isn't signed by a well-known Certificate Authority (CA). (中間証明書が、既知の証明機関 (CA) によって署名されていません。) 証明書チェーンが完全で、バックエンドサーバーで正しく順序付けされていることを確認します。

原因: バックエンドの設定で [well-known CA certificate] (既知の CA 証明書) を選びましたが、バックエンドサーバーから提示された中間証明書は公に既知の CA ではありません。

解決策: プライベートの証明機関 (CA) によって発行された証明書の場合、署名ルート CA 証明書をアプリケーションゲートウェイの関連付けられたバックエンド設定にアップロードする必要があります。こうすることで、アプリケーションゲートウェイはそのバックエンドサーバーとの信頼された接続を確立できます。これを修正するには、プライベート CA に問い合わせて適切なルート CA 証明書 (.CER) を取得し、[not a well-known CA] (既知ではない CA) を選んでその CER ファイルをアプリケーションゲートウェイのバックエンド設定にアップロードします。また、簡単に検証できるように、ルート CA 証明書を含め、バックエンドサーバーに完全なチェーンをインストールすることをお勧めします。

信頼されたルート証明書が一致しない (バックエンドサーバーにルート証明書がない)

メッセージ: 中間証明書が、アプリケーションゲートウェイにアップロードされたルート証明書によって署名されていません。証明書チェーンが完全で、バックエンドサーバーで正しく順序付けされていることを確認します。

原因: 関連付けられたバックエンド設定にアップロードされたルート CA 証明書のいずれも、バックエンドサーバーにインストールされた中間証明書に署名していません。バックエンドサーバーには、リーフ証明書と中間証明書のみがインストールされています。

解決策: リーフ証明書を中間証明書で署名し、中間証明書をルート CA 証明書で署名します。プライベート証明機関 (CA) の証明書を使う場合は、対応するルート CA 証明書をアプリケーションゲートウェイにアップロードする必要があります。プライベート CA に問い合わせて適切なルート CA 証明書 (.CER) を取得し、その CER ファイルをアプリケーションゲートウェイのバックエンド設定にアップロードします。

信頼されたルート証明書が一致しない (ルート証明書はバックエンドサーバーで使用できる)

メッセージ: The root certificate of the server certificate used by the backend doesn't match the trusted root certificate added to the application gateway. (バックエンドによって使用されるサーバー証明書のルート証明書が、アプリケーションゲートウェイに追加されている信頼されたルート証明書と一致しません。) Ensure that you add the correct root certificate to allowlist the backend. (バックエンドを許可リストに登録するために適切なルート証明書を追加していることを確認してください)

原因: このエラーが発生するのは、アプリケーションゲートウェイのバックエンド設定にアップロードされたルート証明書のいずれも、バックエンドサーバーに存在するルート証明書と一致しない場合です。

解決策: これは、プライベート証明機関 (CA) によって発行されたバックエンドサーバー証明書、または自己署名証明書に適用されます。正しいルート CA 証明書を特定し、関連付けられたバックエンド設定にアップロードします。

ヒント: ルート証明書を特定してダウンロードするには、次のいずれかの方法を使用できます。

ブラウザーを使用する: バックエンドサーバーに直接 (Application Gateway を介さずに) アクセスし、アドレスバーの証明書南京錠をクリックして証明書の詳細を表示します。
1. チェーンでルート証明書を選択し、[エクスポート] をクリックします。既定では、これは .CRT ファイルです。
2. .CRT ファイルを開きます。
3. [詳細] タブに移動し、[ファイルにコピー] をクリックします。
4. 証明書のエクスポートウィザードページで、[次へ] をクリックします。
5. [Base-64 エンコード X.509 (.CER)] を選択し、[次へ] をクリックします。
6. 新しいファイル名を付け、[次へ] をクリックします。
7. [完了] をクリックして .CER ファイルを取得します。
8. プライベート CA のこのルート証明書 (.CER) をアプリケーションゲートウェイのバックエンド設定にアップロードします。
バックエンドサーバーにログインする (Windows)
1. 対象のアプリケーションがホストされているマシンにサインインします。
2. Win + R キーを押すか、[スタート] を右クリックして [実行] を選択します。
3. 「certlm.msc」と入力し、Enter キーを押します。 [スタート] メニューで証明書マネージャーを検索することもできます。
4. 証明書を見つけ (通常は、証明書 - ローカルコンピューター\個人\証明書内にあります)、それを開きます。
5. ルート証明書を選択し、[証明書の表示] を選択します。
6. 証明書のプロパティで、[詳細] タブを選択し、[ファイルにコピー] をクリックします。
7. 証明書のエクスポートウィザードページで、[次へ] をクリックします。
8. [Base-64 エンコード X.509 (.CER)] を選択し、[次へ] をクリックします。
9. 新しいファイル名を付け、[次へ] をクリックします。
10. [完了] をクリックして .CER ファイルを取得します。
11. プライベート CA のこのルート証明書 (.CER) をアプリケーションゲートウェイのバックエンド設定にアップロードします。

リーフはチェーンの最上位である必要がある

メッセージ: The Leaf certificate isn't the topmost certificate in the chain presented by the backend server. (リーフ証明書が、バックエンドサーバーで提示されたチェーンの最上位証明書ではありません。) 証明書チェーンがバックエンドサーバーで正しく順序付けされていることを確認します。

原因: リーフ (ドメインまたはサーバーとも呼ばれます) 証明書がバックエンドサーバーに正しい順序でインストールされていません。

解決策: バックエンドサーバーへの証明書のインストールには、リーフ証明書とそのすべての署名証明書 (中間およびルート CA 証明書) で構成される順序付き証明書リストが含まれている必要があります。このチェーンは、リーフ証明書で始まり、次に中間証明書、最後はルート CA 証明書の順である必要があります。ルート CA 証明書を含め、バックエンドサーバーに完全なチェーンをインストールすることをお勧めします。

たとえば、サーバー証明書とその中間およびルート CA 証明書のインストールを OpenSSL で深さ (0、1、2 など) として示す場合、次の OpenSSL コマンドを使用して、バックエンドサーバーの証明書についても同じであることを確認できます。
s_client -connect <FQDN>:443 -showcerts
または
s_client -connect <IPaddress>:443 -servername <TLS SNI hostname> -showcerts

証明書の検証の失敗

メッセージ: The validity of the backend certificate could not be verified. (バックエンド証明書の有効性を検証できませんでした。) To find out the reason, check OpenSSL diagnostics for the message associated with error code {errorCode} (理由を調べるには、エラーコード {errorCode} に関連付けられたメッセージの OpenSSL 診断を確認してください)

原因: このエラーは、Application Gateway が証明書の有効性を確認できない場合に発生します。

解決策: この問題を解決するには、サーバー上の証明書が適切に作成されていることを確認します。たとえば、OpenSSL を使用して、証明書とそのプロパティを確認し、Application Gateway の HTTP 設定への証明書の再アップロードを試行できます。

バックエンドの正常性状態: 不明

バックエンドプールの DNS エントリの更新

メッセージ: The backend health status could not be retrieved. (バックエンドの正常性状態を取得できませんでした。) This happens when an NSG/UDR/Firewall on the application gateway subnet is blocking traffic on ports 65503-65534 in case of v1 SKU, and ports 65200-65535 in case of the v2 SKU or if the FQDN configured in the backend pool could not be resolved to an IP address. (これは、v1 SKU の場合はポート 65503 から 65534、v2 SKU の場合はポート 65200 から 65535 のトラフィックがアプリケーションゲートウェイサブネット上の NSG/UDR/Firewall によってブロックされている場合、またはバックエンドプールで構成された FQDN を IP アドレスに解決できない場合に発生します。) To learn more visit - https://aka.ms/UnknownBackendHealth. (詳細については、次にアクセスしてください。)

原因: FQDN (完全修飾ドメイン名) ベースのバックエンドターゲットの場合、Application Gateway では、後続の DNS ルックアップに対する応答を取得できなかった場合、正常であることが既知の最後の IP アドレスをキャッシュして使用します。この状態でゲートウェイに対して PUT 操作を行うと、DNS キャッシュが完全にクリアされます。その結果、ゲートウェイが到達できる宛先アドレスが存在しなくなります。

解決策: DNS サーバーが、特定の FDQN の DNS ルックアップに対する応答を提供しているかどうかを確認し、そうでなければ修正します。また、アプリケーションゲートウェイの Virtual Network を介して DNS サーバーに到達できるかどうかを確認する必要もあります。

その他の理由。

バックエンドの正常性状態が不明の場合、ポータルビューは次のスクリーンショットのようになります。

Application Gateway backend health - Unknown

この動作は、次の 1 つ以上の理由で発生することがあります。

Application Gateway サブネット上の NSG によって、ポート 65503 から 65534 (v1 SKU) または 65200 から 65535 (v2 SKU) への "インターネット" からのインバウンドアクセスがブロックされている。
Application Gateway サブネット上の UDR が既定のルート (0.0.0.0/0) に設定され、次ホップが "インターネット" として指定されていない。
Virtual Network への BGP 経由の ExpressRoute/VPN 接続によって、既定のルートがアドバタイズされる。
パブリックドメイン名を解決できない Virtual Network 上にカスタム DNS サーバーが構成されている。
Application Gateway が異常な状態である。

解決方法:

NSG によって、ポート 65503 から 65534 (v1 SKU) または 65200 から 65535 (v2 SKU) へのインターネットからのアクセスがブロックされているかどうかを確認します。

a. Application Gateway の [概要] タブで、[仮想ネットワーク/サブネット] リンクを選択します。 b. 対象の仮想ネットワークの [サブネット] タブで、Application Gateway がデプロイされているサブネットを選択します。 c. NSG が構成されているかどうかを確認します。 d. NSG が構成されている場合は、[検索] タブまたは [すべてのリソース] でその NSG リソースを検索します。 e. [受信規則] セクションで、[ソース] が GatewayManager サービスタグに設定されている、65503 から 65534 (v1 SKU の場合) または 65200 から 65535 (v2 SKU の場合) の宛先ポート範囲を許可するインバウンド規則を追加します。 f. [保存] を選択し、バックエンドが正常として表示されることを確認します。または、PowerShell または CLI を使用してこれを行うこともできます。
次ホップが [インターネット] に設定されていない既定のルート (0.0.0.0/0) が UDR にあるかどうかを確認します。

a. 手順 1a および 1b に従って、目的のサブネットを判別します。 b. UDR が構成されているかどうかを確認します。構成されている場合は、検索バーまたは [すべてのリソース] でそのリソースを検索します。 c. 次ホップが [インターネット] に設定されていない既定のルート (0.0.0.0/0) があるかどうかを確認します。設定が [仮想アプライアンス] または [Virtual Network ゲートウェイ] の場合は、仮想アプライアンスまたはオンプレミスのデバイスによって、パケットが変更されることなくインターネットの宛先に適切に戻されるようにする必要があります。プローブが仮想アプライアンスを経由でルーティングされ、変更された場合、バックエンドリソースには状態コード 200 が表示され、Application Gateway の正常性状態が不明として表示されることがあります。これはエラーを示すものではありません。トラフィックは引き続き問題なく Application Gateway 経由でルーティングされます。 d. それ以外の場合は、次ホップを [インターネット] に変更し、[保存] を選択した後、バックエンドの正常性を確認します。
仮想ネットワークへの BGP (Border Gateway Protocol) 経由の ExpressRoute または VPN 接続によってアドバタイズされる既定のルート:

a. BGP 経由で仮想ネットワークへの ExpressRoute または VPN 接続を使用していて、既定のルートをアドバタイズしている場合は、パケットが変更されることなくインターネットの宛先に戻されるようにする必要があります。 Application Gateway ポータルの [接続のトラブルシューティング] オプションを使用して確認できます。 b. 1.1.1.1 などの任意のインターネットルーティング可能な IP アドレスとして宛先を手動で選択します。任意の宛先ポートを選択して、接続を確認します。 c. 次ホップが仮想ネットワークゲートウェイの場合、ExpressRoute または VPN 経由でアドバタイズされる既定のルートが存在する可能性があります。
仮想ネットワークにカスタム DNS サーバーが構成されている場合は、サーバーがパブリックドメインを解決できるかどうかを確認します。パブリックドメイン名の解決は、Application Gateway が OCSP (オンライン証明書状態プロトコル) サーバーなどの外部ドメインにアクセスする必要があるシナリオや、証明書の失効状態などを確認する必要があるシナリオで必要になる場合があります。
Application Gateway が正常で実行中であることを確認するには、ポータルで [リソース正常性] オプションに移動し、状態が [正常] であることを確認します。 [異常] または [デグレード] 状態が表示される場合は、サポートにお問い合わせください。
インターネットとプライベートのトラフィックが、(Azure Virtual WAN ハブを使用して) セキュリティ保護付き仮想ハブでホストされた Azure Firewall を通過している場合:

a. アプリケーションゲートウェイがトラフィックをインターネットに直接送信できるようにするには、次のユーザー定義ルートを構成します。

アドレスプレフィックス:0.0.0.0/0
次ホップ:インターネット

b. アプリケーションゲートウェイが Virtual WAN のハブの Azure Firewall 経由でバックエンドプールにトラフィックを送信できるようにするには、次のユーザー定義ルートを構成します。

アドレスプレフィックス: バックエンドプールサブネット
ネクストホップ: Azure Firewall のプライベート IP アドレス

次のステップ

Application Gateway の診断とログの詳細を確認します。

Application Gateway のバックエンドの正常性に関する問題のトラブルシューティング

概要

バックエンドの正常性を確認する方法

バックエンドの正常性状態: 異常

エラー メッセージ

バックエンド サーバーのタイムアウト

DNS の解決エラー

TCP 接続エラー

HTTP 状態コードの不一致

HTTP 応答本文の不一致

共通名 (CN) が一致しません

バックエンドの有効期限が切れています

中間証明書が見つかりませんでした

リーフまたはサーバー証明書が見つからない

サーバーまたは中間証明書が一般に知られている CA によって発行されていない

中間証明書が一般に知られている CA によって署名されていない

信頼されたルート証明書が一致しない (バックエンド サーバーにルート証明書がない)

信頼されたルート証明書が一致しない (ルート証明書はバックエンド サーバーで使用できる)

リーフはチェーンの最上位である必要がある

証明書の検証の失敗

バックエンドの正常性状態: 不明

バックエンド プールの DNS エントリの更新

その他の理由。

次のステップ

その他のリソース

エラーメッセージ

バックエンドサーバーのタイムアウト

信頼されたルート証明書が一致しない (バックエンドサーバーにルート証明書がない)

信頼されたルート証明書が一致しない (ルート証明書はバックエンドサーバーで使用できる)

バックエンドプールの DNS エントリの更新